[pulseaudio-discuss] PulseAudio <-> ALSA issues

[Wolfgang Rosenauer]

Hi Colin,

Colin Guthrie wrote:

>> I use snd_pcm_delay() actually to get an idea how long/big our buffer 
>> still is to tell the stream delivery to send data to a second (software) 
>> buffer. So I get the buffered frames from alsa's buffer to know how many 
>> frames are in my queue before requesting more data from the audio stream.
>> The application never waits to hit a delay of 0.
>>
>> That doesn't explain my observations anyway since I can verify that I 
>> write via snd_pcm_writei() while the PCM is in PREPARED state what 
>> should trigger the sound output. But I can't hear anything and following 
>> calls to snd_pcm_delay() and snd_pcm_avail_update() show that the delay 
>> is always the buffer size and doesn't change. That suggests that the 
>> actual sound output never starts.
> 
> Do you write a little data and wait for it to start? Or do you just pump 
> data in and analyse it later. The reason I ask is that IIRC pulse will 
> not start playing until a minimum buffer size is reached, so if you only 
> put in a couple samples it probably wont start playing.
> 
> Try pumping in more data first.
> 
> (Apologies if I've got this wrong, I'm going from memory of other 
> peoples comments - which I can't testify to in the first place, let 
> along guarantee the quality of my own memory!)

You were basically right and you are still with that also.
The issue was that we relied on snd_pcm_delay() to stay smaller than 
200msecs. When it got bigger we stopped feeding data to the alsa buffer 
since we actually thought the buffer is full (which isn't the case as 
you wrote) and so we got stuck :-(

Thanks for the help. The app is running fine now with pulse.

Wolfgang