Re: [Jack-Devel] [andraudio] Google I/O: High performance audio talk

On Wed, May 22, 2013 11:24 pm, Adrian Knoth wrote:
> On 05/22/2013 02:52 PM, Stéphane Letz wrote:
>
>>>   - Android now uses SCHED_FIFO and CGROUPS with 5% budget for
>>>     low-latency audio while normal audio runs with SCHED_OTHER
>>>     (low-priority). They use the term "fast-path" for low-latency
>>>     access to the audio hardware. Fast-path requires OpenSLES C++ code,
>>>     no Java code.
>
>> I've understood (perhaps incorrectly) that this SCHED_FIFO mode is
>> *only* possible in *their* code, so that not other code could start
>> threads with SCHED_FIFO.
>
> He said (copy&paste from the transcript):
>
> "For now, it's important to understand that SCHED_FIFO priority only
> applies to threads that are created by the audio system. You can't do it
> for your own threads. So that means if you want the lowest latency, you
> need to run your audio code on an audio thread. In practice, that means
> you need to do your processing in a buffer callback. That means writing
> your sound engine in C++ and using OpenSLES."
>
>
> While this is certainly simply for applications, the question is whether
> JACK is considered an application or part of the audio system. Either
> way, it would probably be possible to write a JACK backend that's
> invoked by such a buffer callback.
>
>
>> SCHED_FIFO is required for the RT thread in JACK server and in each
>> JACK client. And with this overall limitation of 5% budget for
>> low-latency stuff, we are not going to do anything interesting in the
>> near future...
>
> He said it was raised, but never told the actual value.
>
>
>> (BTW : on the completely Apple controlled iOS…
>
> Yeah, it's a shame.
>

In addition they appear to be making decisions about what we can and
cannot do with Linux Audio tools and software without even trying to
canvas the professional Linux Audio community for their feedback on what
would be useful or necessary for our needs.

They seem to want to have a near monopoly on the mobile market but exclude
professional Linux Audio companies from having any input on the
development process.

The whole thing seems like a few people playing with their toys in their
spare time on Googles coin while the rest of us have to sit back and wait
for them to get their ducks in a row. It's been 4 years of waiting and
they are now arguing that they don't even have to worry about the concerns
that the rest of the Linux Audio Development community has identified
including but not limited to running JACK and/or Pulse Audio.

What we have now is a couple of people deciding things on everyone elses
behalf when the parent company that pays their salaries has directly
expressed their support for making Android a flexible platform that anyone
can work with*.

*http://www.wired.com/business/2013/05/exclusive-sundar-pichai-reveals-his-plans-for-android/




--
Patrick Shirkey
Boost Hardware Ltd

1369230896.14654_0.ltw:2,a <55165.89.47.0.197.1369230887.squirrel at boosthardware dot com>