On Sat, Aug 27, 2011 at 1:08 AM, Olivier Guillion - Myriad < olivier@myriad-online.com> wrote:
Hi,
Raymond Toy rtoy@google.com wrote :
IMO, it's not a good idea to try to synchronize perfectly two processes
by way
of an interrupt. If the generating process has to remain untouched, you
should
probably bufferize its data in your own process before sending it to
writei.
It would add some latency, but make the data flow safer. Here is how it
could
work: 1- Your process writes a "magic" pattern at the end of the shared
area
2- It sends a signal to the other process to make it generate data 3-
It
checks whether the magic pattern is still here 4- When changed, it
means the
data have been calculated. It saves them to an internal circular buffer
A nice idea, but I'm not sure it will work in my scenario. The "magic" pattern could potentially be real data (the buffer contains audio
samples), so
that would cause funny, hard-to-reproduce glitches.
You are theorically right, even if I doubt that much genuine audio buffer could end with, let's say : 0x8000 0x7FFF followed by "This is magic!!!" string :)
Agreed.
Plus, I think that when I request new data, something is always written.
I thought it was asynchronous, and you just send a signal to your generating process to ask it generate data.
I'm not 100% sure, but the signal is really request to generate the next set of data and the "current" set is returned. If we call faster than necessary, we always get some data, plus calls to generate new data to be read next time. I suspect the new data is just written into a buffer, overwriting whatever was there. Hence, the problem I have if the callback requests are not regularly spaced according to the period size.
Clemens idea of a counter at the beginning of the buffer would work
nicely, but
requires changes in the generating process.
Right. But if you can modify the generating process and recompile it, there is no more problem. Can you?
Sure, but once I have to modify both, there's not point in a "magic" string. I can do what Clemens suggested.
Ray