[pulseaudio-discuss] Erratic behavior with asynchronous reading and writing

[Eric Thornton]

 One discovery I just made on the missing write callbacks:
If I write data to the playback stream with prebuf enabled immediately after reading it, I eventually get a write callback once the playback buffer has reached it's full mark. Does this mean I need to write zeros to the server if my write callback happens with no data in the buffer? That seems inefficient for network operation, or am I still misunderstanding something here.
Eric

     On Thursday, February 26, 2015 9:58 PM, Eric Thornton <gonesurfingnc at yahoo.com> wrote:
   

 Tanu,
Thanks for the reply.
On further examination, the segfault is happening on pa_stream_write. I've not yet figured out why. However the largest hurdle I can't seem to overcome is getting a write callback with prebuffering enabled. I understand that assigning that attribute only affects playback on the server side of the stream, but it most definitely affects write callbacks in some way I don't understand.
Output with prebuf=-1 (note 1st write callback happens before 1st read so it returns).
Stream write callback: Ready to write 384000 bytesno buffer to write: length 0 Can read     724 read     724 buffer address 0x17da0d0, length,     724Can read     724 read     724 buffer address 0x17da0d0, length,    1448Can read     724 read     724 buffer address 0x17da0d0, length,    2172Can read     724 read     724 buffer address 0x17da0d0, length,    2896Can read     724 read     724 buffer address 0x17da0d0, length,    3620Can read     724 read     724 buffer address 0x17da0d0, length,    4344Can read     724 read     724 buffer address 0x17da0d0, length,    5068
....and on and on...
Now with no prebuf attribute on write stream, I have the following output
no buffer to write: length 0 Can read     288 read     288 buffer address 0x249a0d0, length,     288Can read     104 read     104 buffer address 0x249a0d0, length,     392Can read      88 read      88 buffer address 0x249a0d0, length,     480Can read      32 read      32 buffer address 0x249a0d0, length,     512Can read      64 read      64 buffer address 0x249a0d0, length,     576Can read     104 read     104 buffer address 0x249a0d0, length,     680Can read      24 read      24 buffer address 0x249a0d0, length,     704Can read      24 read      24 buffer address 0x249a0d0, length,     728Can read      24 read      24 buffer address 0x249a0d0, length,     752Can read      24 read      24 buffer address 0x249a0d0, length,     776Stream write callback: Ready to write 437712 bytesWrote 776 of 776 bytes from 0x249a0d0freeing bufferCan read      40 read      40 buffer address 0x249a3e0, length,      40Can read      32 read      32 buffer address 0x249a3e0, length,      72
...and I things act fairly normal except for random segfaults on 2 of the 3 computers i've tested it on.

 Thanks,
Eric

     On Wednesday, February 25, 2015 12:06 PM, Tanu Kaskinen <tanu.kaskinen at linux.intel.com> wrote:
   

 On Mon, 2015-02-23 at 02:22 +0000, Eric Thornton wrote:
> All,
> 
> 
> I'm working on a basic asynchronous read/write program to understand
> the API before applying it to another piece of software.  On a read
> callback I create (or add to) a buffer, and then on write callback I
> write back as much of it as allowed. The code follows pacat.c and
> several examples I've found on Jan Newmarch's site. The main
> difference, is rather than checking for writable size and writing
> immediately following a read, piling it onto the buffer and waiting
> for write callback seems to reduce CPU load on the remote hardware
> (raspberry pi) by 50% or more.
> 
> 
> Here is the erratic behavior...
> 1)I don't get any write callbacks (after the initial one) with the
> prebuf attribute = -1. The sample buffer size continues to increment
> with nowhere to go. This is probably related to the next two issues.

The prebuf attribute shouldn't cause any segfaults, so I don't think
it's directly related to issue 3.

I didn't read your code thoroughly, but you probably don't fully
understand what the prebuf attribute does. If you set prebuf to -1, the
server will decide the value for you, and that value will be non-zero.
If the prebuf is non-zero, playback will not start until PulseAudio has
received prebuf amount of data from your application. Also, if you're
too slow to write audio after the playback has started, so that there's
an underrun on the stream, that will also trigger the prebuffering mode,
meaning that the stream is stopped until you have again written prebuf
amount of data.

> 2)If I comment out the prebuf and tlength attribute it works...
> kind-of.  I sometimes don't get sound on one computer even though the
> data on the screen indicates the program is running normally. If there
> is no sound, I can immediately ctl-c and restart and then I get sound.
> 3)On a slower computer, I get a segfault and gdb gives the following.
> I sometimes get a message about memcpy and unaligned memory.

To get better backtraces from gdb, you need to install the debug symbols
for the program and the libraries that it uses. In this case at least
the debug symbols for libpulse are not available. If you're using
Raspbian, the package name is libpulse0-dbg.

-- 
Tanu




    

   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/pulseaudio-discuss/attachments/20150227/87861b2b/attachment.html>