29 Feb
2016
29 Feb
'16
3:38 p.m.
Hello fellow audio developers,
I've started writing a software synthesizer in C++ (using SDL2 for
now) for kicks and giggles and ran into the problem of having the
event loop thread that listens for keyboard events communicate with
the audio callback.
Are there any recommendations for how to pass real-time events (note
on, note off, etc) to such an audio callback? I figured, this is
already a solved problem and that I could benefit from your
experiences. Maybe you know of some nice open-source C++ queue
implementation that is suitable in such a situation.
I could use some kind of "channel" (thread-safe bounded buffer
implemented using mutexes and condition variables) but I'm not sure
whether this is a good idea in this situation since the audio callback
function should avoid unnecessary delays.
I've also looked into LV2. If I implemented the synthesizer as LV2
plugin, I would get around having to solve the inter-thread
communication problem because it's the plugin host's responsibility.
But to be honest I've found this API to be a bit intimidating and I'm
not familiar with any LV2 host that would allow me to test such a
plugin. Any recommendations? Ardour?
Thanks in advance!
29 Feb
29 Feb
3:45 p.m.
On 02/29/2016 03:38 PM, Sebastian Gesemann wrote:
Hello fellow audio developers,
I've started writing a software synthesizer in C++ (using SDL2 for
now) for kicks and giggles and ran into the problem of having the
event loop thread that listens for keyboard events communicate with
the audio callback.
Are there any recommendations for how to pass real-time events (note
on, note off, etc) to such an audio callback? I figured, this is
already a solved problem and that I could benefit from your
experiences. Maybe you know of some nice open-source C++ queue
implementation that is suitable in such a situation.
I could use some kind of "channel" (thread-safe bounded buffer
implemented using mutexes and condition variables) but I'm not sure
whether this is a good idea in this situation since the audio callback
function should avoid unnecessary delays.
Mutexes are not a good idea.
http://www.rossbencina.com/code/real-time-audio-programming-101-time-waits-…
The generic solution for cases like this is a lock-free ringbuffer.
Then again, ideally you'll get both Audio and MIDI in the same callback
to begin with. JACK provides this for example.
I've also looked into LV2. If I implemented the
synthesizer as LV2
plugin, I would get around having to solve the inter-thread
communication problem because it's the plugin host's responsibility.
But to be honest I've found this API to be a bit intimidating and I'm
not familiar with any LV2 host that would allow me to test such a
plugin. Any recommendations? Ardour?
jalv, Carla, QTractor, Ardour..
A LV2 simple synth example can be found at http://lv2plug.in/book/#_sampler
HTH,
robin
8:52 p.m.
The generic solution for cases like this is a
lock-free ringbuffer.
I've also used the jack ringbuffer for this and it was easy enough.
Not that my work is a reference implementation but you can see how I
take it from a usb callback to the jack process thread here:
https://github.com/rbdrum2midi/rbdrum2midi/blob/dev/src/jackdriver.c#L281
(The process code is above at line 198, note that most of this was
lifted from the jack_keyboard source)
I've also
looked into LV2. If I implemented the synthesizer as LV2
plugin, I would get around having to solve the inter-thread
communication problem because it's the plugin host's responsibility.
But to be honest I've found this API to be a bit intimidating and I'm
not familiar with any LV2 host that would allow me to test such a
plugin. Any recommendations? Ardour?
jalv, Carla, QTractor, Ardour..
A LV2 simple synth example can be found at http://lv2plug.in/book/#_sampler 
9:05 p.m.
On Mon, Feb 29, 2016 at 7:52 PM, Spencer Jackson <ssjackson71(a)gmail.com>
wrote:
Simple tutorial on using JACK ringbuffer and C++ event class here:
https://github.com/harryhaaren/realtimeAudioThreading
The generic
solution for cases like this is a lock-free ringbuffer.
I've also used the jack
ringbuffer for this and it was easy enough. >> But to be honest I've found this API to
be a bit intimidating and I'm
>> not familiar with any LV2 host that would allow me to test such a
>> plugin. Any recommendations? Ardour?
>
> jalv, Carla, QTractor, Ardour..
+1 for Jalv, very fast turnover time, and LV2 implementation
by the lead LV2 developer: I concider it the reference implementation :)
> A LV2 simple synth example can be found at
http://lv2plug.in/book/#_sampler
I like jalv for debugging because its quite simple and quick to load.
I can run it with gdb and valgrind/callgrind without any trouble. I've
found it important to test in other hosts too though but only once its
working in jalv.
+1 again
FWIW I hope you do make an LV2 plugin version as I
rarely use
standalone synths these days.
+1, and LV2 is supported by MOD (hardware platform that runs LV2):
http://moddevices.com/ and https://vimeo.com/92739423
If you have any questions about my code I've
linked you are welcome to
ask. Also, LV2 has a ML and IRC channel and I'll be happy to offer any
advice or support there that I can too.
Same!
Cheers, -Harry
--
http://www.openavproductions.com
1 Mar
1 Mar
4:13 p.m.
Thank you all for the responses!
On Mon, Feb 29, 2016 at 9:05 PM, Harry van Haaren <harryhaaren(a)gmail.com> wrote:
Sounds good! I'll look into it...
+1 again
Yup. I see the benefit of having a synth as LV2 plugin instead of
standalone. It's more flexible and I would have to reinvent less
wheels. I just need to make friends with some of the LV2 hosts first.
Great!
Cheers!
SG
On Mon, Feb 29, 2016 at 7:52 PM, Spencer Jackson
<ssjackson71(a)gmail.com>
wrote:
Simple tutorial on using JACK ringbuffer and C++ event class here:
https://github.com/harryhaaren/realtimeAudioThreading
I've looked into JACK's ringbuffer implementation. It doesn't look too
complicated. Thank you all for suggesting it! But I'm a little bit
concerned about ISO standard compliance. According to the
multi-threading-aware update to the C11 and C++11 memory models, the
access to the ringbuffer's data (*buf) is technically a data race and
therefore invokes undefined behaviour. Only read_ptr/write_ptr are
somewhat protected (volatile). From what I understand, given the
C11/C++11 memory model, one is supposed to use "atomics" for all
read/write accesses in such situations (including *buf). But so far, I
havn't gathered much experience in this kind of lock-free programming.
The
generic solution for cases like this is a lock-free ringbuffer.
I've also used
the jack ringbuffer for this and it was easy enough. >> But
to be honest I've found this API to be a bit intimidating and I'm
>> not familiar with any LV2 host that would allow me to test such a
>> plugin. Any recommendations? Ardour?
>
> jalv, Carla, QTractor, Ardour..
+1 for Jalv, very fast turnover time, and LV2 implementation
by the lead LV2 developer: I concider it the reference implementation :) A LV2 simple synth example can be found at
http://lv2plug.in/book/#_sampler
I like jalv for debugging because its quite simple and quick to load.
I can run it with gdb and valgrind/callgrind without any trouble. I've
found it important to test in other hosts too though but only once its
working in jalv. FWIW I hope you do make an LV2 plugin version as
I rarely use
standalone synths these days.
+1, and LV2 is supported by MOD (hardware platform that runs LV2):
http://moddevices.com/ and https://vimeo.com/92739423 If you have
any questions about my code I've linked you are welcome to
ask. Also, LV2 has a ML and IRC channel and I'll be happy to offer any
advice or support there that I can too.
Same! 
4:54 p.m.
On Tue, Mar 1, 2016 at 10:12 AM, Sebastian Gesemann <s.gesemann(a)gmail.com>
wrote:
Thank you all for the responses!
On Mon, Feb 29, 2016 at 9:05 PM, Harry van Haaren <harryhaaren(a)gmail.com>
wrote:
Sadly, you still don't understand how a lock-free ringbuffer works.
The key insight to have is this:
* the calculation of what can be read and what can be written may, in
fact
be incorrect due to threading
BUT
they are ALWAYS wrong in the "safe" direction. if the calculation is
wrong
it will ALWAYS underestimate data-to-be-read and space-to-be-written.
that is: you will never attempt to read data that should not be read, and
you will never attempt to write to space that should not be written. This
is true of ALL lock-free ringbuffer designs, not just JACK's. The property
arises from the requirement that they are single-reader/single-writer. If
you violate this (e.g. attempt to move the read-ptr from the write thread
or vice versa), then all bets are off unless you use some higher level
mutual exclusion logic (which has no place in the ringbuffer itself. The
design works because in audio contexts, when you use a ringbuffer, you are
more or less guaranteed to be using a design where you keep reading and
keep writing to the ringbuffer over and over. The design cannot work for
single-shot communication where you must always collect ALL possible data
in a thread-synchronous fashion. This is not the case for audio work.
Now, that said, there are some under-the-hood issues with the actual JACK
ringbuffer code, but they have absolutely nothing to do with the high level
semantics, and that is what you're relying on. Those issues concern the use
of memory barriers, and are thus related to code-reordering not to
atomicity. Although a clean fix/patch for this would still be a good thing,
the ringbuffer's are used widely and they function as intended in almost
all situations. You need not concern yourself with this issue if you are
just starting out.
On Mon, Feb 29, 2016 at 7:52 PM, Spencer Jackson
<ssjackson71(a)gmail.com>
wrote:
Simple tutorial on using JACK ringbuffer and C++ event class here:
https://github.com/harryhaaren/realtimeAudioThreading
I've looked into JACK's ringbuffer implementation. It doesn't look too
complicated. Thank you all for suggesting it! But I'm a little bit
concerned about ISO standard compliance. According to the
multi-threading-aware update to the C11 and C++11 memory models, the
access to the ringbuffer's data (*buf) is technically a data race and
therefore invokes undefined behaviour. Only read_ptr/write_ptr are
somewhat protected (volatile). From what I understand, given the
C11/C++11 memory model, one is supposed to use "atomics" for all
read/write accesses in such situations (including *buf). But so far, I
havn't gathered much experience in this kind of lock-free programming.
The
generic solution for cases like this is a lock-free ringbuffer.
I've also used
the jack ringbuffer for this and it was easy enough. 
29 Feb
29 Feb
4:27 p.m.
On Mon, 29 Feb 2016, Sebastian Gesemann wrote:
I've started writing a software synthesizer in C++
(using SDL2 for
now) for kicks and giggles and ran into the problem of having the
event loop thread that listens for keyboard events communicate with
the audio callback.
Are there any recommendations for how to pass real-time events (note
on, note off, etc) to such an audio callback? I figured, this is
already a solved problem and that I could benefit from your
experiences. Maybe you know of some nice open-source C++ queue
implementation that is suitable in such a situation.
I have used jackd ringbuffer for that.
If you don't want to link against jack you could probably pull the code
out to use in your application. the ring buffer is a polled setup, so
every time you do some audio processing you need to check the ring buffer
to see if there are any new bytes to process.
--
Len Ovens
www.ovenwerks.net
5:53 p.m.
On Mon, 29 Feb 2016 07:27:45 -0800 (PST)
Len Ovens <len(a)ovenwerks.net> wrote:
On Mon, 29 Feb 2016, Sebastian Gesemann wrote:
Another vote for jack ringbuffer. I've found it very reliable
and easy to
implement.
--
Will J Godfrey
http://www.musically.me.uk
Say you have a poem and I have a tune.
Exchange them and we can both have a poem, a tune, and a song.
I've started writing a software synthesizer
in C++ (using SDL2 for
now) for kicks and giggles and ran into the problem of having the
event loop thread that listens for keyboard events communicate with
the audio callback.
Are there any recommendations for how to pass real-time events (note
on, note off, etc) to such an audio callback? I figured, this is
already a solved problem and that I could benefit from your
experiences. Maybe you know of some nice open-source C++ queue
implementation that is suitable in such a situation.
I have used jackd ringbuffer for that.
If you don't want to link against jack you could probably pull the code
out to use in your application. the ring buffer is a polled setup, so
every time you do some audio processing you need to check the ring buffer
to see if there are any new bytes to process.
--
Len Ovens
www.ovenwerks.net
3531
days inactive
3532
days old
linux-audio-dev@lists.linuxaudio.org
7 comments
7 participants
participants (7)
-
Harry van Haaren -
Len Ovens -
Paul Davis -
Robin Gareus -
Sebastian Gesemann -
Spencer Jackson -
Will Godfrey