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? If the i/o block waits for a signal (e.g. IRQ), it will work just fine. >>> 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@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev