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

Le 22 mai 2013 à 15:24, Adrian Knoth <[hidden]> a écrit :

> 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.

This would work for the server side : JACK backed triggering the graph scheduling, running in this audio TR thread. This would not work on client side, where the RT thread actual activation it triggered by the previous client in the graph activation chain.  So libjack (client side) has to create this thread itself, and setup the thread activation (suspend/resume) logic (typically using inter-process semaphores).

Stéphane

1369230599.14525_0.ltw:2, <432693AC-C768-4D00-9D42-FE08C920196C at grame dot fr>