Re: [linux-audio-dev] introduction & ideas

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] introduction & ideas
From: Martijn Sipkema (msipkema_AT_sipkema-digital.com)
Date: Wed Feb 27 2002 - 12:25:08 EET


> >> 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
>
> sometimes its necessary to react against the orthodoxy, and declare
> certain designs to be a mistake. winmodems would be one example of
> this; audio interfaces claiming to do "full duplex i/o" that don't run
> both streams from the same clock would be another. i'd add "serial
> line interconnects to multiple MIDI Ports" to that list. the fact that
> emagic and steinberg market them as high end tools is beside the point
> for me.

I wouldn't go that far. It wasn't a bad design some years ago and still the
timing isn't that bad when only using one AMT8 (8 ports) in practice.
The operating system will most of the time produce more hearable and
disturbing timing problems, though that should not be the case for Linux
I hope.
It is more a legacy design, but I happen to have one, so I'm going to write
support for these crappy units :)

> >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.
>
> They are connected, but only internally. You can't see the connection
> in the API. the PCM clock becomes just another possible timer (see
> /proc/asound/timers). When telling the sequencer what to use, you use
> an abstract name that has nothing to do with the fact that its an
> audio device. i think this is "separate" :)

Here out definitions of "seperate" clearly differ :)

> >> 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?
>
> not usefully. all kernel thread scheduling is done using the system
> timer or other device interrupts that wake up a thread. you can't
> sleep for less than 10ms (on average) unless you're running SCHED_FIFO
> or SCHED_RR, and under those circumstances it only makes a difference
> if you want to sleep for <2ms, in which case the kernel spins for the
> required time !!!

This is indeed a problem with the Linux scheduler and will have to be
fixed. The clock resolution is indeed smaller than the maximum value
defined in the standard, but that doesn't make it all that usefull for real
time applications.

> there is also no difference in linux between pthread_cond_timedwait(),
> clock_nanosleep() and nanosleep(), since all (sleep) scheduling is
> done using the system timer (which cannot be reversed by the way -
> we're talking about the kernel's tick counter, which is always
> monotonic).
>
> basically, without a hardware source of regular, high frequency
> interrupts, there is no way to sleep for small amounts of time. you
> either have to increase HZ so that the system timer can play that
> role, or use some other hardware interrupt source.
>
> the only other alternative are the "KURT" patches, the completely
> change the way the system timer is used. they are very cool (the
> kernel constantly reprograms the timer to interrupt when needed) but
> they have never made it into the mainstream kernel and i am not even
> sure if they are maintained anymore. they were measured providing
> microsecond-accurate scheduling!

This is the correct approach. BeOS had this. I think there is also an
IBM kernel patch that might improve scheduling, but it was actually
ment to reduce the clock overhead when running multiple instances
of Linux on a large server.

--martijn


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Wed Feb 27 2002 - 12:17:13 EET