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
