[pulseaudio-discuss] Question regarding usage of pa_stream_peek() and pa_stream_drop()
Tanu Kaskinen
tanu.kaskinen at linux.intel.com
Sun Nov 17 22:39:55 PST 2013
(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.
>
> 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.
> i will upload the raw pcm file and mail the link.
Are you still planning to do that?
--
Tanu
More information about the pulseaudio-discuss
mailing list