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

PrevNext  Index
DateWed, 22 May 2013 15:24:58 +0200
From Adrian Knoth <[hidden] at drcomp dot erfurt dot thur dot de>
To[hidden] at lists dot jackaudio dot org
In-Reply-ToStéphane Letz Re: [Jack-Devel] [andraudio] Google I/O: High performance audio talk
Follow-UpStéphane Letz Re: [Jack-Devel] [andraudio] Google I/O: High performance audio talk
Follow-UpPatrick Shirkey Re: [Jack-Devel] [andraudio] Google I/O: High performance audio talk
Follow-UpJohn Emmas Re: [Jack-Devel] [andraudio] Google I/O: High performance audio talk
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.



Cheers
PrevNext  Index

1369229107.13531_0.ltw:2,a <519CC72A.5080202 at drcomp dot erfurt dot thur dot de>