[pulseaudio-discuss] alsa sink latency - how to account for startup delay
Georg Chini
georg at chini.tk
Sat Apr 16 06:43:15 UTC 2016
On 16.04.2016 05:08, Raymond Yau wrote:
>
>
> >>
> >>
> >> >
> >> >> do loopback module assume sink is not running when it start
> source capture?
> >> >>
> >> > Sink and source are started independently. Source data is
> discarded until the sink-input has
> >> > called pop() the first time.
> >>
> >> But you cannot skip more than 9ms source data since you need 1ms(
> or 25ms fragment time when not using timer schedule mode) to capture
> >>
> >> If you are using usb as source and hda as sink, hda fifo trigger
> dma transfer whenever the fifo fill level is less than fifo threshold,
> you need to fill 256 bytes at first write to avoid fifo underrun
> >>
> >>
> > Yes, if the source takes too long to start up, there will be an an
> underrun.
> > But as I said, I fill the memblockq with silence to the full requested
> > end-to-end latency before starting source or sink. This is usually
> sufficient
> > to avoid underruns at startup.
> > Additionally the new loopback code contains an underrun protection,
> > if the configured end-to-end latency is too small. After 3 underruns it
> > will increase the target latency by 5 ms until no underruns occur.
> >
> >
>
> Your method require source and sink suppport same rate and format, how
> about usb webcam mic support only 16000Hz and hda sink which do not
> support 16000Hz?
>
No, it doesn't. It works also when source and sink have different rate,
because there is a (fixed) resampler on the source side that converts
the source
sample rate to the nominal rate that is specified on the command line.
> How about those fixed latency sound cards which does not support
> latency adjust (e.g. granularity is period time 25ms) pcm pointer only
> increase by period size when interrupt occur
>
Adjusting the latency is done in the memblockq. The sink and source
latency just
give the limits of what is possible.
>
> ar 30 21:46:01 pico1 pulseaudio[11846]: [alsa-sink-USB Audio]
> alsa-sink.c: Starting playback.
>
> Mar 30 21:46:01 pico1 pulseaudio[11846]: [pulseaudio]
> module-suspend-on-idle.c: Sink
> alsa_output.usb-0d8c_C-Media_USB_Headphone_Set-00.analog-stereo
> becomes idle, timeout in 5 seconds.
>
> Mar 30 21:46:01 pico1 pulseaudio[11846]: [alsa-sink-USB Audio]
> ratelimit.c: 322 events suppressed
>
> Mar 30 21:46:01 pico1 pulseaudio[11846]: [alsa-sink-USB Audio]
> alsa-sink.c: Cutting sleep time for the initial iterations by half.
>
> Mar 30 21:46:01 pico1 pulseaudio[11846]: [alsa-sink-USB Audio]
> alsa-sink.c: Cutting sleep time for the initial iterations by half.
>
> why 322 events suppressed ?
>
>
Don't know, I did not touch the code there. I only replaced the
update_smoother function.
> 0 21:46:01 pico1 pulseaudio[11846]: [pulseaudio] module-loopback.c:
> Minimum possible latency: 2,50
>
> Mar 30 21:46:01 pico1 pulseaudio[11846]: [alsa-sink-USB Audio]
> alsa-sink.c: Cutting sleep time for the initial iterations by half.
>
> Mar 30 21:46:01 pico1 pulseaudio[11846]: [alsa-sink-USB Audio]
> alsa-sink.c: Cutting sleep time for the initial iterations by half.
>
> will module loopback stop when user specify latency less than minimum
> possible ?
>
>
It will not stop but use the lowest possible latency. That's why I
calculate it.
The log line with "minimum possible latency" appears twice in the log, the
second appearance gives the correct calculated minimum. I had a long
discussion with Tanu how to calculate it and what I am doing there may
be wrong, therefore I placed the calculation in a separate function so
that it
can be changed easily.
It probably is no save value anyway, because the devices report latency
ranges that they do not support (USB for example is telling you it supports
0.5ms).
I have however added an underrun protection that will increase the target
latency by 5ms after 3 underruns. This will continue until there are no
longer
any underruns.
> How do you know there is no underrun when stop threshold is set to
> boundary?
>
I don't understand this question.
> How do you recover underrun when source capture less data than sink
> playback? Do loopback inject some data?
>
I am using adaptive re-sampling, so if the source is slower, the sample
rate will be adjusted accordingly.
No data is injected.
> The lowest latency is hardware dependent, will the loopback module
> recalcuate after user switch sink or source ?
>
Yes.
> Neither alsa avail nor delay increase like a straight line, the main
> problem is you don't know the process time for your to skip and copy
> data from input to output,
>
> how can the latency be accurate?
>
>
I'll send you the document with the theory privately. I would appreciate
if you find some time to review it, it is still a draft.
More information about the pulseaudio-discuss
mailing list