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 is clear.
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.
Takashi