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
