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: Paul Davis (pbd_AT_Op.Net)
Date: Wed Feb 27 2002 - 01:55:00 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.

>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" :)

>> 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 !!!

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!

--p


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 - 01:46:58 EET