[LAD] JACK + PA Latency

Patrick Shirkey pshirkey at boosthardware.com
Fri Sep 27 16:47:02 UTC 2013


On Sat, September 28, 2013 1:29 am, Fons Adriaensen wrote:
> On Sat, Sep 28, 2013 at 12:42:26AM +1000, Patrick Shirkey wrote:
>
>> 1: Why PA is reporting 10ms for the stream buffer but jack_delay is
>> giving
>> the results below.
>>
>> 2: Why PA is reporting 10ms for the stream buffer when I am running jack
>> at 64 frames/period and ecasound too.
>
>> 3: Where the fluctuating measurements from jack_delay are coming from in
>> the graph as PA Stream Buffer is static at 10ms and ecasound is
>> basically
>> in pass through with a 64/48k buffer same as JACK. A back of the envelop
>> estimation suggests latency should be stable well under 20ms including
>> the
>> 10ms set aside for the PA Stream buffer.
>
> (1) and (2) you should really ask to the PA author(s).
>
> Regarding (3):
>
> * The results you included can't be consecutive outputs of jack_iodelay
>   at least not as I wrote it. So what is the real timing of them ?
>

Those results are sequentially copied with no editing. I was surprised to
see it as I thought it would just keep climbing.

I have included the full log here:

http://boosthardware.com/pa-jack-latency-1.txt

Absolutely no editing.


> * How is ecasound taling to PA ? Some native PA interface ? ALSA ?
>   Any ALSA 'plugs' in the chain ?
>

ecasound -f:32,2,48000 -b:64 -i alsa -o alsa

It's possible that something is creeping in between ecasound and PA. Or
maybe it is the way PA is handling the stream?


> * Going from 65216 to 64 is just an overflow modulo 2^16 (which the
>   maximum that jack_(io)delay can measure. Apart from that, the
>   delay seems to be continuously increasing, but since you edited
>   the result it's not possible to say how fast.
>
> Either PA is adding more and more buffering as time goes on, or
> it is resampling and doing a very bad job at it.
>
>
> Hint: use jack_delay (on my website), it will output less clutter
> (one line per value), and is also more resistant to abnormal
> circumstances.
>
>

I will try that next.


--
Patrick Shirkey
Boost Hardware Ltd


More information about the Linux-audio-dev mailing list