linuxaudio.org

--e0cb4efe3444addbc304d5ed5b07

Content-Type: text/plain; charset=ISO-8859-1
On Sun, Feb 17, 2013 at 3:57 AM, M Donalies wrote:
> No locks or mutexes in a callback function. I need to think about that one.

quoted text
>

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

Content-Type: text/html; charset=ISO-8859-1

Content-Transfer-Encoding: quoted-printable
On Sun, Feb 17, 2013 at 3:57 AM, M Donalies <ingeniousnebbish@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 fo=

r 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 essenc=

e it boils down to this:

-Create an "EventBas=

e" class=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 with pure virtual type() and=

 size() functions-Derive actual events like "EventPlay"=A0 ov=

erriding type() and size()

-Create a ringbuffer =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 checkout the ex=

ample, it uses the JACK ringbuffer-Create events *on the stack*=A0=A0=

=A0=A0=A0=A0=A0=A0=A0=A0 ie EventPlay eventPlay();-Write events into th=

e 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 outof scope (and gets destroyed)=

.This solution is very workable, on the condition that only fundame=

ntal 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 com=

munication from the GUI thread to the RT thread. Create another ringbuffer =

and functions

for communicating in the other direction.https://github.com/harryhaaren/real=

timeAudioThreadingHTH, -Harry
--e0cb4efe3444addbc304d5ed5b07--