Ok, I understand how it works now.
Having controlled underruns and overruns is ok. Although, I guess the way you try to do it is also okay.
When you basically would get a write overrun, you can do
skip([number]), although, you might not have the luxury to retry, so the write might be lost, hmm. That’s probably why ALSA can go for overrun and notifies you.
Looking at the code I don’t understand how
write is notified that a
1 [write full circle] 1 [write] 1
2 [read] 2 2 [how does write know that it can write over this?]
3 - nowhere to write, skip(1) -> 3 [read] - still reading, write() executed -> 3 [read]
4 4 4
I guess depends on what you want to do with the ring buffer, the API in general is ok.
Although, when you want to have every write be recorded and only skip reads when an overrun occurs(that’s usually the desired behavior with live audio streaming - the buffer is limited but you want every write to be recorded), the API might limit you on this part.
You could look at it this way: The idea of this
RB is that it won’t do overruns and underruns, it has its usecases, you decide if it fits your use case.
Althought, I think you can have both.
read with overruns and underruns,
read_blocking without overruns and underruns.