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

[nimesh.chanchani at accenture.com]

Hi Tanu,

I recorded with 8000 hz mono, to reduce the file size. its uploaded.
http://www.filedropper.com/28_4 ( < 1 MB)

i tried to attach it, but it didnt work

please see other comments inline.

Regards,
Nimesh
________________________________________
From: Tanu Kaskinen [tanu.kaskinen at linux.intel.com]
Sent: Monday, November 18, 2013 12:09 PM
To: Chanchani, Nimesh
Cc: pulseaudio-discuss at lists.freedesktop.org
Subject: Re: [pulseaudio-discuss] Question regarding usage of pa_stream_peek() and pa_stream_drop()

(Please don't top-post on mailing lists. See
http://en.wikipedia.org/wiki/Posting_style for an explanation about what
I mean by that.)

On Fri, 2013-11-15 at 11:10 +0000, nimesh.chanchani at accenture.com wrote:
> 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?

Yes, that's strange, if those are the actual numbers. I think the size
should always be a multiple of 4 bytes, since the sample format is 16
bits and it's a stereo stream, so the frame size is 4 bytes.

Nimesh>>These numbers were only for illustration, what i actually wanted to highlight was the magnitude of the number of bytes read.

>
> 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.

Having two streams is no problem.

> "void PulseAudioClient::Read()" is the function to lookout for. This
> is still a test code , so please excuse the inefficiencies.

Read() doesn't lock the mainloop properly. You need to lock it whenever
you access objects outside the mainloop thread. Read() accesses the
stream object for the first time in the pa_stream_cork() call.

Nimesh>>Thanks for pointing that out. But there is a strange thing that i notice, after I lock the mainloop before calling pa_stream_cork().

The Flush function , doesn't receive a succede  callback , and I keep waiting in the while loop.
, if I move the mainloop lock to its original position in the code , i get the flush succede callback.

> i will upload the raw pcm file and mail the link.

Are you still planning to do that?

--
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