linuxaudio.org

On 02/24/2011 07:01 PM, Robin Gareus wrote:

quoted text
> 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
_______________________________________________

Linux-audio-dev mailing list

Linux-audio-dev@lists.linuxaudio.org

http://lists.linuxaudio.org/listinfo/linux-audio-dev