[linux-audio-dev] Re: [MusE] More ideas :) [Track freeze] - Alsa Sequencer

Allan Klinbail allank at labyrinth.net.au
Fri Jun 13 12:34:00 UTC 2003

This is all quite interesting.. 

>From working with hardware synths I'm used to listening to everything in
real time.... over and over and over again.. no big deal... often this
is where new ideas are formed and also problems in the mix discovered.. 

Personally I'm just excited that we have real-time soft synths.  

To my knowledge MIDI in itself is a real-time spec except for sysex...
which is used more often for management rather than real-time control..
(although it can be). However the notes below do indicate a dedication
to real-time.... although some concerns do arise 
"Note that for the softsynth to get advantage of this the application
> >   should enqueue the events (a bit) ahead of time"

ON outset it would seem that someone who is using an external MIDI
controller device (fader box e.t.c..) or even an internal Midi slider
app may suffer as us humans work in real time.. our real time messages
would then be queuing after the above events...(am I making sense? let
me try another phrase) essentially a real-time tweak of a knob (say
routed to a filter, envelope or LFO)  may not register with the system
as the sequencer app only received these messages in real time and not
"slightly before"..... This would make recording performances extremely
difficult (and in techno,electronica et.al synth tweaking is the
performance in itself)... Imagine trying to pre-empt yourself by a
matter of milliseconds.. Playing on traditional instruments it's often
hard to even do it in time.   I'm not convinced trying to do "better
than real-time" is actually such a musical concept.  I Would be happy to
see a bounce feature that works in better than real-time.. but not if it
is going to sacrifice the performance of MusE or any other app in

> >   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."

So long as sample-rate is converted into minutes and seconds etc.. to
allow for adjusting BPM.. but I'm sure this consideration has been taken


On Tue, 2003-06-10 at 23:51, Robert Jonsson wrote:
> 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:
> > > Hi,
> > >
> > > > 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.)
> >
> > 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.
> >
> > Frank.
> 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

More information about the Linux-audio-dev mailing list