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>