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