[alsa-devel] Playback Devices in PREPARED State Throw Off POLLOUT Events?

[Jeff Rush]

Takashi Iwai wrote:
> At Mon, 09 Apr 2007 07:46:47 -0500,
> Jeff Rush wrote:
>>
>> I thought a device was idle in the PREPARED state, and you had to either set 
>> the start conditions and write data, or explicitly invoke snd_pcm_start().  In 
>> my case, I wanted to use snd_pcm_start() once I had data to send, and also 
>> used the start conditions, set at 50%, to cause the audio output to them 
>> proceed to the speaker.
> 
> When the playback PCM is in the PREPARED state, it's actually ready
> for getting data and trigger.  Thus poll() returns POLLOUT.  Its logic
> is clear.

Is this the purpose of the "tick" value that can be manipulated by the ALSA 
API - in that every "tick" the poll() function will return with POLLOUT to 
check for more data to be sent?

I've read the ALSA docs very carefully, and while they document the arguments 
and have one-liner descriptions, how the start/stop/tick/etc. pieces interact 
behind the scenes, the semantics as it were, isn't always clear to me.


> I think you should change the program design.  The data should have
> been prepared before poll.  Or, if the flow is like:
> 	poll -> fetch data -> write data
> then you need some error control between fetch data and write data,
> for example, simply wait some time when no data is ready.

Thanks, I've got it working now.  The application is for screencasting, where 
I want to grab both the mic input on which I'm speaking, merged with the 
"monitor" input back from the output of my sound card, and then deliver that 
to my headphones so I can hear myself, and also save it via a popen() pipe 
into the "sox" utility and then on to a .wav, mp3, or ogg file.

I get the monitor audio by running the PulseAudio software, which can export 
an ALSA input device that represents what is being played out the system 
speakers by other ALSA, OSS or ESD client programs.

However, since this monitor audio isn't running all the time, i.e. there isn't 
always something making system sounds so there are too few POLLINs, but the 
microphone -is- always running with silence or voice, I handled the case of 
POLLOUTs for the headphones by always having at least microphone data to feed 
it.  Essentially the mic POLLINs 'smooth out' the overall timing.

-Jeff