Re: Periodically silence when listening through uaudio

> 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]
> > 
> >