[pulseaudio-discuss] PulseAudio <-> ALSA issues

[Wolfgang Rosenauer]

Hi Colin,

Colin Guthrie wrote:
>> I've also opened a bug here:
>> https://bugzilla.novell.com/show_bug.cgi?id=405354
>>
>> I've rewritten some of the Alsa-using code to fix some issues which were 
>> in the application but in its current state I can't think of a major 
>> issue in the app which would cause PA to fail.
>> alsa lib doesn't return an error in any of it's calls but sound simply 
>> doesn't start while it should.
>>
>> The device seems to be initialized correctly and PCM stream is written 
>> to the buffer but stream never starts. The pulse audio config thingy is 
>> showing the application and offers a volume control for it but that's it.
>>
>> Anyone has any hints for me please?
> 
> While I don't see anything in the bug report's attachment about calls to 
> snd_pcm_delay(), you do mention it in a comment.
> 
> I suspect you are making the same mistake that the wine people have made 
> with regards to this function. It should return a delay that the 
> application should expect before a sample played now is actually heard. 
> It has been used incorrectly by some implementations to check whether a 
> queued sample has been fully output: i.e. when the function returns 0, 
> the sample has finished playing as there is no delay left. This is not 
> actually a correct use of the function. Wine people got this wrong, as 
> have several others. This is in part due to the high level documentation 
> of the function in the alsa docs mentioned in the implementation details 
> with reference to frame pointers. From this implementation (used for 
> hardware devices) it is only a small logical step to assume that it will 
> eventually return 0.
> 
> When used with a pulseaudio, advanced latency information is included in 
> the return value and it will rarely (if ever) return 0.

I don't think that's the issue in my case.
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.

Thanks anyway,
  Wolfgang