[LAD] JACK + PA Latency

[Patrick Shirkey]

On Sat, September 28, 2013 2:47 am, Patrick Shirkey wrote:
>
> 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.
>

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

The results are quite different so that's a good sign. However they are
still changing on a regular basis so my quest to understand the cause of
this behaviour to find out if it is a localised issue or a bug of some
kind is not over yet.



--
Patrick Shirkey
Boost Hardware Ltd