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

PrevNext  Index
DateWed, 22 May 2013 14:52:26 +0200
From Stéphane Letz <[hidden] at grame dot fr>
ToAdrian Knoth <[hidden] at drcomp dot erfurt dot thur dot de>
Cc[hidden] at lists dot jackaudio dot org
In-Reply-ToAdrian Knoth Re: [Jack-Devel] Fwd: [andraudio] Google I/O: High performance audio talk
Follow-UpAdrian Knoth Re: [Jack-Devel] [andraudio] Google I/O: High performance audio talk
Le 22 mai 2013 à 14:36, Adrian Knoth <[hidden]> a écrit :

> On 05/22/2013 01:35 PM, John Emmas wrote:
> 
> [http://youtu.be/d3kfEeMZ65c]
>> For those of us who don't know the history behind this (and who don't
>> want to sit through a 40 minute video) what's the underlying problem
>> here...?
> 
> I've just watched the video. Summary:
> 
>   - Android until JellyBean had no SCHED_FIFO in the kernel.
> 
>   - 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.
> 
>     The normal audio creates a submix that's fed into the fast-path
>     system. That's similar to what you have when running jackd with the
>     pulseaudio-jack modules.
> 
>   - Android has no means to deal with priority inversion
> 
>   - Google developers emphasise not to block in your audio thread
>     (surprise, surprise, that's mentioned in the JACK FAQ for years)
> 
>   - Sample rates vary among devices (some 44.1kHz, others 48kHz)
> 
>   - Hardware buffer sizes vary among devices, e.g., 240 samples/buffer
> 
>   - The last two points will be addressed by adding an API to query the
>     sample rate and buffer size (Android API level 17)
> 
>   - Google hardware team will fix kernel audio driver bugs
> 
> The guy who wrote the synthesizer finally talked about optimisations he
> had done to his application. Nothing new: Use C++ instead of Java, use
> the correct buffer size, use aligned buffers, use SIMD asm.
> 
> 
> So after all, there is hope for low-latency on Android. It already works
> on some devices, more devices will follow. For the first time, the
> architecture is similar to what's known to work on (desktop) Linux.
> 
> 
> 
> HTH

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. 

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

(BTW : on the completely Apple controlled iOS… we can still start RT threads (so "time constraints" in OSX/iOS terminology…) and JACK can start any number of clients, and low-latency audio can use all CPU, and so burn your battery in no time….. well if the *user* choose to...)

Stéphane 
PrevNext  Index

1369228186.12804_0.ltw:2, <AE06920B-6E0D-4DC7-A786-41680F8A117A at grame dot fr>