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