[prev in list] [next in list] [prev in thread] [next in thread]
List: linux-audio-dev
Subject: Re: [LAD] making sense of Jack MIDI; or, is this an appropriate use for Jack?
From: Harry van Haaren <harryhaaren () gmail ! com>
Date: 2013-02-17 21:41:38
Message-ID: CAKudYbMY0d2ueozeehRRgxLQWm3cvKZ1FEXVqqTFkTWf8=nhrw () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
On Sun, Feb 17, 2013 at 9:20 PM, Paul Coccoli <pcoccoli@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.
[Attachment #5 (text/html)]
<br><br><div class="gmail_quote">On Sun, Feb 17, 2013 at 9:20 PM, Paul Coccoli <span \
dir="ltr"><<a href="mailto:pcoccoli@gmail.com" \
target="_blank">pcoccoli@gmail.com</a>></span> wrote:<br><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"> This scheme sounds error prone. In general, copying C++ \
objects via<br> memcpy (or writing them 1 byte at a time into the ringbuffer, which \
is<br> what I think you're proposing) is a bad idea. </blockquote><div>Nope, \
write them one sizeof( event->size() ) at a time.<br>I'm very interested in \
why copying C++ objects like this is a bad idea.<br>Its been discussed on list before \
(<a href="http://linux-audio.4202.n7.nabble.com/Inter-thread-Communication-Design-Appr \
oach-td68710.html">http://linux-audio.4202.n7.nabble.com/Inter-thread-Communication-Design-Approach-td68710.html</a>).<br>
This seemed to be the best simple RT safe solution. If you have suggestions / \
improvements I'd love to hear them.<br><br></div><blockquote class="gmail_quote" \
style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> JACK \
ringbuffers are<br> ideally suited to passing simple types (like floats), and not \
vairable<br> sized things (like different derived Event classes). Your enum for<br>
event types is a bit of a red flag, too. While its perfectly valid,<br>
"type flags" like this more often than not accompany inflexible,<br>
tightly coupled code (which may be fine in a small audio app, but few<br>
apps stay small).<br></blockquote><div><br> </div><blockquote class="gmail_quote" \
style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> What about \
passing pointers via the ringbuffer? </blockquote><div>Pointers to an Event? Just \
makes it more hassle to send an Event from the RT thread.<br>Involves taking X memory \
from a mem-pool, and then using placement new to construct<br> the EventPlay(), and \
then send the pointer trough the ringbuffer. More complicated IMO.<br> \
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex">To free the event objects, you could pass them back via a \
second ringbuffer so the RT<br> threads aren't responsible for deleting them.<br>
</blockquote></div>Indeed, that would be necessary. Again, more complications. That \
said, it can be done,<br>and would involve less "traffic" trough the \
ringbuffer, and also "fixed size" traffic": pointers to EventBase.<br> \
<br>
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic