[pulseaudio-discuss] PulseAudio <-> ALSA issues
gmane at colin.guthr.ie
Wed Jul 9 01:10:18 PDT 2008
Wolfgang Rosenauer wrote:
> Hi Colin,
> Colin Guthrie wrote:
>>> I've also opened a bug here:
>>> 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!)
More information about the pulseaudio-discuss