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 _______________________________________________ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev