[pulseaudio-discuss] [PATCH v2 3/3] client API: Document buffer_attr.maxlength

[Tanu Kaskinen]

On Fri, 2013-03-22 at 10:42 +0100, David Henningsson wrote:
> On 03/22/2013 09:58 AM, Tanu Kaskinen wrote:
> > On Thu, 2013-03-21 at 19:10 +0100, David Henningsson wrote:
> >> Let's officially support that people use maxlength to put an upper
> >> bound on playback latency.
> >>
> >> Signed-off-by: David Henningsson <david.henningsson at canonical.com>
> >> ---
> >>   src/pulse/def.h |    8 +++++++-
> >>   1 file changed, 7 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/src/pulse/def.h b/src/pulse/def.h
> >> index 495302f..79d93e1 100644
> >> --- a/src/pulse/def.h
> >> +++ b/src/pulse/def.h
> >> @@ -360,7 +360,13 @@ typedef struct pa_buffer_attr {
> >>       uint32_t maxlength;
> >>       /**< Maximum length of the buffer in bytes. Setting this to (uint32_t) -1
> >>        * will initialize this to the maximum value supported by server,
> >> -     * which is recommended. */
> >> +     * which is recommended.
> >> +     *
> >> +     * In strict low-latency playback scenarios you might want to set this to
> >> +     * a lower value, likely together with the PA_STREAM_ADJUST_LATENCY flag.
> >> +     * If you do so, you will get underflows instead of increasing latency
> >> +     * if PulseAudio cannot deliver the latency you requested, so this is not
> >> +     * recommended unless you know what you're doing. */
> >
> > "Underflows instead of increasing latency" sounds like there wouldn't be
> > underruns at all if maxlength is big enough, and also like the latency
> > wouldn't still increase if maxlength is low (currently, the sink latency
> > will increase regardless of the stream buffer settings, it's only
> > tlength that will stop increasing). I think it would be better to say
> > that maxlength sets the upper limit for tlength.When tlength reaches
> > maxlength, device underruns won't increase the tlength anymore.
> 
> IMO, this is bikeshedding. But I can change "you will get underflows" to 
> "you might get underflows" if that makes you happier.

That doesn't fix the issue that the phrasing sounds like there wouldn't
be underruns at all if maxlength is big enough. I propose this:

"In strict low-latency playback scenarios you might want to set this to
a lower value, likely together with the PA_STREAM_ADJUST_LATENCY flag.
If you do so, you ensure that the latency doesn't grow beyond what is
acceptable for the use case, at the cost of getting more underruns if
the latency is lower than what the server can reliably handle."

> > So, maxlength doesn't currently set any cap for the sink latency. The
> > stream buffer maxlength parameter only limits the stream buffer size.
> > Perhaps we should limit the sink buffering too based on the stream
> > buffer maxlength, though?
> 
> Hmm, maybe I need to investigate this in more depth. But yes, if you set 
> both maxlength and PA_STREAM_ADJUST_LATENCY, the maxlength should affect 
> the maximum latency of the sink too, but that is more of an 
> optimisation. Because even if the sink latency increases, and the stream 
> buffer length stays the same, won't the result be that the overall 
> latency stays the same, but you'll have a lot of rewinds?

I think the stream buffer will get smaller and smaller, keeping the
total latency constant, until the stream buffer can't be made any
smaller. Then the total latency starts to increase again, if the sink
latency isn't limited by the stream maxlength.

I don't think you need to do anything about this now, though. If the
total latency increases because the stream buffer can't be made any
smaller, the stream audio is totally broken anyway at that point, so
documenting this behavior doesn't seem necessary, especially if we
change things in the future so that the sink latency stops growing
before this happens.

> > Another thing is that we don't increase tlength on stream buffer
> > underruns (not even on "real" stream underruns, as long as we don't have
> > an alsa underrun). Since it looks like we already have a mechanism for
> > applications to state the absolute maximum latency that they are ready
> > to accept, perhaps we should be more liberal in increasing the tlength,
> > and bump it whenever a stream underrun happens?
> 
> I don't know. That's a topic for a separate discussion.

True.

-- 
Tanu