[pulseaudio-discuss] unable to play very small beep (.wav) sounds

[Tanu Kaskinen]

On Mon, 2011-08-22 at 17:05 +0530, Himanshu Chug wrote:
> From protocol-native.c handle_seek( ) function we are getting rewinds due to
> rewrite on the condition when sink's read index is greater than write index,
> 
> The comment says "  /* OK, the sink already asked for this data, so let's
> have it ask us again */
> 
>          indexr = pa_memblockq_get_read_index(s->memblockq);
> 
>         if (indexw < indexr) {
>             /* OK, the sink already asked for this data, so
>              * let's have it usk us again */
> 
>             pa_log_debug("Requesting rewind due to rewrite.");
>             pa_sink_input_request_rewind(s->sink_input, (size_t) (indexr -
> indexw), TRUE, FALSE, FALSE);
>         }
> 
> 
> as per my understanding,
> PA is going to write audio buffers on write index and update write index
> after every write.
> ALSA sink is going to read audio buffers from read index and update the read
> index after every read.
> 
> here we are rewinding back (indexr - indexw) size due to PA rewrite, but
> practically what causes the situation where indexr > indexw ??
> 
> 1. Is ALSA not in Sync (to slow or too fast) in reading the buffers ?

No, alsa doesn't have to sync itself with anything in Pulseaudio,
pulseaudio syncs to alsa.

> 2. Is gst-plusesink not giving enough buffers in time when ALSA needs ?

Apparently that's not the case, or at least the code path that you
pasted is not itself an indication of this happening. The handle_seek()
function is called as a reaction to some event from the client, not when
alsa asks for more data. handle_seek() contains the check
"s->sink_input->thread_info.underrun_for > 0". If that would evaluate to
true, then that would mean that gst-pulsesink isn't providing data fast
enough, but the code that you pasted is in the else branch.

> 3. or something else ?

I'm betting on this.

> 4. handle_seek( ) called  , why we need to seek streams in a smooth playback
> scenario ? the same function is not called from pacmd play-file scenario and
> the beep worked fine always here?

I'd guess this is some peculiarity of Gstreamer. I don't see any need
for doing seeking either during simple playback.

There seem to be five call sites for handle_seek(), let's inspect those.


Line 1440: This code is executed when the client writes a chunk, or when
the client requests a seek to be done, or a combination of these (ie.
the client writes a chunk to some other position than the end of the
previous chunk).

There's some complexity for handling the case when multiple writes or
seeks are pending. The objective seems to be delay calling handle_seek()
until there are no more queued write or seek events. The indexw
parameter of handle_seek() will be set to the lowest windex of all
overlapping events. The windex of a single event is the write index
before handling the event if the client didn't request a backward seek,
or if the client did request a backward seek, then the windex of the
event is the seek target.

So handle_seek() is called always when the client has written a chunk of
data or requested a seek. If there's no underrun, the indexw parameter
can only be less than the read index if the client did a backward seek
beyond the read index.

If gst-pulsesink does backward seeks, I don't know why. I don't see any
reason for it when just playing back a file.


Line 1474: This code is executed when the client requests draining (play
the currently buffered data and send a signal when finished), flushing
(drop all currently buffered data), or toggling the prebuffering status.
None of these cases moves the write index anywhere, so the indexw
parameter of handle_seek() will be the current write index. It can be
less than the read index only if there's an underrun, so the code that
you pasted should never get executed in these cases.


Lines 1481 and 1488: These are the same case as 1474, repeated for
synchronized streams.


Line 1521: This code is executed when the sink input state changes. Here
again the write index can't move anywhere, so the only way it can be
less than the write index in handle_seek() is underrun, so the code that
you pasted should never get executed due to sink input state changes.


Conclusion: if I didn't make mistakes above, then gst-pulsesink is doing
backward seeks for some reason. I don't have any ideas for what that
reason might be.

> Attached are the PA logs for beep (click.wav) playback 1. working fine with
> pacmd play-file 2. Not working with gst-launch

Strange log. I wonder if you're being bitten by the broken rewind
handling during corking/uncorking that Wang Xingchao fixed recently. For
example, on line 37 of your log a rewind request is done due to corking.
The request doesn't seem to get handled. I guess you're not running the
most recent Pulseaudio version from git? The relevant patch is this:
http://cgit.freedesktop.org/pulseaudio/pulseaudio/commit/?id=2f55da5baa0323af76510fd07c540f6dafcf1ac0

-- 
Tanu