Re: [LAD] Realtime threads and security

Hello Robin,

On 02/23/2011 08:28 PM, Robin Gareus wrote:
> On 02/23/2011 11:22 AM, Olivier Guilyardi wrote:
>> Hi,
>>
>> On 02/17/2011 10:53 PM, Robin Gareus wrote:
>>
>>> /proc/sys/kernel/sched_rt_runtime_us
>>> /proc/sys/kernel/sched_rt_period_us
>>>
>>> <kernel-source>/Documentation/scheduler/sched-rt-group.txt
>> There's something which confuses me. But I'm not sure how this realtime period
>> settings relate to the audio I/O period.
>
> It only does iff the audio-I/O thread (or process) is executed with
> realtime privileges (`man chrt` - man `pthread_setschedparam` ).

Hmm.. realtime privileges are a given in this discussion. Yes, the idea is to
have the audio I/O thread run in realtime, and access the audio hardware through
the Android audio HAL, namely libaudio, instead of say, ALSA.

ALSA actually is the backend of libaudio on certain devices, but only a
minority. So, for more portability, I'm investigating whether it would be
possible to read and write using the libaudio API from a realtime thread.

> if you have a RT_PREEMPT kernel you can also raise the priority of the
> audio-device interrupt handler.

I need to look at that, but I'm not sure if this is relevant in the case of
libaudio, as it is when using ALSA. The audio hardware which is integrated into
these all-in-one chips seems to be sometimes very different from conventional
soundcards. And in many cases there are rather non standard kernel drivers under
libaudio. So I'm not sure whether one can think in terms of interrupts on
Android mobile systems. But I suppose it makes sense in the majority of cases.

> Well, it's a bit more complex than that.. not sure if you can go that
> way on Android easily.

Since you mention realtime privileges above, I suspect some confusion here.

This discussion is not about capturing and playing audio using the Android
public API. It is about improving low level Android audio support, by:

- either writing some patches for the mainstream Android source code

- or dropping some external module on systems where the user has acquired
superuser privileges (rooted devices).

For the later, what module? Well, this could for example be JACK. This should be
possible to a certain extent.

Now, say I'm only focusing on playback now. Is there something wrong with
calling a blocking output API from a realtime thread as I ask below?

>> On Android, the closest that one can get to hardware in a more or less portable
>> way is libaudio [1]. It's Android's audio HAL. This API exposes blocking read()
>> and write() calls, with fixed buffer sizes (input and output buffer sizes
>> generally do not match, but that's another problem).
>>
>> So, this may be a silly/newbie question, but can one access this blocking API
>> from a realtime thread? What will happen when it blocks? How does the read/write
>> period relate to sched_rt_period_us?
>>
>> [1] http://source.android.com/porting/audio.html

--
  Olivier
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev