18 Dec
2002
18 Dec
'02
9:59 a.m.
You move the play position marker.
Plugins get the position changes from the timeline,
and those that need to, do their best to prebuffer
audio data from disk, or whatever. While doing that,
the put a "1" on their "READY" Control Outputs, that
are connected to the transport control.
You press "Start".
The transport control simply waits until it has
received a "0" from each one of the "READY" Controls
it's watching. Then it actually starts the sequencer.
If there are no READY Controls in the net, the
sequencer will just start instantly.
Sounds reasonable?
//David Olofson - Programmer, Composer, Open Source Advocate
.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`---------------------------> http://olofson.net/audiality -'
--- http://olofson.net --- http://www.reologica.se ---
18 Dec
18 Dec
11:23 a.m.
On Wed, Dec 18, 2002 at 02:53:50PM +0100, David Olofson wrote:
You move the play position marker.
Plugins get the position changes from the timeline,
and those that need to, do their best to prebuffer
audio data from disk, or whatever. While doing that,
the put a "1" on their "READY" Control Outputs, that
are connected to the transport control.
You press "Start".
The transport control simply waits until it has
received a "0" from each one of the "READY" Controls
it's watching. Then it actually starts the sequencer.
If there are no READY Controls in the net, the
sequencer will just start instantly.
I'm wondering if this can't be handled better in a non RT manner, like
the activate call in LADSPA, but with the addition of some kind of time
position.
The plugin will likly have to flush its internal buffers anyway, so it
might just be easier and cleaner to do it outside the normal RT context.
- Steve
12:30 p.m.
On Wednesday 18 December 2002 16.18, Steve Harris wrote:
On Wed, Dec 18, 2002 at 02:53:50PM +0100, David
Olofson wrote:
But then you have to stop the whole net along with the sequencer, as
soon as you have one of those "non-instant" plugins in the net. The
very point is to avoid that.
Besides, this doesn't just happen when you activate a plugin, but
could happen as soon as you move the transport, or change a control.
Sure, it can be handled with control hints, saying these controls are
not RT safe, but I think that's a bit restrictive.
You move the play position marker.
Plugins get the position changes from the timeline,
and those that need to, do their best to prebuffer
audio data from disk, or whatever. While doing that,
the put a "1" on their "READY" Control Outputs, that
are connected to the transport control.
You press "Start".
The transport control simply waits until it has
received a "0" from each one of the "READY" Controls
it's watching. Then it actually starts the sequencer.
If there are no READY Controls in the net, the
sequencer will just start instantly.
I'm wondering if this can't be handled better in a non RT manner,
like the activate call in LADSPA, but with the addition of some
kind of time position. The plugin will likly have to flush its internal
buffers anyway, so
it might just be easier and cleaner to do it outside the normal RT
context.
That kind of solution would need explicit API support as well, so I'm
not sure it makes anything easier.
//David Olofson - Programmer, Composer, Open Source Advocate
.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`---------------------------> http://olofson.net/audiality -'
--- http://olofson.net --- http://www.reologica.se ---
1:14 p.m.
On Wed, Dec 18, 2002 at 05:25:18PM +0100, David Olofson wrote:
But then you have to stop the whole net along with the
sequencer, as
soon as you have one of those "non-instant" plugins in the net. The
very point is to avoid that.
Effectivly you have to anyway.
Realigning all the plugins will take a non finite time, so you have to do
something while the're busy.
Besides, this doesn't just happen when you
activate a plugin, but
could happen as soon as you move the transport, or change a control.
Sure, it can be handled with control hints, saying these controls are
not RT safe, but I think that's a bit restrictive.
Are you expecting that the graph will continue to execute while you're
waiting for the realignment? That seems a bit optomistic and not
particularly useful.
OTOH I'm not sure that a delay line (for example) can handle this usefully
at all, it can't prefill its buffers with the previous n seconds of audio
(which is what it would like to do), so all it can do is reset back to its
inital state (unhelpful and slow) or ignore it (even more unhelpful).
Its basicly just sequencers (ie. plugins with internal, temporal data)
that can do something useful with this, right?
- Steve
3:04 p.m.
On Wednesday 18 December 2002 18.09, Steve Harris wrote:
(See above.)
On Wed, Dec 18, 2002 at 05:25:18PM +0100, David
Olofson wrote:
I can't see why. You don't even have to stop the plugins that aren't
ready. They *could* actually be capable of doing real processing
while doing background work.
For example, you don't have to kill the whole sampler just because
it's loading a new sound for one of it's Channels. (This applies to
Audiality, BTW. It *never* stops the RT engine, not even when loading
and rendering sounds.)
But then you have to stop the whole net along
with the sequencer,
as soon as you have one of those "non-instant" plugins in the
net. The very point is to avoid that.
Effectivly you have to anyway. Realigning all the plugins will take a non finite
time, so you have
to do something while the're busy.
So, why not just keep processing audio, so you don't kill the monitor
mix and whatever might be going on in the net?
I'd *really* like XAP hosts to be able to behave like *real
hardware*, now that we have an OS to provide the lowlatency
scheduling, and real audio interfaces for quality audio.
Besides, this
doesn't just happen when you activate a plugin, but
could happen as soon as you move the transport, or change a
control. Sure, it can be handled with control hints, saying these
controls are not RT safe, but I think that's a bit restrictive.
Are you expecting that the graph will continue to execute while
you're waiting for the realignment? That seems a bit optomistic and
not particularly useful. OTOH I'm not sure that a delay line (for example)
can handle this
usefully at all, it can't prefill its buffers with the previous n
seconds of audio (which is what it would like to do), so all it can
do is reset back to its inital state (unhelpful and slow) or ignore
it (even more unhelpful).
Ignore what? A delay plugin is never expected to prebuffer anything
at all. It's just expected to delay whatever it receives.
If you really want a song that you start in the middle to sound
*exactly* as if you were doing the same thing with a prerendered
audio file, it's getting really rather hairy.
The idea with the READY thing is just to be able to let the sequencer
know when a plugin is ready to start playing. The alternatives are:
1. Ignore the problem and have the host freeze, lose
sync and whatnot while some plugin needs to prebuffer.
2. Just ignore the plugins that aren't ready, and play.
They'll chime in eventually. Expect the user to wait a
little longer before hitting "play" after moving the
play cursor, if he/she finds this random delay, missed
or delayed first notes etc annoying.
3. Allow the sequencer/host/transport control wait until
plugins say they're ready for instant playback.
1 is obviously out, because it makes some sound cards freak out in
various ways, which in turn may upset external sync'ed devices etc.
That leaves 2 and 3, which are identical to plugins, except that in
3, they have a standardized control through which they indicate their
status.
Its basicly just sequencers (ie. plugins with
internal, temporal
data) that can do something useful with this, right?
No, it would work for samplers, hard disk recorders and the like as
well. I've suggested a way to tell HDRs about the play cursor before
starting the transport. The READY control would be a logical
complement to that, for hosts that care.
It may not be a vital feature, but it's a real problem, and I think
this is a simple solution for it.
Don't mix it up with managing background threads and stuff - that's a
different problem, really. (For which I think I have a simple
solution for simple cases, BTW. Linuxsampler will just have to use
pthreads until XAP 2.0. ;-)
//David Olofson - Programmer, Composer, Open Source Advocate
.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`---------------------------> http://olofson.net/audiality -'
--- http://olofson.net --- http://www.reologica.se ---
1:01 p.m.
Steve Harris wrote:
On Wed, Dec 18, 2002 at 02:53:50PM +0100, David Olofson
wrote:
if the whole system is in sample-sync to external, and transport
control is external too, there's no choice anyway i think.
tim
You move the play position marker.
Plugins get the position changes from the timeline,
and those that need to, do their best to prebuffer
audio data from disk, or whatever. While doing that,
the put a "1" on their "READY" Control Outputs, that
are connected to the transport control.
You press "Start".
The transport control simply waits until it has
received a "0" from each one of the "READY" Controls
it's watching. Then it actually starts the sequencer.
If there are no READY Controls in the net, the
sequencer will just start instantly.
I'm wondering if this can't be handled better in a non RT manner, like
the activate call in LADSPA, but with the addition of some kind of time
position.
The plugin will likly have to flush its internal buffers anyway, so it
might just be easier and cleaner to do it outside the normal RT context.
2:36 p.m.
On Wednesday 18 December 2002 17.19, Tim Goetze wrote:
[...handling prebuffering and the like...]
if the whole system is in sample-sync to external, and
transport
control is external too, there's no choice anyway i think.
No, there's no choice; you have to be ready in time - and for that,
you need the external transport control to wait until you're ready.
Normally, you do this by just having a configurable delay between a
"brutal" transport operation and the next "start" (*), or you simply
have to assume that the user handles it manually, by waiting some
before hitting "play".
(*) Many MIDI sequencers do this to allow samplers and slow synths
to load the sounds before playback starts. (And yes, I have to
use this with one of my synths at least. Must be *really* slow
patch memory or something... *heh*)
My suggestion is basically to allow XAP sequencers to do the same
with XAP plugins, although *automatically*, since we now have the
chance to get it right.
BTW, does anyone know if any standard sync protocols, or studio
hardware support this kind of feedback?
//David Olofson - Programmer, Composer, Open Source Advocate
.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`---------------------------> http://olofson.net/audiality -'
--- http://olofson.net --- http://www.reologica.se ---
7820
days inactive
7820
days old
linux-audio-dev@lists.linuxaudio.org
6 comments
3 participants
participants (3)
-
David Olofson -
Steve Harris -
Tim Goetze