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

Harry van Haaren harryhaaren at gmail.com
Sun Feb 17 15:35:28 UTC 2013


On Sun, Feb 17, 2013 at 3:57 AM, M Donalies <ingeniousnebbish at cox.net>wrote:

> No locks or mutexes in a callback function. I need to think about that one.
>
This is indeed a "lovely" topic for debate. I'm bound to say that, I'm
currently doing a final-year project for college on the topic.
I've came up with a solution, which I feel is the best balance between
C++-y style Event classes, and C-style simple code. Simple is great for
RT situations: its easy to see if something is RT or not.

In essence it boils down to this:
-Create an "EventBase" class            with pure virtual type() and size()
functions
-Derive actual events like "EventPlay"  overriding type() and size()
-Create a ringbuffer                    checkout the example, it uses the
JACK ringbuffer
-Create events *on the stack*           ie EventPlay eventPlay();
-Write events into the ringbuffer using jack_ringbuffer_write();

The last two steps are key, as they enfore the event gets *copied* into the
ringbuffer, and the original goes out
of scope (and gets destroyed).

This solution is very workable, on the condition that only fundamental C
datatypes are passed trough the Event class.
Things will get nasty if you pass std::shared_ptr<> objects trough it, I've
made that mistake already :)

The following code shows communication from the GUI thread to the RT
thread. Create another ringbuffer and functions
for communicating in the other direction.

https://github.com/harryhaaren/realtimeAudioThreading

HTH, -Harry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxaudio.org/pipermail/linux-audio-dev/attachments/20130217/e9ccaf9d/attachment.html>


More information about the Linux-audio-dev mailing list