Slashdot Mirror
Linux Cluster For Processing DSP Effects?
SpLiFFoRd asks: "I'm a MIDI musician and songwriter who seems to be constantly running out of processing power for my VST effects when I'm working in CubaseVST. Coincidently, I've also been working on explorations into Linux clusters and parallel processing. As I watched my CPU meter in Cubase hit 95% one night, I began thinking...'What if there was a way to farm out the work of my single processor to an outside Linux cluster with multiple processors to speed things up as well as enable me to run more simultaneous effects without straining the system?' I've been looking around, but don't seem to see any others who might have had this thought. This would be a tremendous real world application to me, and probably to others as well. Do you know anyone who might want to tackle such a project?" Sounds like a worthy project, but sound processing is still in its infancy under Linux, and while the horizon looks good with projects like GLAME and ecasound, I'm wondering if it may be a while before something like this will be feasible. That issue aside, however, I think something like this would be really cool. What about you?
"As a side note, when I say 'VST effects', I mean both the original and third party plugins for audio effects such as digital delay, reverb, tapped delay, pitch shifting etc. that work with Cubase."
See here for my earlier comment/response.
Some links to mLAN resources, by no means complete, please follow-up with more URL's if you find them (I don't have time):
Pavo (leader in 3rd party mLAN development): http://www.pavo.com/
Yamaha's mLAN (pretty pictures): http://www.harmony-central.com/Newp/2000/mLAN.html
Details on mLAN products (Japanese) http://www.miroc.co.jp/Tango/qrys/NEWS/yamaha/mlan .html
mLAN stands for "musical LAN", which is exactly what it sounds like. There is no point us re-engineering this for Linux, we simply need to work on making Linux a good platform for mLAN development, and we'll get to the point where we can route audio just like we route IP, and thus do things to it just like we do with the content fields of IP packets...
If you want realtime DSP-rendering farms based on Linux, then keep an eye on the work being done to add Firewire/IEEE1394 support to the Kernel. This is where it will start.
-- Jay Vaughan - jv@teklab.com
; -- the corruption of government starts with its secrets. a truly free people keep no secrets. --
"This seems like an expensive and inefficient solution for the problem you describe. PCs are actually pretty bad at doing signal processing; there's a whole class of chips (DSPs) that are optimized for it. There are almost certainly DSP-based hardware boards/widgets that will handle a lot of these effects for you, and it wouldn't surprise me to learn that there was a general-purpose programmable DSP card on the market too. Researching this before you spend money on a cluster would be a Good Idea."
y mbolic_Sound/PR/Kyma5.html
Yup. Here's some links:
Symbolic Sounds Kyma system, a DSP-based programmable hardware solution for audio.
Details on the Kyma system (drool!):
http://namm.harmony-central.com/SNAMM00/Content/S
Hardware DSP hacking tools:
Analog Devices EZ-SHARC/EZ-KIT DSP experimentation board (which screams for Linux support, incidentally)
; -- the corruption of government starts with its secrets. a truly free people keep no secrets. --
I'm not an expert on clusters but it may be simpler to use something like MOSIX
http://www.mosix.cs.huji.ac.il/
MOSIX uses transparent migration of processing amongst other nodes on an Ethernet network [read the site for more particulars]. It's also pretty easy to set up [basically just run the install script and make sure the nodes can locate each other].
Might be helpful if Beowulf is a bit much for your needs.
This seems like an expensive and inefficient solution for the problem you describe. PCs are actually pretty bad at doing signal processing; there's a whole class of chips (DSPs) that are optimized for it. There are almost certainly DSP-based hardware boards/widgets that will handle a lot of these effects for you, and it wouldn't surprise me to learn that there was a general-purpose programmable DSP card on the market too. Researching this before you spend money on a cluster would be a Good Idea.
Assuming that the software's there, dedicated DSP hardware should by far be the cheapest and easiest solution.
OTOH, good luck finding the software.
Addendum: Actually, I think that the effects generators on most modern sound cards are just DSPs, RAM, and some firmware. You might be able to find (or write or contract) hacked drivers that would let you arbitrarily reprogram this for your own purposes.
Just a few thoughts.
Exactly...mLAN will help this out tremendiously, but it is only a start. Saying that mLAN will be the cause of Audio Rendering Farms is a bit premature though. Right now, it is little more than a fast network dedicated to audio, though I've seen some really fricken cool stuff come through in the last few week. I too am stuck under too many NDAs to talk about this and kinda wish that this topic had come about in a month. NAMM, the music industrys premier showcase of technologies, is almost on us (doh! gotta finish up some demos soon) and I can guarentee we will be seeing some of the technology that will enable this kinda processing to happen.
The greatest thing about mLAN is that, unlike MIDI, it will allow both the Audio and Data layers to be transmitted syncronously and we will soon be looking at other paradigms that us electronic musicians (and probably the folks that have stayed away from electronic music because it was too geeky and technical). Yeah, I'm just reiterating what was said, but few outside the closed music communities know whats coming up.
The only real problems I see right now is everyone is focusing their attention on Mac and Windows. The few cool pieces of software that I would consider to be professional level are getting their developers eaten up by these Mac/PC Only developers. Our staff has been heavily pursuing one company to produce a version of their software that could be run from a modified linux distribution from simply a LCD and command line. Once we can get that, run it in server mode and let the server parse the different tasks to different machines. I believe jMAX, which is a derividation of IRCAM / Opcode / (MSP???)s MAX application...only running from a Java front end and running in Server Client mode. Heh...I haven't been able to get it working on Mac OS X yet, but it is technically what we all want (I hope...I've only read about it so far as I've already got the regular MAX running and haven't put the time to it). If that could run in Server Client mode, whats to split the polyphony and have multiple servers for the parts of the audio that don't need to modulate the other parts.
blah blah blah...ask this question again in 4 weeks...I'm sure a few of us will be able to open our mouths (if'n these guys actually produce...still waiting for a few products from the last winter NAMM to be announced at least from a development sake...)
clif
I've been wanting something exactly like this for a long long time.
I do editing using Adobe Premiere on my Macintosh. When I finish a project, or finish a "stage" of it, I have to render the project overnight. My next editing machine will likely be a dual processor PC, but for now I'm using my Mac.
In addition to my Mac, I have four other computers available, all of which will happily run Linux. Setting up a Linux cluster would be a good project, and is definitely feasible. But my Macintosh has no means to offload the rendering to a cluster...
I think this would be a fantastic product, I can see it maybe as a wholly separate product. It would run separate from the actual editing application and distribute its rendering load to some sort of cluster (I'd assume a customized Linux cluster).
Computers are cheap now, but it is expensive to buy very fast machines every few months... why not allow for clustering of your old machines (even if you do replace the primary one every few months)? Then you could still use those extra CPU cycles, and maybe you could actually use your money effectively.
Isn't the problem faced by distributing computing such as this the limitation of the network bandwith between machines? Assuming you connected machines via 100MB/s, wouldn't you top out real quick? The processing speed compared to what it can send of the wire would make for a few delays I would think.
Anyone have any feedback on using distributed computing for such "Real-time" things such as Video and Audio?
If you did your effects in Mpeg 4 structured audio instead of MIDI, you might get considerably more performance.
Why? Because there is considerable research in compiling MP4-SA to C and then running the native code, to get greater performance out of arbitrary effects, filters, etc.
More info is available here
Nicholas C Weaver
nweaver@cs.berkeley.edu
Test your net with Netalyzr
... before MP4-SA can begin to function, and I mean *function* in a professional studio in lieu of MIDI.
... which, by the way, is one of the reasons I'm a very strong advocate of musicians *staying* in the hardware realm for now, and leaving the software plugins alone.
There's a lot to say about MIDI - sure, it's slow, sure it's limited, but as far as serial control protocols go, it has *definitely* weathered the test of time.
Anyway, this slashdot article is not a problem of MIDI, but a problem of i/o architectures.
The problem with realtime Cubase effects is that they're still very processor/architecture/OS bound. There's no functional way of getting data in and out of a Cubase effects module other than by using the strict architecture path that the effects software has been written to use - this problem exists for Cubase plugins, ProTools/TDM plugins, DirectX plugins, etc.
A better alternative to investing energy into the MP4-SA side of things (which is not a new technology - for a similar example, check out Thomas Dolby's Beatnik, which is a fairly similar implementation) is to instead investigate Linux' support for mLAN, which is Yamaha's "musical LAN" protocol that sits on top of Firewire/IEE1394.
mLAN is the solution to this article's stated problem.
By adding really good support for mLAN in Linux, it's really *NOT* unreasonable to say that Linux clusted boxes could be used for REALTIME DSP processing tasks. mLAN represents audio, video and media-data as individual streams on the same wire - a very good implementation of mLAN/Firewire in the Linux kernel would allow you to separate these streams, route them off to different processes/processors, and stick them back on the mLAN wire in realtime.
This will happen in the PC world.
There are already Windows-based realtime DSP effects boxes that use mLAN as the routing interface, currently in *development* by a number of large music companies (I can't drop names here, I'm under very tight NDA).
With good Firewire support, Linux (and other OSS OS'es) can keep up with these developments, which will hit the market, I'd predict, by Q3 2001. Put the audio out on the wire, route it wherever you want to route it, and get it back off the wire, and we'll never have these limited 'plugin' problems again
The audio world has *ALWAYS* been about interoperability, open specifications, and shared protocols. MIDI would never have come so far, and given us so much, if it weren't for the fact that hardware manufacturers took the time to figure out good ways to work together, in spite of competition. Audio effects architectures have always been very well documented - the average professional mixing desk has been designed from the ground up to be able to work with gear from *all* sorts of manufacturers, using simple protocols and specifications for audio signal routing. (XLR, balanced, etc)
This changed recently with the advent of software plugins, where hardly *ANY* companies are truly working with others to build a common platform - Oh sure, Digidesign have their TDM system, as do Microsoft, as do Steinberg, but pretty much all of these systems were developed from the ground up to be proprietary and to be used in giving 'market edge' to the respective owners.
Next year, software plugins won't be as badly implemented, and the audio world will actually be able to work cooperatively again... because of mLAN.
So, we should work on getting good mLAN/Firewire support in Linux, and develop open API's to solve the problem. Then you can build your Linux audio-rendering farm, hook it all up with mLAN, and forget about proprietary crappy interfaces for your audio work in the future...
; -- the corruption of government starts with its secrets. a truly free people keep no secrets. --
Given that network bandwidth would quickly become your bottleneck, it seems that going SMP would be a *much* more efficient (and cost-effective) solution.
Slashdot: come for the pedantry, stay for the condescension.
..for distributed computing.
Where you can use any other type of OS, and send a work order to a clustered network, for processing.
Of course, for this to become reality, it would require software manufacturers support. Which is where things fall out, not because of ignorance, but it just wouldn't be cost effective (why spend extra money on a feature few users would be able to use?).
This then presents another problem, inhouse development by individual companies based on need, with no outlook for distribution of this work. It's cool that some companies would be willing to sacrifice resources to develop a distributed solution for a product that they need, but there's no guarentee that they'll release it to the public afterwards.
Cheers,
leroy.