20 Dec
2016
20 Dec
'16
4:09 a.m.
Dear All,
What exactly is the difference between *jack_midi_event_reserve* and
*jack_midi_event_write* ?
In particular, if I call *jack_midi_event_write*, does it actually copy
the data from the buffer, which I provide?
Or does it use that same buffer.
Another question is how can I send midi events generated from GUI,
(which does not run in the audio callback)?
My guess is to cache them somewhere and transmit them inside the callback?
Am I guessing correctly?
Cheers,
Robert
20 Dec
20 Dec
5:30 a.m.
On 20.12.2016 12:09, ROBERT WOLF wrote:
What exactly is the difference between
*jack_midi_event_reserve* and
*jack_midi_event_write* ?
In particular, if I call *jack_midi_event_write*, does it actually copy the data
from the buffer, which I provide?
For a simple MIDI message
const size_t sz = 3;
const uint8_t src [sz] = {0x90, 0x2f, 0x7f};
think of jack_midi_event_write as a convenience wrapper around
jack_midi_event_reserve and memcpy
uint8_t *dst = jack_midi_event_reserve(client, 0, sz);
if(dst)
memcpy(dst, src, sz);
else
; // no space left on buffer
which is equivalent to
if(jack_midi_event_write(client, 0, src, sz) != 0)
; // no space left on buffer
Or does it use that same buffer.
Another question is how can I send midi events generated from GUI, (which does
not run in the audio callback)?
My guess is to cache them somewhere and transmit them inside the callback?
Am I guessing correctly?
The common practice is to use lock-free single-reader/single-writer ring buffers
to exchange data between worker/GUI and audio threads.
JACK readily ships its own implementation of such a structure [1].
[1] http://jackaudio.org/api/ringbuffer_8h.html
5:31 a.m.
On Tue, Dec 20, 2016 at 11:09 AM, ROBERT WOLF <
robert.wolf(a)hercsmusicsystems.com.au> wrote:
Dear All,
Hi Robert,
What exactly is the difference between
*jack_midi_event_reserve* and
*jack_midi_event_write* ?
From my understanding:
- event_reserve() takes
"size" number of bytes from JACKs internal MIDI
buffers for a particular port, and returns the address to that buffer. Your
application can now write to that pointer, and once the RT callback is
done, JACK will transmit the data.
- event_write() takes a pointer from your application, and copies the data
pointed to into the JACK internal midi buffer. Your application can re-use
or delete the buffer you passed to the event_write() function now, as JACK
has a copy of the data.
In particular, if I call *jack_midi_event_write*, does
it actually copy
the data from the buffer, which I provide?
Or does it use that same buffer.
See above.
Another question is how can I send midi events
generated from GUI, (which
does not run in the audio callback)?
My guess is to cache them somewhere and transmit them inside the callback?
Am I guessing correctly?
<http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org>
In short: Yes. You need to transfer the MIDI data to be sent between two
threads - this can be trivial with mutexs/semaphors/locking systems, but
keep in mind that your real-time thread must *never* block. Personally, I
am a big proponent of message passing, instead of locking based systems.
To answer your question, I would use a ringbuffer (jack has a ringbuffer t)
to move a message (struct with some metadata) to transfer an event (midi
note one) between the GUI to JACK thread.
Hope that helps, -Harry
--
http://www.openavproductions.com
2682
days inactive
2682
days old
jackaudio@lists.linuxaudio.org
2 comments
3 participants
participants (3)
-
Hanspeter Portner -
Harry van Haaren -
ROBERT WOLF