Subject: Re: [linux-audio-dev] introduction & ideas
From: Paul Davis (pbd_AT_Op.Net)
Date: Wed Feb 27 2002 - 00:06:57 EET
>I don't think you understand what I mean. Say I have an Emagic AMT 8
true! but now i do :)
>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)
2) using multiple USB-based MIDI ports
2) using multiple Firewire-based MIDI ports
>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 :)
>> 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.
>> >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.
>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.
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.
>> 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.
--p
This archive was generated by hypermail 2b28 : Tue Feb 26 2002 - 23:58:11 EET