On Sun, Feb 17, 2013 at 10:35 AM, Harry van Haaren
This scheme sounds error prone. In general, copying C++ objects via
memcpy (or writing them 1 byte at a time into the ringbuffer, which is
what I think you're proposing) is a bad idea. JACK ringbuffers are
ideally suited to passing simple types (like floats), and not vairable
sized things (like different derived Event classes). Your enum for
event types is a bit of a red flag, too. While its perfectly valid,
"type flags" like this more often than not accompany inflexible,
tightly coupled code (which may be fine in a small audio app, but few
apps stay small).
What about passing pointers via the ringbuffer? To free the event
objects, you could pass them back via a second ringbuffer so the RT
threads aren't responsible for deleting them.
Linux-audio-dev mailing list