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
