Erratic behavior with asynchronous reading and writing

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Linux Audio Users]     [AMD Graphics]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux