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

[Jeff Rush]

A question re normal internal operation of ALSA.

I'm using the poll() interface to wait for a audio playback device to ask for 
more samples.  The device is in the PREPARED state, not RUNNING state.  At the 
beginning of my program, _before_ I write any samples to it, I'm getting 
repeated POLLOUT events, when I do not yet have data available to send.  They 
seem to come frequent enough to load down my CPU, rather than every N ticks, 
so it seems.

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.

The output snd_pcm_status_dump() right after exiting from the very first 
poll() ever in the program shows the following, and that I have a POLLOUT 
event pending.

  --- Status of Headphones Player --- 

   state       : PREPARED 

   trigger_time: 0.000000 

   tstamp      : 1176119509.658821000 

   delay       : 0 

   avail       : 2400 

   avail_max   : 0 

 

POLLOUT fired, calling ready_for_write() 


I suppose I could force it back to an earlier state like SND_PCM_STATE_OPEN or 
SND_PCM_STATE_SETUP, but that seems a bit harsh, since the snd_pcm_hw_params() 
takes it to the SND_PCM_STATE_PREPARED itself.

Thanks for any tips,

-Jeff