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.
_______________________________________________
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
