[LAD] Jack ringbuffer

Len Ovens len at ovenwerks.net
Thu Dec 10 14:51:48 UTC 2015

On Thu, 10 Dec 2015, Will J Godfrey wrote:

> On Thu, 10 Dec 2015 09:07:25 -0500
> Paul Davis <paul at linuxaudiosystems.com> wrote:
>> On Thu, Dec 10, 2015 at 9:04 AM, Will Godfrey <willgodfrey at musically.me.uk>
>> wrote:
>>> If I have a buffer size of 256 and always use a 4 byte data block, can I be
>>> confident that reads and writes will either transfer the correct number
>>> of bytes or none at all?
>> You cannot.
> Somehow I expected that would be the answer :(
> So, if I get, (say) three bytes processed, presumably I make another call for
> just one.

You can check if there are 4 bytes available, if not don't read (yet). 
Normally (at least for anything I have done) the reason I use the ring 
buffer is to divorce the data processing from any real time requirement. 
So I am reading the ring buffer in a loop, I can check how many bytes are 
available. jack_ringbuffer_read_space(buffer) can be used I think.

> Is it safe to cheat and without modifying the data block adjust the
> byte count and increment the pointer passed to jack by the appropriate amount?

I am not sure what you mean by this. You are dealing with two (or more?) 
threads that are not in sync. The Jack thread (your application's 
callback) should be running at a higher priority than the ringbuffer 
reading is. SO while it is possible the callback has not finished writing 
a 4 byte sequence at any one time, it should not be a problem to wait for 

> I'm thinking that I should only make two or three repeat attempts before
> aborting.

It would depend on jack's buffer size (and other things). There may be 
quite some time between bursts of data. But you have control of both sides 
of the ringbuffer. If you are always sure to only put 4 bytes in, you 
should always be able to get four byte chunks out that are in those same 
four byte groups if you always wait for there to be at least 4 bytes 
available for read. Both the read and write functions give number of bytes 
actually read/written which your application should verify.

Len Ovens

More information about the Linux-audio-dev mailing list