(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
