10 Jun
2003
10 Jun
'03
11:12 a.m.
tisdagen den 10 juni 2003 13.21 skrev Frank van de Pol:
On Tue, Jun 10, 2003 at 08:30:39AM +0200, Robert
Jonsson wrote:
Okay, I didn't know that this had been up on the table, how far has this work
progressed, was it just the Karlsruhe meeting or has more thinking occured?
(fyi I'm CC:ing LAD, it might be a more appropriate place for this
discussion..).
Regards,
Robert
Hi,
You are right, with the current alsa-sequencer the softsynths are driven by
realtime events. Though an application can enqueue the events to the
priority queues with delivery timestamp, the scheduling is handled
internally by the alsa sequencer. This causes some problems (especially for
sample accurate synchronisation with JACK or LADSPA synth plugins (XAP?)),
but also for network transparency and support for MIDI interfaces which
accepts timing hints (Steinberg LTB or Emagic AMT ... if specs of the
protocol were available :-( ).
During the LAD meeting at Karlsruhe we discussed this and sketched a
alsa-sequencer roadmap that focusses on transition of the alsa-sequencer
from kernel to userspace and better integration with softsynths / JACK.
A few things from this are very much related to your track bouncing /
off-line rendering thing:
- Provide facility to delegate scheduling to the client. The implementation
would be to deliver the events directly (without queuing) with the
timestamp attached to the registered client port. This would allow the
client to get the events before the deadline (time at which the event
should be played) and use that additional time to put the events at the
right sample position.
Note that for the softsynth to get advantage of this the application
should enqueue the events (a bit) ahead of time and pass the timestamp.
Some of the current applications (including MusE) use the alsa-sequencer
only as event router and drive it real-time.
Since the softsynth/plugin has no notion of the acutal time (only the
media time and sample position), rendering at arbitrary speed should be
possible: bounce faster than realtime or even slower than realtime for
those complex patches.
- JACK is real-time, and bound to the sample rate of the soundcard. Since
the audio sample rate can also be used as a clock master for the alsa
sequencer this would be a good option to ensure synchronisation. The
transport of JACK and alsa sequencer can be tied together (either one of
the two acting as master, a run-time configurable option) to provide
uniform transport and media time amongst the applications that hook into
the JACK and/or alsa sequencer framework.
For the offline rendering no nice scheme has been worked out yet; I guess
it would be something along the lines where the application that owns the
sequencer queue has full control on the transport, moving media time at the
speed the frames are actually rendered, and the app(s) generating the
events keeping at least one sample frame ahead of time. In fact the bounce feature in MusE is
"realtime". It means that you
have to wait the real duration of the track to be rendered.
In a non "realtime" mode the track is rendered as fast as computer can.
AFAICT the realtimeness of the bounce feature is like that because of
design constraints. Okay, bouncing wavetracks should be possible in
non-realtime, but not when using softsynths.
This is because all softsynths use alsa-sequencer as the input interface.
And if I'm not missing anything, this interface is strictly realtime
based. (perhaps it can be tweaked by timestamping every note and sending
them in batches? it seems very hard though.)