On Sun, September 22, 2013 1:55 am, Tanu Kaskinen wrote: > On Thu, 2013-09-19 at 23:54 +1000, Patrick Shirkey wrote: >> On Thu, September 19, 2013 6:52 pm, Patrick Shirkey wrote: >> > >> > On Thu, September 19, 2013 6:42 pm, Tanu Kaskinen wrote: >> >> On Wed, 2013-09-18 at 04:28 +1000, Patrick Shirkey wrote: >> >>> Hi, >> >>> Can someone shed some light on the best case and typical latency >> that >> Pulse provides for standard operations? >> >> What do you mean by standard operations? I'd estimate volume changes >> etc. normally (on an ALSA sink) have a few millisecond latency (best >> case 0.5 ms audio buffer + scheduling latency). >> > >> > Just a "normal" round trip signal flow, for example : PA (in) -> >> audacity >> > (in) -> audacity (out) -> pa (out) >> > >> > >> >>> Also how that is affected by using jack-sink assuming jack is set to >> the >> >>> lowest possible latency that a device can handle? >> >> When jackd asks for N frames from PulseAudio, pulseaudio will render >> N >> frames. There's no extra buffering done in the Jack sink, so volume >> changes etc. will have latency that is roughly the same as the normal >> Jack client latency. >> > >> > Do you have an suggestions on how to get an accurate measurement? >> > >> >> >> I'm using this method: >> >> jack_delay -> pa_source -> audacity -> pa_sink -> jack_delay >> >> jack is set to 64/48000/2 >> >> Using audacity with 0 internal latency and in pass through mode I see >> the >> following results. It starts out as 10.667ms and after a few seconds it >> climbs up to 70.667 ms. >> >> I see similar results with ecasound instead of audacity using the >> following chain: >> >> jack_delay -> pa_source -> ecasound -> pa_sink -> jack_delay >> >> ecasound -f:32,2,48000 -b:64 -i alsa -o alsa >> >> In that case it starts at 60.000 ms and climbs upto 572.000 ms after a >> few >> seconds of running the test. >> >> Full console logs here: >> >> http://boosthardware.com/pa-jack-latency.txt >> >> This appears to be caused by PA adding more buffer on a regular basis. >> Any >> thoughts on why this is happening and how to stop it? > > PulseAudio doesn't increase the buffering on the fly (well, some small > adjustments are done with ALSA, but you're using JACK, so that's > irrelevant). If the source produces audio faster than the sink consumes > it, then I guess the buffer might accumulate in the PulseAudio client > (audacity/ecasound). I think one reason for the source "running faster" > could be that the sink side is experiencing underruns, which causes > silence to be sent to jack_delay every now and then, and this silence is > not compensated by dropping a matching amount of data from the PA > client. > That seems like a reasonable explanation. The device I am using is an onboard hda_intel and I am seeing a lot of xruns in the jack console messages. >From the perspective of an ignorant user this appears to be a sort of bug in that the audio stream is being delivered to the speakers but not to jack_delay. Although ears can be deceiving I don't hear any obvious dropouts. Can you think of a way to mitigate this issue when using both jack and pa at the same time? I am seeing this issue with both 64 frames/period and 1024 . I usually run with 1024 on JACK and that stable for me albeit I don't ever try to record to jack apps with the onboard mic. However, I use skype via PA regularly and it usually provides semi decent quality for phone conversations (without jack running). I tried using the skype call testing service with jack+pa. I can hear my voice and there are no obvious artefacts. The end goal here is to find a way to accurately measure the round trip latency when both JACK and PA are in use and figure out a robust method to achieve the lowest latency possible while PA is connected to JACK . Ideally I would like to measure the latency between each node in the graph. Does the PA API allow for obtaining latency measurements between nodes in the graph? Could I spin up a tool to gather that data for testing/QA purposes? By combining that info with jack_delay and a couple of other system metrics I might be able to gain some useful insight into tweaking the system to provide better performance other than installing a realtime kernel and setting the priorities with rtirq. That's assuming that there is anything that can be done to either PA or JACK to make it perform better. -- Patrick Shirkey Boost Hardware Ltd
