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
