[pulseaudio-discuss] Best Case Latency

[Tanu Kaskinen]

On Fri, 2013-09-27 at 23:31 +1000, Patrick Shirkey wrote:
> On Fri, September 27, 2013 10:52 pm, Tanu Kaskinen wrote:
> > On Fri, 2013-09-27 at 19:26 +1000, Patrick Shirkey wrote:
> >> On Thu, September 26, 2013 2:27 am, Tanu Kaskinen wrote:
> >> > Sorry, forgot to reply earlier. Yes, you can check the stream buffer
> >> > with "pactl list sink-inputs". The "Buffer Latency" field shows the
> >> > amount of audio in the stream buffer (not yet written to the sink).
> >> The
> >> > "Sink Latency" field shows the latency of the sink. The sum of these
> >> two
> >> > values is the full server-side latency for the stream. In addition to
> >> > the server-side latency, there's the transport latency between the
> >> > client and the server (very low for local streams).
> >> >
> >>
> >> Thanks for that info. Polling the output I see the results fluctuate
> >> over
> >> time in much the same way that the results from jack_iodelay fluctuate.
> >> I
> >> haven't tried to correlate them yet but here's a snapshot to give you a
> >> better idea of what is happening on this machine.
> >
> > The latency stays around 10 ms. You complained earlier that the latency
> > would grow to several hundreds of milliseconds, but this shows no such
> > behaviour, so the problem is somewhere else than in the playback stream
> > inside pulseaudio.
> >
> 
> It may seem like I am complaining but I am not trying to come across that
> way.

I guess that was a bad choice of words from my part. You were reporting
undesirable behaviour, which I referred to as complaining. I used it as
a neutral word, not as in "whining" or anything like that.

> I am trying to get hard data on the real world latency performance
> using the combination of JACK + PA to allow a bunch of people including
> some of your colleagues at Intel to attempt to make a professional
> business decision about the best way to integrate them (or not) for mobile
> platforms. IMO it is best to run them with the method that I am testing
> and fix any issues that might not have been ironed out yet but others are
> suggesting they should be used interchangeably. That opens up a can of
> works that may be a lot more effort to implement both in terms of
> resources and politically for various reasons so I am reluctant to follow
> that path unless all options with combining JACK + PA have been
> categorically shown to be infeasible or impractical (or both).

Sorry, I couldn't really follow what you're saying, but I won't go into
detail, since I believe this is not relevant for solving the latency
mystery.

> At the moment I'm trying to pin down the cause of the consistent and
> reproducible but fluctuating latency results that I see with this machine.
> I am doing this in order to get the hard data I need to present the JACK +
> PA solution as the better method.

One of the unclear things is what other method you are comparing the
"JACK + PA solution".

> So far I cannot point the finger at any
> specific process or bottleneck. Given that I am apparently the only person
> in the world who has the time and/or motivation to run these tests we are
> working with the small dataset that I can provide. All your feedback is
> crucial and very useful as I do not have the complete overview of PA
> codebase like yourself or others on this list.
> 
> To recap, I have tested with two jack graphs.
> 
> 1: jack_delay -> pa -> ecasound -> pa -> jack_delay
> 
> The latency starts low and then consistently climbs (see below).
> 
> 2: jack_delay -> pa -> ecasound -> pa -> system_out -> system_in ->
> jack_delay
> 
> The latency jumps around from anything between 4ms to 1300ms. It might
> also go lower but I didn't see that yet.
> 
> - Here's an interesting snapshot for consideration captured just now while
> running graph 1. The latency captured while polling with "pactl list
> sink-inputs" is the same as the previous snapshot (approx 10ms).
> 
> ex.
> 	Buffer Latency: 8000 usec
> 	Sink Latency: 3166 usec
> 
> However, jack_delay reports the following data. Where you see ?? that
> indicates a dropout in the audio stream so jack_delay was not able to make
> a real measurement so guessed.

What do you mean by "dropout"? An xrun reported by jackd? Note that
there are several different kinds of underruns and overruns that can
occur. One kind is the case where jackd is late to read/write to the
sound card (alsa). Another kind is when pulseaudio is late to read/write
to jackd (I'm not sure if this will always translate also to alsa level
under/overruns too). Third kind is when ecasound is late to read/write
to pulseaudio (this is what I'll refer to as "stream under/overruns",
and these are invisible to the jack domain). Do you get logs about each
of these? I don't remember if the alsa compatibility layer forwards the
stream under/overrun notifications to the alsa application - IIRC there
were problems when those were reported and there were different problems
when those were not reported, and I don't remember what the current code
does.

I don't know if distinguishing between the different kinds of
under/overruns is really important at this point, though. Changes in the
latency probably happen when there is some kind of an under/overrun, but
that doesn't help much with figuring out in which buffer the audio is
accumulating.

> jack_delay -> pa -> ecasound -> pa -> jack_delay
> 
> ---------------
> 62784.000 frames   1308.000 ms total roundtrip latency
> 	extra loopback latency: 62784 frames
> 	use 31392 for the backend arguments -I and -O
>  62784.000 frames   1308.000 ms total roundtrip latency
> 	extra loopback latency: 62784 frames
> 	use 31392 for the backend arguments -I and -O ?? Inv
>  63168.000 frames   1316.000 ms total roundtrip latency
> 	extra loopback latency: 63168 frames
> 	use 31584 for the backend arguments -I and -O

What's the interval of these measurements? I mean once per 10 seconds or
something like that? (Just trying to get a better understanding of the
rate of the latency changes.)

Since "pactl list sink-inputs" doesn't show any abnormal behaviour, it
looks to me like the next step is to either add extra logging to each
point in the audio path that deals with buffering (print the amount of
buffered audio), or write the measurement application that you were
planning to do (that should find out whether the bad buffer is in the
input or output path, but still doesn't pin-point the bad buffer).

-- 
Tanu