[linux-audio-dev] MIDI Clock and ALSA seq

Paul Davis paul at linuxaudiosystems.com
Fri Feb 14 09:37:01 UTC 2003


>I'm trying to hack up a quick app that sends MIDI clock pulses in sync
>with a ringbuffer playback.
>
>I've got it reading MIDI (thanks to Matthias' great exmaple code), but I
>cant figure out how to send MIDI clock pulses explicitly. The ALSA seq
>interface lets me set it up to go automatically, but I want to send a
>clock pulse every 1/24th of the buffer, so the sync is correct.
>
>I dont think I can use raw MIDI because I need the ALSA seq for other
>apps, on the same MIDI port.
>
>- Steve
>
>PS I know there are several apps that can, or will be able to do this, but
>   I need it to work by saturday. Its disposable code.

don't bet on it.

i've been thinking about this quite a lot recently. your best bet will
be to set the sequencer to use the RTC as the clock source. i don't
know how to do this. i'm not sure that even this will work, because
the RTC doesn't run in sync with the audio, so it may drift over time.
you don't have too many other choices, because there is no other timer
source capable of providing sub-audio-period interrupts.

medium-to-long term, i'm going to start recommending that people run
kernels with the high-res timer patch. like the lowlat patch, linus
has rejected this, but it seems the the folks using it are intent on
maintaining it. it provides the same sort of thing as the old KURT
patches - one shot reprogramming of the system timer to provide usec
resolution timer-based scheduling. this will allow
ardour/muse/rosegarden and others to get sub-audio-period MIDI
scheduling, much like things such as the Unitor and other "external
scheduling MIDI interfaces" provide.

there will still be the question of whether the app should do the
timing, and use the sequencer/rawmidi to do immediate delivery, or if
the kernel-side of the sequencer will be hacked to support this.

--p




More information about the Linux-audio-dev mailing list