On 02/24/2011 07:01 PM, Robin Gareus wrote:
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?
Linux-audio-dev mailing list