On Sun, 2013-09-22 at 02:30 +1000, Patrick Shirkey wrote:
> On Sun, September 22, 2013 1:55 am, Tanu Kaskinen wrote:
> > 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.
If you want to get the minimum latency of this path:
jack_delay -> pulseaudio -> application -> pulseaudio -> jack_delay
then you should use an application that reports underruns and lets you
control the latency that the application requests from pulseaudio. Then
you can tune the application latency to find the point where you start
to get underruns. You should also know the maximum internal buffer size
of the application. You probably need to write that application
yourself.
pa_stream_get_latency() gives you an estimate of the latency between the
hardware and your application. pa_stream_get_timing_info() gives some
more details about how that latency is split between different parts in
pulseaudio.
--
Tanu
