Subject: Re: [linux-audio-dev] an open letter to Linus re: low latency
From: Paul Barton-Davis (pbd_AT_Op.Net)
Date: Fri Jun 23 2000 - 17:01:17 EEST
>I'm envisioning server daemons that run on each system. Instead of opening
>the audio device through the kernel, apps would call a sound daemon library
>routine. And there would be control to allow programs to shut off
>the daemon's handling of the different devices, to allow one app to
>take over that device when maximum efficiency is desired. Then the
>daemon would treat all other open requests (or r/w requests on an already
>opened device) as errors (resource in use).
>The daemon would handle any number of inputs, outputs, synths, MIDI
>devices, etc., on whatever sound hardware is available (no design limit).
>It would allow multiple apps to access the MIDI device, and play and/or
>record sounds in a cooperative manner. (Different apps could access the
>MIDI I/O at the same time through different MIDI channels, and if an app
>were already recording audio, another app could open the device to record,
>and the daemon would send it a duplicate of the sound input, starting at the
>time when it started reading from the input.)
you clearly need to know more about ALSA. it doesn't have a sound
daemon, but it can already do most of what you describe above, and/or
has hooks for the remaining stuff.
>For use over the network, an open Internet protocol would be developed.
it already exists, and people on this list and alsa-devel have pointed
it out. it was developed by NCD several years ago. as best i could
tell, it works fine.
>The more advanced use would be for a geographically dispersed group of
>musicians to be able to jam together, put on an Internet concert for millions
>(billions?) of people in real time, and do multitrack recording and overdubs.
>And maybe other things we haven't thought of yet. Why not?
this is a totally different kind of protocol, since it has to be
full-duplex.
>> This distinction between "close to the h/w" and "i want my API" is
>> even more true for audio. There is no way in hell that you would
>> sensibly do real-time FX on a networked audio connection.
>
>Not right now, but maybe later! X was developed by people who weren't
>so much concerned with the level of performance of the hardware they
>were developing on, but what would exist in upcoming years. That was,
>if I may say so, rather brilliant of them. My latest issue of Fiber
>Optic News has articles on running fiber into residences and 10Gbps ethernet
>network speeds. Put that together with some fast CPUs and a network protocol
>that allows for low-latency and priority for real-time data transfer for
>multimedia (it's been talked about, is important for VoIP, and IIRC is included
>in IPv6), and maybe we'll be doing real-time FX over the Internet (not to
>mention LAN connections) in the not too far-off future.
latency is not a function of bandwidth. network interface latency has
been going down too, but not as fast as bandwidth has been going up.
>One of my goals is to be able to dedicate one computer as a multitrack
>recorder, and use another one or two for the synthesizer(s), another to
>do pitch to MIDI conversion to MIDIfy my electric guitar, maybe another to
>convert pulses from drum pads to MIDI, etc., and maybe a bunch of rack mount
>Linux systems to replace the rack mount digital effects boxes in the studio,
>and tie it all together with an ethernet LAN for the digital data flow.
>(S/PDIF? Digital ADAT interfaces? Ancient, archaic stuff. Who needs them? :)
you've just spent way more than you would have done with dedicated
boxes. using one computer for each of these tasks is absurd. if all
you are doing is a single task (eg. fx), you're much better off with
no disk, no monitor, no keyboard, no mouse, no floppy, no IDE or SCSI
bus, no video bus, no PCI bus, no ISA bus, etc. etc. etc. Thats why
you can get a kick-ass TC multi-fx unit for US$400, and only a pretty poor
computer for anything close to that price.
where computers make sense are when you can use one of them for many things.
--p
This archive was generated by hypermail 2b28 : Fri Jun 23 2000 - 17:35:36 EEST