On Thu, 10 Dec 2015, Will J Godfrey wrote: 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. 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. 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

On Thu, 10 Dec 2015, Will J Godfrey wrote: On the input end of the ringbuffer we put a set number of bytes into the buffer. This is done during the time our app has it's time to do whatever it is going to do in that jack period. But this callback might be running on another core than the rest of the app and so it is possible that the write event may be only partly done when our app looks at the buffer. That is why it is not known that if there is data there it has all been written. However, the call back is a RT thread and so it will finish the write "real soon". So there should be an event's worth of bytes by the time you look at it a second time. A time out does not really make sense that I can see. I don't think the ring buffer is un reliable. But, don't read till all the bytes are there. The answer to your question of how the pointer is updated, does't matter really. What matters is if everything that goes in gets to the output. So if one checks that the right number of bytes are there before reading, it doesn't matter. The safe way to do things might be to update the pointer after each byte written. The least code way/cpu way may be to write n bytes then update. But Paul's answer seems to indicate the first is true... but, the buffer can be written to manually too, where the input manually inserts a byte at a time and updates the pointers after each byte. The API allows that from what I can tell. In fact, if the calling SW wanted to, it could write 10 bytes and only update the pointer 3, write another 3 and then update the pointer 10 (I can't see any sane SW doing so). But you have control of both the input and the output, so you can make sure the event based input API is used rather than a manual method. The jack ringbuffer does not force you to code in a sane manner, but you can still choose to code in a sane manner if you want to. In general, jack does things in chunks. It starts doing things at the beginning of a period going through all it's call backs and when finished it does nothing till the beginning of the next period. On a single core system, it is this time when your application will be looking at the non-RT end of the ringbuffer. So in general, so long as the RT end can always access the right number of bytes when it needs to, everything will work.... nothing will be lost. Someone will correct all my mistakes I am sure. My own code, after having thought this through in answer to your question, does not do enough checks at all :) I need to go back and fix some things. Oddly enough, it does work :) My particular code is all MIDI events and so those events are various sizes, not all 4 bytes. I started off with more than one ringbuffer for each expected event size. This meant I had to do my sorting in RT, so I have now gone to one buffer and parse it on the output. With one, two or three byte events, I can easily look for the right number... I pull one byte, parse it and know I have it all or expect one or two more. However, I do use sysex events as well so I have to look for an eox. Len goes back to redo a big chunk of his code. I must be missing at least some events. -- Len Ovens www.ovenwerks.net