> I guess that opening the pipe does something on the device side that > breaks audio.
I found bug https://bugzilla.kernel.org/show_bug.cgi?id=215934 about it. Vendor changed something in 1.35 revision and now driver should use implicit feedback endpoint. I don't think there is easy solution so I'll try to dig how to implement it and see how it behaves without sync endpoint. On Wed, Apr 22, 2026 at 03:26:32PM +0200, Alexandre Ratchov wrote: > On Wed, Apr 22, 2026 at 02:07:35PM +0300, Artem Sheldyaev wrote: > > I also dumped usb packets on linux and situation the same, no > > communication on 0x84 endpoint. > > > > > Could you confirm that on Windows/macOS you're using the standard > > > class driver (i.e. no vendor specific driver)? > > > > On windows I have vendor driver installed, but there is no driver for macos > > and linux. I > > Also tried dump on linux and there is also no specific drivers. > > > > > With your modification, is the sound stable on OpenBSD? I'd expect a > > > periodic glitch. Note that the glitch period is related to the > > > difference between the audio and bus clocks, so it may be long, it > > > could be several minutes, which is difficult to observe on OpenBSD. > > > > On 300s sample there is only one silence in the begginging and then > > everything is ok. > > > > > Last question: how did you capture the USB packets? > > > > tcpdump -i usb0 -w dump_file on openbsd, using wireshark on > > XHC20 iface on macos, wireshark on usbmon on linux and on windows. > > > > > > If I understand correctly, host make psync_xfer to device and presumably > > polling device to get response and call psync_intr with xfer? > > The usbd_open_pipe() call is responsible for starting the sync > xfers. The uaudio_psync_xfer() calls only submit buffers to the host > controller where the data is stored. > > > Then why > > If I comment psync_xfer (and there is no more responses from device) calls > > the problem persist? > > > > I guess that opening the pipe does something on the device side that > breaks audio. > > > I watch deeper on packets notices some things: > > > > 1. Other systems send clock validity request, but I tried to do it and > > nothing changed. > > > > 2. I found it strange that clock source descriptor have "synchronization: > > free running" attribute value. Maybe it related with synchronization > > endpoint? > > > > 3. On the OpenBSD dump there is so much communications on 0x84 between > > real data transfers on 0x08, but I think it must be 8 times less often > > than data transfer (1 << (ival - 1))? > > > > That's what I thought in first place, but the polling interval is not > set by the uaudio(4) driver. It is setup directly by the usb stack > which doesn't make any difference between data and sync pipes or even > between device types. So the interval handling is likely to be > correct. > > ival = 4, means we poll the device every (1 << (4 - 1)) = 8 frames. > > usb 2.0 schedules 8000 frame/second, so this corresponds to one sync > frame every millisecond. IIUC, this seems to match the dump below: > > I don't understand the data packets of the dump though. > > > Different between calls: > > > > 89 0.027691 0.5.8 host USB 519 > > 0x08 URB_ISOCHRONOUS out[Packet size limited during > > capture] > > 90 0.027813 host 0.5.8 USB 8199 > > 0x08 URB_ISOCHRONOUS out[Packet size limited during > > capture] > > 91 0.027848 0.5.4 host USB 51 > > 0x84 URB_ISOCHRONOUS in > > 92 0.027848 host 0.5.4 USB 51 > > 0x84 URB_ISOCHRONOUS in > > 95 0.028758 0.5.4 host USB 51 > > 0x84 URB_ISOCHRONOUS in > > 96 0.028759 host 0.5.4 USB 51 > > 0x84 URB_ISOCHRONOUS in > > 97 0.029756 0.5.4 host USB 51 > > 0x84 URB_ISOCHRONOUS in > > 98 0.029757 host 0.5.4 USB 51 > > 0x84 URB_ISOCHRONOUS in > > 99 0.030757 0.5.4 host USB 51 > > 0x84 URB_ISOCHRONOUS in > > 100 0.030758 host 0.5.4 USB 51 > > 0x84 URB_ISOCHRONOUS in > > 101 0.031756 0.5.4 host USB 51 > > 0x84 URB_ISOCHRONOUS in > > 102 0.031758 host 0.5.4 USB 51 > > 0x84 URB_ISOCHRONOUS in > > 103 0.032756 0.5.4 host USB 51 > > 0x84 URB_ISOCHRONOUS in > > 104 0.032757 host 0.5.4 USB 51 > > 0x84 URB_ISOCHRONOUS in > > 105 0.033756 0.5.4 host USB 51 > > 0x84 URB_ISOCHRONOUS in > > 106 0.033757 host 0.5.4 USB 51 > > 0x84 URB_ISOCHRONOUS in > > 107 0.034756 0.5.4 host USB 51 > > 0x84 URB_ISOCHRONOUS in > > 108 0.034757 host 0.5.4 USB 51 > > 0x84 URB_ISOCHRONOUS in > > 109 0.035756 0.5.4 host USB 51 > > 0x84 URB_ISOCHRONOUS in > > 110 0.035757 host 0.5.4 USB 51 > > 0x84 URB_ISOCHRONOUS in > > 111 0.036758 0.5.4 host USB 51 > > 0x84 URB_ISOCHRONOUS in > > 112 0.036759 host 0.5.4 USB 51 > > 0x84 URB_ISOCHRONOUS in > > 113 0.037693 0.5.8 host USB 519 > > 0x08 URB_ISOCHRONOUS out[Packet size limited during > > capture] > > 114 0.037813 host 0.5.8 USB 8199 > > 0x08 URB_ISOCHRONOUS out[Packet size limited during > > capture] > > > >
