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 _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/listinfo/linux-audio-dev
