[alsa-devel] Playback Devices in PREPARED State Throw Off POLLOUT Events?
tiwai at suse.de
Tue Apr 10 12:06:01 CEST 2007
At Mon, 09 Apr 2007 07:46:47 -0500,
Jeff Rush wrote:
> 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.
When the playback PCM is in the PREPARED state, it's actually ready
for getting data and trigger. Thus poll() returns POLLOUT. Its logic
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.
More information about the Alsa-devel