On 29.03.2016 02:13, Pierre-Louis Bossart wrote: > On 3/28/16 12:38 PM, Georg Chini wrote: >> On 28.03.2016 17:18, Georg Chini wrote: >>> On 28.03.2016 16:16, Pierre-Louis Bossart wrote: >>>> On 3/22/16 4:11 AM, Georg Chini wrote: >>>>> Hi, >>>>> >>>> Ups, looks like I misread your sentence above. You are right, in >> software you can't >> see the output. But what you can see is the time between dispatching the >> audio >> to the USB bus and the time when the bus reports back that the audio was >> played. >> >> I am not sure if I read the code right, I don't know anything about USB, >> but if the >> URB's you are submitting to the bus in the prepare step are handled in >> chronological >> order, it means that >> a) you have to wait for the next URB to retire before you can send any >> real audio >> b) after you submitted the first audio, it is at the end of the queue >> and all the other >> URB's containing silence will be processed first. > > The USB driver will submit N silence URBs on startup in the prepare > and you will have to wait for those URBs to retire before the samples > are queued. There is very little 'USB processing'. If you want to > reduce this delay you have to use smaller periods, it'll decrease the > size of the URBs. I guess it could be possible to change the URB size > after the start but that's not implemented atm. > I don't want to shorten the latency. I only want the latency reported correctly. To me it still looks like the real latency of the driver is not what it reports, because the time that the audio spends in the URB's is not taken into account. What I am seeing is, that the real latency is around 10ms longer than expected.
