[LAD] making sense of Jack MIDI; or, is this an appropriate use for Jack?

Harry van Haaren harryhaaren at gmail.com
Sun Feb 17 21:41:38 UTC 2013

On Sun, Feb 17, 2013 at 9:20 PM, Paul Coccoli <pcoccoli at gmail.com> wrote:

> 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.

Nope, write them one   sizeof( event->size() ) at a time.
I'm very interested in why copying C++ objects like this is a bad idea.
Its been discussed on list before (
This seemed to be the best simple RT safe solution. If you have suggestions
/ improvements I'd love to hear them.

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?

Pointers to an Event? Just makes it more hassle to send an Event from the
RT thread.
Involves taking X memory from a mem-pool, and then using placement new to
the EventPlay(), and then send the pointer trough the ringbuffer. More
complicated IMO.

> To free the event  objects, you could pass them back via a second
> ringbuffer so the RT
> threads aren't responsible for deleting them.
Indeed, that would be necessary. Again, more complications. That said, it
can be done,
and would involve less "traffic" trough the ringbuffer, and also "fixed
size" traffic": pointers to EventBase.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxaudio.org/pipermail/linux-audio-dev/attachments/20130217/0886cb88/attachment.html>

More information about the Linux-audio-dev mailing list