26 Dec
2010
26 Dec
'10
2:05 a.m.
Hi,
I've been trying to come up with a nice program architecture for a live
performance tool (Audio looping etc),
and I've kind of hit a wall:
Input will be taken via OSC, the "engine" will be written in C++, and the
GUI is up in the air.
I've written most of the engine, (working to a degree needs some bugfixes),
and now I've started implementing
the GUI in the same binary. Ie: its all compiled together, double-click it
and it shows on screen & loads JACK client.
The GUI code has a nasty habit of segfaulting.. which is also killing the
engine. That's a no-go for live performance.
The engine is rock solid stable. So its the fact that there's the GUI thread
running around that's segfault-ing things.
So I'm wondering if it feasible to keep the audio/other data in SHared
Memory, and then write the GUI in Python reading
from the same memory? Is this concidered "ugly" design? I have no experience
with SHM, so I thought I'd ask.
The other option I was concidering is writing the front-end GUI part using
only info obtained from OSC, but that would
exclude the waveforms of the audio, and lots of other nice features...
Help, advice, laughter etc welcomed :-) -Harry
26 Dec
26 Dec
9:22 a.m.
On Sunday 26 December 2010 02:05:03 Harry Van Haaren wrote:
Hi,
I've been trying to come up with a nice program architecture for a live
performance tool (Audio looping etc),
and I've kind of hit a wall:
Input will be taken via OSC, the "engine" will be written in C++, and the
GUI is up in the air.
I've written most of the engine, (working to a degree needs some bugfixes),
and now I've started implementing
the GUI in the same binary. Ie: its all compiled together, double-click it
and it shows on screen & loads JACK client.
The GUI code has a nasty habit of segfaulting.. which is also killing the
engine. That's a no-go for live performance.
The engine is rock solid stable. So its the fact that there's the GUI
thread running around that's segfault-ing things.
So I'm wondering if it feasible to keep the audio/other data in SHared
Memory, and then write the GUI in Python reading
from the same memory? Is this concidered "ugly" design? I have no
experience with SHM, so I thought I'd ask.
The other option I was concidering is writing the front-end GUI part using
only info obtained from OSC, but that would
exclude the waveforms of the audio, and lots of other nice features...
You could do both: Connect the gui via OSC for general usage and define a
shared memory for the big-data for local usage. If your engine is that rock-
stable, you might want to run it on a headless machine and control it via OSC.
Which allows the gui to run on any win/linux/mac/ipad/ipod/galaxy
tab/whatever. And once the shmem is working, you can try to port some of that
to osc too.
Have fun,
Arnold
11:57 a.m.
Hi,
On Sun, Dec 26, 2010 at 8:22 AM, Arnold Krille <arnold(a)arnoldarts.de> wrote:
And once the shmem is working, you can try to port some of that
to osc too.
Is it acceptable to be sending ±4 sec worth of float samples across OSC? It
sounds like quite a bit of data,
esp if the sampling rate goes upwards to 96... :-)
If that's possible I'll definatly be doing that, the reason I tried the
"same-binary" approach was I presume that
doing the OSC transfer of lots of data was a bad idea.. I have no reason to
like SHM, I've never used it and it
doesn't scale if I want to run on two different machines. Which was the
reason to control using OSC in the first place!
Summing up: Large data ( ±384,000 samples of float type ) OK to send with
OSC?
Thanks for the swift reply! -Harry
12:20 p.m.
On Sun, Dec 26, 2010 at 10:56:59AM +0000, Harry Van Haaren wrote:
Summing up: Large data ( ±384,000 samples of float
type ) OK to send with
OSC?
Depends entirely on if the delay is acceptable or not. You can send it as
a binary blob - encoding each sample would be quite a waste of time.
Ciao,
--
FA
There are three of them, and Alleline.
1:37 p.m.
On Sun, Dec 26, 2010 at 11:20 AM, <fons(a)kokkinizita.net> wrote:
Depends entirely on if the delay is acceptable or not.
You can send it as
a binary blob - encoding each sample would be quite a waste of time.
I should have specified: The data will be the Sample played back by the
engine,
and it will be sent to the GUI, to be able to show the waveform / spectral
etc info.
IMO: Delay acceptable yes. Binary blob is good advice, thanks.
Ill try it out when I get some time, and will report back.
-Harry
2:02 p.m.
On Sun, Dec 26, 2010 at 12:37:47PM +0000, Harry Van Haaren wrote:
On Sun, Dec 26, 2010 at 11:20 AM,
<fons(a)kokkinizita.net> wrote:
One thing to consider: sending such large blocks of data may block
the sender, so you should not do this from the RT audio processing
thread.
Ciao,
--
FA
There are three of them, and Alleline.
Depends entirely on if the delay is acceptable or
not. You can send it as
a binary blob - encoding each sample would be quite a waste of time.
I should have specified: The data will be the Sample played back by the
engine,
and it will be sent to the GUI, to be able to show the waveform / spectral
etc info.
IMO: Delay acceptable yes. Binary blob is good advice, thanks.
5 p.m.
On Sunday 26 December 2010 14:02:49 fons(a)kokkinizita.net wrote:
On Sun, Dec 26, 2010 at 12:37:47PM +0000, Harry Van
Haaren wrote:
Another thing: OSC is generally sent per udp. The bigger the datagram, the
less likely it is actually sent and received. If you encounter this, either
split the data into smaller chunks to be sent or use the osc to define a tcp-
connection for the big binary data.
Include avahi/bonjour/zeroconf into your equation and it will be the cure for
cancer or something equally cool.
Have fun,
Arnold
On Sun, Dec 26, 2010 at 11:20 AM,
<fons(a)kokkinizita.net> wrote:
One thing to consider: sending such large blocks of data may block
the sender, so you should not do this from the RT audio processing
thread. Depends entirely on if the delay is acceptable or
not. You can send it
as a binary blob - encoding each sample would be quite a waste of
time.
I should have specified: The data will be the Sample played back by the
engine,
and it will be sent to the GUI, to be able to show the waveform /
spectral etc info.
IMO: Delay acceptable yes. Binary blob is good advice, thanks. 
27 Dec
27 Dec
12:51 p.m.
On 12/26/2010 01:37 PM, Harry Van Haaren wrote:
On Sun, Dec 26, 2010 at 11:20 AM, <fons(a)kokkinizita.net
<mailto:fons@kokkinizita.net>> wrote:
Depends entirely on if the delay is acceptable or not. You can send
it as
a binary blob - encoding each sample would be quite a waste of time.
I should have specified: The data will be the Sample played back by the
engine,
and it will be sent to the GUI, to be able to show the waveform /
spectral etc info.
IMO: Delay acceptable yes. Binary blob is good advice, thanks.
If you want to display a live waveform/spectrum while receiving data through
OSC, then I recommend that each packet is timestamped, so that you can
synchronize the graphics with audio output.
Also, if you don't need sample-level zooming in your waveform, you could send
peaks of blocks of a fixed size. Streaming the entire sample data through OSC
could be heavy IMO. Similarly, for the spectrum, you could compute it in the
engine, and send frequency peaks through OSC.
But for all that, you'll need accurate timestamps for each packet. Such accurate
timestamps can be tricky to produce. I made a small library for this purpose:
http://code.google.com/p/libtimefilter/
--
Olivier
9:32 p.m.
On Sat, Dec 25, 2010 at 8:05 PM, Harry Van Haaren <harryhaaren(a)gmail.com> wrote:
So I'm wondering if it feasible to keep the
audio/other data in SHared
Memory, and then write the GUI in Python reading
from the same memory? Is this concidered "ugly" design? I have no experience
with SHM, so I thought I'd ask.
The other option I was concidering is writing the front-end GUI part using
only info obtained from OSC, but that would
exclude the waveforms of the audio, and lots of other nice features...
If you only run the GUI on the same machine as the engine, you buffer
your samples (via rungbuffer) to a non-RT thread that writes them to
disk. Then use OSC to send the file name to the GUI.
4879
days inactive
4880
days old
linux-audio-dev@lists.linuxaudio.org
8 comments
5 participants
participants (5)
-
Arnold Krille -
fons＠kokkinizita.net -
Harry Van Haaren -
Olivier Guilyardi -
Paul Coccoli