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. > 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). > -- Patrick Shirkey Boost Hardware Ltd
