Re: Periodically silence when listening through uaudio

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