On Tue, October 1, 2013 1:39 am, Paul Davis wrote: > On Mon, Sep 30, 2013 at 11:33 AM, Fons Adriaensen > <[email protected]>wrote: > >> On Tue, Oct 01, 2013 at 12:04:37AM +1000, Patrick Shirkey wrote: >> >> > The most obvious potential violator is the bridge code between PA and >> ALSA >> > because it's the one place that no one really seems to understand well >> at >> > the moment. >> >> That would then affect *all* apps using PA via ALSA (which seems >> to be the only way)... >> >> I still don't understand the purpose of all this. An application >> that can't use Jack can still connect to it using the ALSA jack >> plugin, you don't need PA for this. A quick test here shows >> that the latency in that case is as solid as it gets. >> > > the linux mobile world has partially adopted PA as a native audio API > (something PA's designer did not intend to happen). there are audio device > streams that are accessible only via PA, much as FFADO is (or was) the > only > way in or out of a firewire device. even without this, there are control > issues (related to audio "session management", i.e. when one app has to be > suspended). this may or may not have something to do with it. >
It has a lot to do with it. Bypassing PA is fine for desktop users who choose that method but it is not going to happen without major struggle and a large amount of resistance from several angles on Mobile platforms. Adding all of the above into JACK or making that functionality accessible while using JACK is unlikely to be viable for a number of fairly obvious reasons. Whereas ensuring that PA and JACK work as efficiently as technically possible IMO is an attainable and worthy goal which also makes the whole Linux Audio Stack more reliable and powerful. Either way we are not going to be able to *easily* run JACK on various mobile platforms until we address the issues. This is not my opinion, it is a stated fact coming directly from the people who are in charge of deciding the direction of Mobile Audio on such platforms. That makes it harder for open source multimedia to move onto those platforms and denies us the true potential of JACK on mobile until we do. FYI, the people I am in contact with are very supportive of the goal of running JACK and the possibilities therein but they are not going to "open the door" until various issues are resolved. Currently the priority is establishing some hard data on the total latency of the PA+JACK combination. We have got close with these tests and the good news is that we are in the same space as the current best that Android can offer. However, it can be better, more stable and we can definitely go lower. Anyway this thread is not supposed to be a discussion on for or against, it is about isolating the bottlenecks in the graph. It seems that I am the only person in the world who has the time/motivation to test the combination of PA+JACK. I only have access to one computer at this time to run the tests. Therefore we only have one data set to work from. The issues I am seeing could turn out to be entirely local in which case we would be wasting time to try and fix things that are not actually broken. At this point it would be very helpful to get some additional test results from the rest of the LAD/LAU community. Apparently I have to beg people to do that these days or maybe people are waiting for me to offer some kind of financial reward? Apparently being able to run JACK *and* sell apps on several mobile platforms is not enough incentive. -- Patrick Shirkey Boost Hardware Ltd _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/listinfo/linux-audio-dev
