On Mon, October 14, 2013 11:21 pm, Tanu Kaskinen wrote: > 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. > This is very useful insight. It seems the question now is who is going to do the actual work? Given that it is not really your interest to work on the JACK specific features it seems like it should be JACK developers who take charge of that but I suspect that they would be more inclined to work on JACK than fixing issues with PA. However as PA is the default sound system for a few mobile platforms it is also reasonable that resources could be applied to these issues from the perspective of making things as efficient and powerful as possible. I'm personally willing to work on some of the issues but I am not funded to do it so I have to find my own income and that means it can only really get done when I am not trying to pay my bills. Given the lack of genuine interest I have observed from the wider LAD community for these issues I am doubtful anyone else will move on this issue anytime soon without an incentive. However, it might be possible to convince some of the JACK devs to get involved. It's really an issue of resources and priorities. Given that these mobile platforms do not currently have significant market share it doesn't help to get people motivated. If we leave it up to JACK devs they will either do nothing or more likely extend JACK. That could end up being the best way forward but then it would mean pushing people towards JACK at the potential expense of PA development. Given the way that some people feel about PA vs JACK I'm sure that they would prefer to go exclusively with JACK over PA but it seems a bit harsh if PA can do the job and there is the option to make it happen. IMO, the simplest option that allows JACK to run on mobile platforms without causing major headaches or disruptions to the existing audio layer should be the goal. Otherwise things are gonna get messy and that doesn't need to happen because it just makes everyone look bad and provides cannon fodder for the haters. PA has received a lot of bad publicity over the years and lots of people will be eager to jump on that bandwagon again if they have the opportunity. -- Patrick Shirkey Boost Hardware Ltd
