Re: [LAD] Jack ringbuffer

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

> On Thu, 10 Dec 2015 09:07:25 -0500
> Paul Davis <paul@email-addr-hidden> wrote:
>
>> On Thu, Dec 10, 2015 at 9:04 AM, Will Godfrey <willgodfrey@email-addr-hidden>
>> 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
it.

> 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
www.ovenwerks.net
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev