Re: [LAD] JACK + PA Latency

On Tue, October 1, 2013 1:39 am, Paul Davis wrote:
> On Mon, Sep 30, 2013 at 11:33 AM, Fons Adriaensen
> <fons@email-addr-hiddenwrote:
>
>> 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
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev