[pulseaudio-discuss] PulseAudio <-> ALSA issues

[Colin Guthrie]

Wolfgang Rosenauer wrote:
> Hi,
> 
> I have an application (which is not OSS unfortunately) using ALSA output.
> Sound works fine on systems where no pulseaudio is running but doesn't 
> work at all as soon as PA is running (Gnome desktops on latest Ubuntu 
> and openSUSE versions were tested).
> 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 believe this assumption also does not hold true for other plugins and 
perhaps even USB audio devices.

If you think this is the problem, you can have a look at the very long 
thread over on the alsa-dev mailing list:
http://comments.gmane.org/gmane.linux.alsa.devel/53841

It doesn't give a solution but highlights the problem and proposes a 
solution for the future. Hopefully if this is the problem you can alter 
the implementation accordingly.

HTHs

Col