[pulseaudio-discuss] Best Case Latency

[Tanu Kaskinen]

On Mon, 2013-10-07 at 20:23 +1100, Patrick Shirkey wrote:
> There are two options that JACK allows for
> 
> 1) Kick the offender from the graph
> 2) Allow dropouts in the stream (softmode)
> 
> I suppose in this case PA is trying to stop dropouts from happening which
> is a noble cause because most of the audio flowing through PA is probably
> fine with a variable buffer.
> 
> >From the user perspective combining JACK and PA together to provide low
> latency high performance audio I'm not sure if anything should be done to
> change the existing system.

A buffer that can grow without limit is definitely a bug. It would be
nice to get that fixed. (I doubt I will personally work on it, though.)

> However from the developer perspective this
> leans in favour of adding Bluez support to JACK directly so that systems
> that explicitly require low latency with hard time limits can keep the
> bluetooth stream running while JACK is also running. I'm not sure how that
> affects managing policy with Murphy.

I don't think anyone was talking about Bluez or Murphy in this thread
before you brought them up here, so people are most likely missing a lot
of context. I'll try to explain the background briefly.

I was pointed to a thread[1] on tizen-general that you started. The
topic there was what should the Tizen audio stack contain - should JACK
be supported, and if so, should it be an alternative for PA, or should
they be stacked (PA on top of JACK). Supporting a JACK-only
configuration would require adding BlueZ and Murphy support to JACK.

[1] http://thread.gmane.org/gmane.comp.handhelds.tizen.general/1683

> There are a couple of things that have been identified in this test process.
> 
> - PA Stream Buffer adds approx 10ms latency to the stream at 64/48000/2
> - PA main loop handles the audio stream in a way that allows the buffer to
> grow causing variable latency on systems that cannot keep up.
> - I should try to find out why realtime is not working for PA+JACK on my
> test system.
> 
> It seems there are a some of issues to figure out in terms of supporting
> the combination of JACK + PA.
> 
> Given that the PA Stream buffer adds 10ms latency and there are cases
> where 20ms is the max time available to the entire audio graph is it
> viable that we should try to make PA + JACK more efficient?

One thing would be to make sure that no matter how low the JACK latency
is, PA should handle it gracefully, if PA clients connected to the JACK
sink/source don't require low latency. The growing buffer problem could
perhaps be mitigated so that the JACK source wouldn't send every tiny
audio block that it gets from JACK to the main thread. Instead, the JACK
source could have a bit larger buffer that would be flushed to the main
thread less often.

> For example enabling apps to bypass the Stream Buffer while JACK is running.

What would this mean?

Currently when the audio device (or JACK) wakes a sink up requesting for
more audio, the streams connected to that sink must have enough audio
buffered so that the request can be fulfilled immediately. There could
be a low-latency mode where there would be no stream buffer. Instead,
when JACK would request for more audio, PA wouldn't respond immediately,
but forward the request to clients, and wait for the clients to respond
to PA before PA responds to JACK. (I think this would be quite similar
to how JACK works with its clients.) I'd expect this to take a lot of
effort, but I'm not opposed to this in principle.

Another very welcome optimization would be to change the streaming
protocol so that the audio from clients wouldn't have to pass through
the main thread (this would probably mean separate sockets for control
and audio data).

> Is it a productive use of resources or is it better to recommend to
> developers to add direct support to their audio system for routing audio
> through JACK when JACK is running? That also means adding logic to JACK to
> deal with Bluez and Murphy which seems like a double up of effort when it
> is already being handled in PA.
> 
> If we go with the combination can PA manage the Bluetooth stream and
> Murphy requests while JACK is running?

Yes. JACK doesn't have other effect on PA than suspending the ALSA
devices.

-- 
Tanu