On Sat, September 28, 2013 2:58 am, Patrick Shirkey wrote: > > On Sat, September 28, 2013 12:53 am, Tanu Kaskinen wrote: >>> On Fri, 2013-09-27 at 23:31 +1000, Patrick Shirkey wrote: >>> >>> 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". >> > > The other option is to use JACK exclusively while it is running. The opens > a can of worms that I would rather didn't have to be opened. > > >>> 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). > > Any or all of the above. Basically a discontinuity in the stream which > means jack_delay cannot complete the signal loop temporarily. > > >> 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. >> > > Another location that hasn't been discussed could be the point between > ecasound and PA (the intermediate alsa layer) > > >>> 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.) >> > > Approximately every second. I will try again with a possibly newer version > of jack_delay in case that helps. > This is with a newer version of jack_delay which I didn't know about until a few minutes ago. http://boosthardware.com/pa-jack-latency-2.txt The results are better which is encouraging but the variation is still happening just on a smaller scale. > >> 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). >> > Looks like this might be required now. -- Patrick Shirkey Boost Hardware Ltd
