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

[Harry van Haaren]

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 (
http://linux-audio.4202.n7.nabble.com/Inter-thread-Communication-Design-Approach-td68710.html
).
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
construct
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>