Subject: Re: [linux-audio-dev] introduction & ideas
From: Martijn Sipkema (msipkema_AT_sipkema-digital.com)
Date: Wed Mar 06 2002 - 00:28:48 EET
> Ok, I was of course thinking of timestamping MIDI events with the
> "audio clock". No problem when running a sequencer as a part of the
> audio network, but it does get messy to timestamp the MIDI events.
I would prefer timestamping MIDI messages with some common clock.
Then the audio system can return the actual transmission time for a buffer
in this clock and MIDI and audio can be synced.
> > asking them to deal with packetized delivery
> > of semantically whole MIDI messages won't win many friends, i fear.
> >
> > if you try to deliver them in one lump, that can cause major stress
> > for a buffer system optimized on the assumption that most messages
> > are less than 32 bytes.
>
> Right - the biggest problem here would be the requirement for dynamic
> memory management in real time context...
I don't think an arbitrarily long sysex messages should be guaranteed to
be delivered atomically. This is very hard to do and still be real time,
i.e.
don't use malloc. A preallocated memory pool could be used, but you
will eventually run into a sysex message too large. Besides, I don't really
see a problem with receiving the sysex message in chunks not larger than
some maximum size.
> > and again, we can easily timestamp MIDI data on the way in - after
> > all, its clocked by an "external" source. the problem is delivering
> > it on time on the way out.
>
> Yeah... It's actually quite amazing that even "high end" MIDI
> interfaces are as stupid as they are...! *heh*
Even with the stupid interfaces timing should be quite good on a realtime
operating system.
> Wonder if your average MIDI interface would handle the 0xfe abuse
> hack I suggested above... (Well, at least I know most SoundBlaster
> cards won't handle it!)
I don't really see an advantage to this approach. It might work for creating
a clock, but it wouldn't work on multiport interfaces where the accurate
timing is most needed. I don't think timing actually gets any better with
this
approach, and I'm still not even sure the serial port hardware can only
start
a byte every 320 microseconds.
IMHO a MIDI driver should be a (real time) user space process able to
accurately transmit MIDI events on the hardware from
CLOCK_MONOTONIC or something similar.
--martijn
This archive was generated by hypermail 2b28 : Wed Mar 06 2002 - 00:17:30 EET