On 02/24/2011 07:01 PM, Robin Gareus wrote:
On 02/24/2011 03:59 PM, Olivier Guilyardi wrote:
Hello Robin,
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?
mmh. it depends on how the blocking is done. If it is a spin-lock it
will consume CPU and block other processes which are running at lower
priority in the meantime (but only up to sched_rt_runtime_us per second.
Other processes won't starve). Is there a poll (or select) function
available as part of the libaudio API?
I don't think there are spin locks, which would say loop until some data becomes
available, etc.. The libaudio implementation is provided by the device and/or
the harware platform (main chip) manufacturer(s), so it's rather opaque. Some of
these implementations are open source (
http://android.git.kernel.org/), but they
can differ a lot.
But to prevent problem in case some libaudio implementations use a spin lock,
then the audio server, audioflinger, could have limited realtime runtime, with
sched_rt_runtime_us, as you mention (at first I was only thinking about this for
the audio clients, not the server).
I don't know about a select function exposed by libaudio. There are only
blocking read() and write() functions AFAIK.
If the i/o block waits for a signal (e.g. IRQ), it
will work just fine.
That sounds good.
In the implementations that I saw so far, when it's not ALSA, it seems to be
some kind of OSS file-based interface. So I think that's quite safe to assume
that read/write operation are backed by an interrupt.
The one catch is that in all libaudio implementations that I saw, some mutexes
get locked in both read() and write(). Is this a problem?
I just looked into JACK1, and I see some pthread mutex being locked in
oss_driver_read(), in drivers/oss/oss_driver.c. What happens in case of a mutex
lock? Is there a context switch?
--
Olivier