Subject: Re: [linux-audio-dev] introduction & ideas
From: Martijn Sipkema (msipkema_AT_sipkema-digital.com)
Date: Wed Feb 27 2002 - 01:24:26 EET
> >I don't think you understand what I mean. Say I have an Emagic AMT 8
>
> true! but now i do :)
Great! :)
> >Note that this problem only occurs with multiport interfaces
> >connected using a single relatively low speed serial link. Also this
> >is because a message has to be sent atomically and not byte for byte
> >so it is not possible to first send a single byte to all ports.
> >
> >So you see this problem can only be solved by having the interface store
> >and schedule messages (or use a very fast link to the interface, which
> >would be a much simpler solution, but it is not what the hardware
> >developers do).
>
> not quite. it can also be solved by:
>
> 1) using multiple PCI-based MIDI ports (though this takes up PCI
slots)
Or using one multiport PCI-based MIDI port. Don't think these exist though.
> 2) using multiple USB-based MIDI ports
The standard MIDI over USB isn't very well designed IIRC. I think it uses
USB bulk transfer mode, which is for 'none time critical' transmission. The
MMA
did not like it.
> 2) using multiple Firewire-based MIDI ports
This is the best IMHO, but then again we should be able to use the current
'professional' MIDI interfaces optimally and for that we need 'send
> >As explained above, the slow serial link to the interface is the
> >bottleneck.
>
> Right. So I'd now go beyond what I said before. Not only is there
> nothing particular clever in these devices, but there's actually
> something *really* stupid :)
I guess... :)
> >> there absolutely *IS* a clock. its built into the UART chip that
> >> converts the digital data into an analog representation on the
> >> wire. it runs at 31.25kb/sec. you can't deliver data to the wire "out
> >> of sync" with that clock.
> >
> >But transmission can start at any time. Then it is transmitted with a
number
>
> my understanding is that it can only start when the UART is in the
> correct state, which only happens a several thousand times a
> second. this still looks like a clock to me. if you deliver a new MIDI
> byte to the hardware before its done with the last byte, there will be
> a gap between the end of the first byte and the start of the second.
> that gap is defined by the UART clock rate used for the serial
> line. in the context we're discussing, its not an insignificant
> gap. that is, you can't dump a NoteOn and then a NoteOff without
> approx 1/31000 seconds between them. Dump a thousand notes, and thats
> 1/31 second of "unnecessary" delay between them.
>
> i may have this wrong, of course.
Maybe you are right though, I'm not an expert on UARTs. I would think it's
pretty stupid that the UART would wait for 10 clocks instead of 1 in the
case
of 8 data bits with 1 start and 1 stop bit.
> >> >The operating system should support accurate scheduling though, at
least
> >> >1 millisecond clock resolution. With Linux this is 10ms at the moment
on
> >> >i386 IIRC and that is not acceptable.
> >>
> >> You do not need to limit yourself to the OS system timer. You can use
> >> the RTC to get timing with a resolution down to about 0.1msec, and you
> >> can also use the interrupt from an audio interface to provide timing
> >> on the order of 1msec.
> >>
> >> The ALSA sequencer as well other programs that use the RTC (MusE,
> >> SoftWerk) do this kind of thing already (though the sequencer requires
> >> a kernel patch to allow it to use the RTC).
> >
> >Using the RTC is not portable. CLOCK_MONOTONIC should provide
>
> actually, the RTC exists for almost every system on which Linux
> currently runs (x86, PPC, Alpha, SPARC, even ARM I think). the code to
> control and use it is non-architecture specific.
I know this is the linux-audio-dev list, but I actually ment portable to
other
POSIX compliant operating systems :)
> >what I need. Maybe I'm not using audio, so using the audio clock is not
an
> >option, and I want the audio and MIDI API seperated apart from a single
> >common clock.
>
> You don't have to be using audio to use the audio interrupt, and it
> doesn't require any connection of the APIs. The ALSA sequencer (again)
> does this. You can tell it to use a PCM clock, even though the
> sequencer itself doesn't access the PCM device in any way.
Using the PCM clock in the MIDI API does require some connection
to the audio system, and I think the ALSA sequencer is quite dependant
on the audio part of ALSA when using this clock right? I just think it is
important to keep the MIDI and audio APIs as seperate as possible.
> I like the model of the clock source being defined as a "module", and
> the choice is left till run-time. There's no reason to define it at
> compile-time. I wouldn't want a MIDI API that required me to have an
> audio device, or to have HZ=N, or to have a specific RTC interval
> available from my kernel.
>
> I don't believe that POSIX_CLOCK_MONOTONIC will actually solve the
> problem you will face either, because from what I've read, it doesn't
> provide an interrupt source - there is no way to use it to schedule
> things "to happen" - you can only use it to ask "how long since <some
> other time>?".
>
> and BTW, from what google tells me, CLOCK_MONOTONIC *is* implemented
> in glibc 2.2, though there may be a work-around-able bug in the code.
You should be able to use cond_var with timeout or clock_nanosleep to
schedule
on the CLOCK_MONOTONIC right?
> >> the hard part is defining the timebase to use, though the
> >> microsecond-based one returned by gettimeofday() doesn't seem like a
> >> bad place to start.
> >
> >gettimeofday() is not unadjusted. UST is needed. And indeed the API
>
> actually, gettimeofday() is defined as monotonic. there have been
> several alarmist threads on the l-k mailing list from people who
> believe they've seen it go backwards. in a very few (SMP) cases, they
> were right and the last of those bugs appears to have fixed somewhere
> back in the middle of the 2.3 development process.
>
> so actually, gettimeofday is not so far from UST as you might
> think. but i agree its not the right answer.
It shouldn't go backwards out of itself, though changing the system time
will
definately break all running media applications using the timeofday, which
somehow seems a little stupid.
--martijn
This archive was generated by hypermail 2b28 : Wed Feb 27 2002 - 01:18:08 EET