[pulseaudio-discuss] PulseAudio <-> ALSA issues

[Colin Guthrie]

Wolfgang Rosenauer wrote:
> 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.

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!)

Col