11 Apr
2006
11 Apr
'06
5:10 p.m.
Paul Davis:
How about creating the gfx waveform data on the engine and then just
send a pointer to the gfx process, which displays the data using the
MIT-SHM X extension?
PS. Please don't let this inspire you to reimplement Ardour. :-)
As an
interface designer, the first thing I look for on an engine's
project site is some sort of asynchronous API - I should never concern
myself with anything outside referencing the api from my app's one
windowing thread. FMOD, gstreamer, and my dead pkaudio project do this
very well. I don't ever want to worry about what thread it happens in,
what threads it will affect, or what the performance effects of
*making* the call will be (as opposed to residual effects).
although i agree that this is the right design for many classes of
application design, i would like to see how you propose to tackle
metering and waveform display (the two most difficult examples).
ardour would be relatively easy to separate into interface+engine
processes (as opposed to just a lib/lib-client separation) if it were
not for these issues. moving waveform and metering data back and forth
between two processes via a wire protocol is very expensive and
inefficient. 
12 Apr
12 Apr
10:40 a.m.
New subject: [linux-audio-user] Re: [linux-audio-dev] music engine
On Tue, 2006-04-11 at 12:10 -0700, Kjetil Svalastog Matheussen wrote:
Paul Davis:
How about creating the gfx waveform data on the engine and then just
send a pointer to the gfx process, which displays the data using the
MIT-SHM X extension?
PS. Please don't let this inspire you to reimplement Ardour. :-)
Actually Lars Luthman's DSSI Oscilloscope plugin does exactly this.
-DR-
As an
interface designer, the first thing I look for on an engine's
project site is some sort of asynchronous API - I should never concern
myself with anything outside referencing the api from my app's one
windowing thread. FMOD, gstreamer, and my dead pkaudio project do this
very well. I don't ever want to worry about what thread it happens in,
what threads it will affect, or what the performance effects of
*making* the call will be (as opposed to residual effects).
although i agree that this is the right design for many classes of
application design, i would like to see how you propose to tackle
metering and waveform display (the two most difficult examples).
ardour would be relatively easy to separate into interface+engine
processes (as opposed to just a lib/lib-client separation) if it were
not for these issues. moving waveform and metering data back and forth
between two processes via a wire protocol is very expensive and
inefficient. 
10:50 a.m.
New subject: [linux-audio-user] Re: [linux-audio-dev] music engine
On Wed, 2006-04-12 at 08:40 -0400, Dave Robillard wrote:
On Tue, 2006-04-11 at 12:10 -0700, Kjetil Svalastog
Matheussen wrote:
nice idea, except that it needs to work across a LAN too, which MIT-SHM
doesn't accomplish.
anyway, the comments here last week/last weekend convinced me to look at
this in a new light. the bandwidth is really much less than i had been
imagining. and i stress "imagining" :)
--p
Paul Davis:
How about creating the gfx waveform data on the engine and then just
send a pointer to the gfx process, which displays the data using the
MIT-SHM X extension?
PS. Please don't let this inspire you to reimplement Ardour. :-)
Actually Lars Luthman's DSSI Oscilloscope plugin does exactly this. As an
interface designer, the first thing I look for on an engine's
project site is some sort of asynchronous API - I should never concern
myself with anything outside referencing the api from my app's one
windowing thread. FMOD, gstreamer, and my dead pkaudio project do this
very well. I don't ever want to worry about what thread it happens in,
what threads it will affect, or what the performance effects of
*making* the call will be (as opposed to residual effects).
although i agree that this is the right design for many classes of
application design, i would like to see how you propose to tackle
metering and waveform display (the two most difficult examples).
ardour would be relatively easy to separate into interface+engine
processes (as opposed to just a lib/lib-client separation) if it were
not for these issues. moving waveform and metering data back and forth
between two processes via a wire protocol is very expensive and
inefficient. 
2:34 p.m.
New subject: [linux-audio-user] Re: [linux-audio-dev] music engine
On Wed, 2006-04-12 at 08:40 -0400, Dave Robillard wrote:
On Tue, 2006-04-11 at 12:10 -0700, Kjetil Svalastog
Matheussen wrote:
Not really - it actually pushes _all_ audio data onto a ringbuffer in
normal SysV shared memory, period by period, and does all the triggering
and rendering in the GUI.
--
Lars Luthman
PGP key: http://www.student.nada.kth.se/~d00-llu/pgp_key.php
Fingerprint: FCA7 C790 19B9 322D EB7A E1B3 4371 4650 04C7 7E2E
How about creating the gfx waveform data on the
engine and then just
send a pointer to the gfx process, which displays the data using the
MIT-SHM X extension?
PS. Please don't let this inspire you to reimplement Ardour. :-)
Actually Lars Luthman's DSSI Oscilloscope plugin does exactly this.
6599
days inactive
6600
days old
linux-audio-dev@lists.linuxaudio.org
3 comments
4 participants
participants (4)
-
Dave Robillard -
Kjetil Svalastog Matheussen -
Lars Luthman -
Paul Davis