Subject: RE: [linux-audio-dev] midi events in jack callback / ALSA Sequencer
From: mikko.a.helin_AT_nokia.com
Date: Wed Aug 21 2002 - 16:44:00 EEST
Is it possible to lock the ALSA sequencer to audio clock? Most controllers like Envy24 have a register called "Playback DMA Current/Base Count Register" (= where the 'play position' inside the DMA buffer is currently). Can ALSA sequencer also send MIDI clock based on this counter to MIDI out? Would it be too heavy for a system to read the position inside a timer and then decide which MIDI data should be sent out and update the time stamp (global clock)?
-Mikko (sorry for the ignorance..)
> -----Original Message-----
> From: ext Frank van de Pol [mailto:fvdpol_AT_home.nl]
> Sent: 20. August 2002 23:50
> To: linux-audio-dev_AT_music.columbia.edu; Martijn Sipkema
> Cc: alsa-devel_AT_alsa-project.org
> Subject: Re: [linux-audio-dev] midi events in jack callback / ALSA
> Sequencer
>
>
>
> Martijn,
>
> the ALSA sequencer is exactly designed to serve a mechanism
> to route (midi)
> _events_ from a source to a sink (either driver, application
> or whatever).
>
> On Mon, Aug 19, 2002 at 07:12:47PM +0100, Martijn Sipkema wrote:
> > > >MIDI through and any other 'immediate' type MIDI messages do
> > > >not need to be scheduled, they can be written to the interface
> > immediately.
> > >
> > > Yes, they could. It would however necessitate different
> input routes
> > > for 'immediate' and 'queued' events to the MIDI output handler.
> >
> > The MIDI I/O API I am working on has 'scheduled' and
> 'immediate' queues. I
> > don't think there is a way around this unless 'immediate'
> messages are not
> > used
> > at all and that is clearly not an option.
>
> Within ALSA we have two priority queues, one for tick
> (bar,beat) scheduled
> events, and one for clock (ns) scheduled events. In case of immediate
> scheduling the priority queue is bypassed and the event
> submitted in the
> receiver's fifo (which would be your immediate queue).
>
> Due to potential blocking at the receivers you'll need a fifo
> for every
> destination.
>
> Reason for having 2 priority queues with different reference
> is to cope with
> tempo/signature changes while remaining in sync. The clock
> and tick priority
> queues are in fact parallel in ALSA.
>
> Since especially for soft synths (but also for some
> -undocumented!- USB midi
> interfaces, like Emagic AMT) the events need to be scheduled
> ahead (sort of
> a pre-delay, say 10ms or more) to let the device/softsynth
> handle the micro
> scheduling, it would seem a good idea to handle this at the
> clock based
> queue. Since variable predelay in ms would be not quite
> friendly to the tick
> based queue (different units), it might make sense to have
> the tick based
> queue send events into the clock based queue instead of
> immediate delivery).
>
> Your links about UST sound very good in this perspective, since the
> _monotonic_ clock ensures compatibility between the event (sequencer)
> subsystem, and other audio/video subsystems.
>
> The current clock based ALSA prioq could then simply be a
> reference against
> the UST instead of keeping track of time itself. High level
> applications can
> have the freedom to take whatever route they want, use the
> ALSA sequencer
> API or go directly to the UST based scheduler. All these
> applications can
> still cooperate in this framework :-) (try that in MS Windows.....)
>
> A good reason for applications to use (UST/ALSA) scheduling instead of
> taking care of micro scheduling itself and using rawmidi interfaces is
> better support for softsynths to trigger at the right spot in
> the buffer,
> and for the upcoming smart (eg. USB) midi devices.
>
> >
> > > This
> > > would not help make things simpler. It would also mean
> that a Sysex
> > > or pitch/CC burst routed through can delay MIDI clocks
> because of the
> > > limited bandwidth on the MIDI wire.
> >
> > Sysex can hurt timing for other events, but that's MIDI.
> MIDI clock (any
> > MIDI realtime message) can interleave other messages. And
> yes, merging
> > MIDI streams is not easy.
>
> You can't overcome the limits of the MIDI physical line if that's your
> target transport. However when sending events to soft- or
> onboard synths
> these limits are different (typically less of an issue).
>
> When using events instead of midi bytes the merging is a no
> brainer (and
> leaves room for events not defined in midi spec).
>
> >
> > > Thinking about it -- it's hypothetical because we don't
> have them in
> > > Linux yet -- I believe a decent MIDI out handler using a
> firm timer
> > > would be an order of magnitude more complicated than one
> based on the
> > > RTC. Have you coded one yet?
> >
> > Yes, and it is not that complex I think. Note that this
> would only have to
> > be done
> > in a driver process or a user-space sequencer application
> and not for every
> > client
> > application.
> >
> > I'll try to get a version of my MIDI I/O API/framework
> ready, but it will
> > probably still
> > take me some time to get finished.
>
> Perhaps you might want to look at the ALSA sequencer, and take it to a
> higher level? I'd love to see UST time references...
>
> >
> > --martijn
> >
>
> --
> +---- --- -- - - - -
> | Frank van de Pol -o) A-L-S-A
> | FvdPol_AT_home.nl /\\ Sounds good!
> | http://www.alsa-project.org _\_v
> | Linux - Why use Windows if we have doors available?
>
This archive was generated by hypermail 2b28 : Wed Aug 21 2002 - 16:48:01 EEST