[pulseaudio-discuss] Question regarding usage of pa_stream_peek() and pa_stream_drop()

[Tanu Kaskinen]

On Thu, 2013-11-14 at 10:40 +0000, nimesh.chanchani at accenture.com wrote:
> Hi ,
> 
> I have a question regarding the usage of pa_stream_peek() and pa_stream_drop().
> 
> my usage is :
> 
> pa_stream_peek(mStreams[1], &data, &free);
> if ( data == NULL && free > 0 )
> {
>         pa_stream_drop(mStreams[1]);
> }
> else
> {
>        fwrite(data, sizeof(uint8_t), free, fpOutput);
>         pa_stream_drop(mStreams[1]);
> }

Looks good, except that errors from pa_stream_peek() aren't handled, and
the code assumes that there is data available (it's a valid assumption
if you have checked pa_stream_readable_size()).

> The problem is that sometimes i get the data and sometimes not, also when i get the data it is very noisy.

What do you mean by not getting data? Do you mean that "data == NULL &&
free > 0" or "data == NULL && free == 0"? If the former, it means that
the stream contains holes, which is pretty unusual, and I think it
should happen only if you record from a monitor source. If the latter,
then you're calling pa_stream_peek() when there's no data available, and
you should use pa_stream_readable_size() and call pa_stream_peek() only
if the readable size is greater than zero.

It's also unclear what you mean by "very noisy". Can you make an example
audio file available somewhere? PulseAudio doesn't generate any noise by
itself, so this sounds like a hardware problem, or you're using wrong
format parameters when playing back the audio.

> Now, from reading the document, it says :
> pa_stream_peek() , returns the bytes read, which may be less than the fragsize.
> also, pa_stream_drop() is used to remove the current fragment.
> 
> now my question is , since pa_stream_drop is needed to move the buffer
> forward, so that i read the next , what will happen if I call
> pa_stream_peek() , which returns partial fragment, and then call
> pa-stream_drop(), which will drop the fragment. Will this lead to data
> loss?

No, there are no "partial fragments" that you need to worry about. The
documentation could probably be improved, but I'm not quite sure how.

The server sends audio in chunks, and the size of those chunks is not
necessarily constant. Sometimes their size may be the same as the
fragsize parameter that you configured, but sometimes their size may be
something else. pa_stream_peek() always returns a full chunk, and
pa_stream_drop() always drops the chunk that was returned by
pa_stream_peek().

-- 
Tanu