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:[EMAIL PROTECTED]] > Sent: 20. August 2002 23:50 > To: [EMAIL PROTECTED]; Martijn Sipkema > Cc: [EMAIL PROTECTED] > 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 > | [EMAIL PROTECTED] /\\ Sounds good! > | http://www.alsa-project.org _\_v > | Linux - Why use Windows if we have doors available? >
