On August 25, 2024 6:58:31 AM GMT+02:00, "Michał Pecio" <michal.pecio@xxxxxxxxx> wrote: >I believe what happens is that in full duplex, either by request from >Jack or on its own, snd-usb-audio attempts to synchronize the playback >and recording streams by scheduling packets to move in specific USB >(micro)frames. Yes, at least in libasound2 there is a call snd_pcm_link <https://www.alsa-project.org/alsa-doc/alsa-lib/group___p_c_m.html#gac6c33091b049985baa6466e8fe93917e> which jack uses in the full duplex case: <https://github.com/jackaudio/jack1/blob/ab2e7363cacd0bf4b961c0466c13b0b4c1086ed9/drivers/alsa/alsa_driver.c#L2431> I know too little about alsa internals and USB to follow through the libasound2 > snd_usb_audio > usb class driver > usb core > xhci chain to grasp the specific way this is achieved though :( Bugs could be lurking everywhere ;) >With playback only, the queued packets are only marked "ASAP" and the >hardware can cheat by delaying them to the next frame if either: >- it fails to do the transfer on time for internal reasons >- we fail to queue the transfer before its due time > >See discussion in xHCI spec 4.10.3.1, 4.10.3.2. Thanks for the pointer. >Regarding capture, snd-usb-audio seems to always queue about 10 packets >or so. Latency depends only on the hardware returning them quickly and >no delays in the IRO-drivers-application pipeline. There is almost zero >risk that the URBs won't be resubmitted on time and the hardware will >face either an empty queue or an already stale packet. > >That being said, I'm seeing Missed Service Errors on the recording side, >so it's possible that in my case the ASmedia controller is to blame... I will try and do a little more "comparative tracing" for the capture/playback/full duplex cases on 1. the intel xhci and 2. the renesas xhci which seems to work perfectly. Kind regards, FPS
