Hi Tanu,
Thx for your response.
to clarify:
Yes, im using " pa_stream_readable_size()", to first check if there are readable bytes available.
"pa_stream_peek()" doesnt have any error codes to return, it always returns Zero.
by no data, I mean that the PCM data that gets written to the file is a flat line. that is "free > 0" and data!= NULL.
but by logs i noticed that very few bytes actually get pulled by pa_stream_peek() in each iteration like: 8, 6 , 59, 70,10 etc. to give one example. is that strange?
when I do get some data ( not a flat PCM line but noisy) , I get approx 1000 bytes pulled in each iteration by pa_stream_peek(), like 800,1600,1300,700 etc.
i'm using threaded main loop .
I am using a single context , and i'm opening 2 streams in that context ( one for playback and one for record) , will that create a problem? I'm attaching the code for your reference.
"void PulseAudioClient::Read()" is the function to lookout for. This is still a test code , so please excuse the inefficiencies.
i will upload the raw pcm file and mail the link.
________________________________________
From: Tanu Kaskinen [tanu.kaskinen@xxxxxxxxxxxxxxx]
Sent: Friday, November 15, 2013 12:36 PM
To: Chanchani, Nimesh
Cc: pulseaudio-discuss at lists.freedesktop.org
Subject: Re: Question regarding usage of pa_stream_peek() and pa_stream_drop()
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
________________________________
This message is for the designated recipient only and may contain privileged, proprietary, or otherwise confidential information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the e-mail by you is prohibited. Where allowed by local law, electronic communications with Accenture and its affiliates, including e-mail and instant messaging (including content), may be scanned by our systems for the purposes of information security and assessment of internal compliance with Accenture policy. .
______________________________________________________________________________________
www.accenture.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PulseAudioClient_test.cpp
Type: text/x-c++src
Size: 10169 bytes
Desc: PulseAudioClient_test.cpp
URL: <http://lists.freedesktop.org/archives/pulseaudio-discuss/attachments/20131115/ee45adee/attachment-0001.cpp>
