18 Feb
2005
18 Feb
'05
5:01 a.m.
Hi folks,
currently, all signal processing algos are being done in software for
Linux Audio.
are there any hardware accelerated support for audio hardware when doing
these sort of algos?
what I mean is, graphics card manufacturers have hardware acceleration
where the X servers can support those acceleration. do we have it in audio?
for now, RME cards do not have DSPs in them yet. (as far as i know)
they only have audio signal routings and high quality audio paths.
what if we want to experiment with h/w dsp? (e.g. the 1820m from
creative professional aka emu)
jipi
18 Feb
18 Feb
5:57 a.m.
On Fri, Feb 18, 2005 at 05:00:52PM -0800, jipi wrote:
Hi folks,
currently, all signal processing algos are being done in software for
Linux Audio.
are there any hardware accelerated support for audio hardware when doing
these sort of algos?
None of the linux audio DSP software will run on DSP hardware as far as I
know. Converting the stuff we write to DSP code is a significant effort,
and just not worth it IMHO. Buy a faster CPU :) Given the price perfomance
of modern x86 chips you probably get more bang for your buck that way
anyway.
c.f. http://www.ardour.org/native.html
- Steve
7:08 a.m.
jipi wrote:
currently, all signal processing algos are being done
in software for
Linux Audio.
are there any hardware accelerated support for audio hardware when doing
these sort of algos?
If you bend the definition of "hardware accelerated" enough, SIMD
extensions like MMX/SSE... would qualify. :)
what if we want to experiment with h/w dsp?
The DSP on emu10k1 cards is the only one supported in Linux.
(e.g. the 1820m from creative professional aka emu)
I don't know how similar that DSP is to the one on Creative's game
("consumer") cards, but it probably is somewhat related. But Creative
doesn't release documentation, so we can forget it.
Clemens
7:48 a.m.
On Fri, Feb 18, 2005 at 12:08:35PM +0100, Clemens Ladisch wrote:
I think some of the general purpose DSP PCI cards are supported, but they
cost serious money. e.g. http://www.agelectronics.co.uk/dp12.html
- Steve
jipi wrote:
Heh, yeah, though we dont support those that well, until gcc4 is out.
There is a problem to do with building LADSPA plugins that makes it hard to
hand over SSE-built functions on SSE capable machine, and 387 otherwise
from a single .so, which is a shame, but I cant think of an easy way round
it.
currently, all signal processing algos are being
done in software for
Linux Audio.
are there any hardware accelerated support for audio hardware when doing
these sort of algos?
If you bend the definition of "hardware accelerated" enough, SIMD
extensions like MMX/SSE... would qualify. :) what if we
want to experiment with h/w dsp?
The DSP on emu10k1 cards is the only one supported in Linux.
22 Feb
22 Feb
12:41 a.m.
Hi All,
I was thinking,
we always have dedicated graphic cards for gaming/3D rendering etc..
why don't we have some h/w optimised audio algos running on some
FPGA/DSP/ etc...
...
on linux...
look at these.. are there simple/cheap/open versions of these?
http://www.lyrtech.com/DSP-development/audio/index.php
http://www.zpeng.com/Articles/Section1/digitalaudio.html
http://www.altera.com/products/devkits/partners/kit-ate-dmck.html
http://lts1pc19.epfl.ch/repository/Simeonov2004_737.pdf
what we require is a separate card which can take a few channels of
audio lines and process them in a cheap FPGA/DSP (put in your favourite
**HW LADSPA** algo).. and route them back to the main audio card..
of course I am for the idea of using clusters of linux PCs while some of
them do different types of audio processing,
but not everyone has access to more than 1 PC.. : >
jipi
Steve Harris wrote:
On Fri, Feb 18, 2005 at 12:08:35PM +0100, Clemens
Ladisch wrote:
I think some of the general purpose DSP PCI cards are supported, but they
cost serious money. e.g. http://www.agelectronics.co.uk/dp12.html
- Steve
jipi wrote:
Heh, yeah, though we dont support those that well, until gcc4 is out.
There is a problem to do with building LADSPA plugins that makes it hard to
hand over SSE-built functions on SSE capable machine, and 387 otherwise
from a single .so, which is a shame, but I cant think of an easy way round
it.
currently, all signal processing algos are being
done in software for
Linux Audio.
are there any hardware accelerated support for audio hardware when doing
these sort of algos?
If you bend the definition of "hardware accelerated" enough, SIMD
extensions like MMX/SSE... would qualify. :)
what if we
want to experiment with h/w dsp?
The DSP on emu10k1 cards is the only one supported in Linux.
5:20 a.m.
On Tuesday 22 February 2005 05.41, jipi wrote:
Hi All,
I was thinking,
we always have dedicated graphic cards for gaming/3D rendering etc..
why don't we have some h/w optimised audio algos running on some
FPGA/DSP/ etc...
Because there isn't enough demand for it. Only musicians have any
serious use for that kind of hardware, whereas half the planet needs
accelerated graphics - especially with all the eyecandy that
Microsoft, Apple, the KDE and Gnome people etc have decided we
need. ;-)
on linux...
Dito. The state of accelerated audio on Linux should realistically
relate to the corresponding on Windows and Mac in the same way as 3D
acceleration on Linux vs Windows and Mac - and it pretty much does, I
think... Some popular hardware is supported by Free/Open Source
drivers to some extent, some vendor has tried to support the Linux
community to some extent, and that's about it.
look at these.. are there simple/cheap/open versions
of these?
Simple: Not possible, unless you'll settle for a toy synth...
Cheap: Cheap and good are basically mutually exclusive when it comes
to hardware. The best you can do is to use high volume components.
Currently, that means standard general purpose DSP chips for small
devices, and probably AMD64 chips for heavier gear.
Open: Only if you're ready to pay a premium for the "lost revenue"
resulting from opening up the "trade secrets". You don't want to
design some cool hardware only to have some foreign company make a
clone of it, sell it dirt cheap (*you* paid the development costs!)
and put you out of business. That doesn't mean you have to close both
the design *and* the programming info, but try to explain that to the
management of your average company... Also try to explain why they
should be taking the risk of making reverse engineering easier for no
significant monetary gain.
http://www.lyrtech.com/DSP-development/audio/index.php
http://www.zpeng.com/Articles/Section1/digitalaudio.html
http://www.altera.com/products/devkits/partners/kit-ate-dmck.html
http://lts1pc19.epfl.ch/repository/Simeonov2004_737.pdf
what we require is a separate card which can take a few channels of
audio lines and process them in a cheap FPGA/DSP (put in your
favourite
**HW LADSPA** algo).. and route them back to the main audio card..
If it's actually supposed to do something serious, it won't be cheap.
Really powerful DSPs are nowhere near cheap.
If you're into dedicated hardware anyway, why not just hook up a PC
(SBC, perhaps; though you still get more power/$ if you buy standard
mainstream PC components) running RTLinux or RTAI? Cheaper and much
easier to deal with...
of course I am for the idea of using clusters of linux
PCs while
some of them do different types of audio processing,
but not everyone has access to more than 1 PC.. : >
Well, if you can get any DSP hardware worth using, you might as well
get another PC... As an extra bonus, you get a "universal machine",
as opposed to some oddball DSP card that you're hard pushed to even
get it to do what you purchased it for.
Now, if you really don't want to use another PC, and want lots of dirt
cheap processing power, how about learning some EMU10k1 asm? :-)
Seems to have more DSP power than your average studio sampler - and
since it's a high volume product, just like the 3D accelerators, it
lets you see some of the "silicon is free" effect. That's the closest
audio gets to the state of 3D acceleration currently, AFAIK.
//David Olofson - Programmer, Composer, Open Source Advocate
.- Audiality -----------------------------------------------.
| Free/Open Source audio engine for games and multimedia. |
| MIDI, modular synthesis, real time effects, scripting,... |
`-----------------------------------> http://audiality.org -'
--- http://olofson.net --- http://www.reologica.se ---
5:43 a.m.
On Tue, Feb 22, 2005 at 10:21:21 +0100, David Olofson wrote:
On Tuesday 22 February 2005 05.41, jipi wrote:
Yes, except that the Cell processor is quite DSP like with 8 floating
point processors per cell, I dont know if it will ever become afordable
in some package thats available to consumers, but it would be very good
for audio processing.
- Steve
Hi All,
I was thinking,
we always have dedicated graphic cards for gaming/3D rendering etc..
why don't we have some h/w optimised audio algos running on some
FPGA/DSP/ etc...
Because there isn't enough demand for it. Only musicians have any
serious use for that kind of hardware, whereas half the planet needs
accelerated graphics - especially with all the eyecandy that
Microsoft, Apple, the KDE and Gnome people etc have decided we
need. ;-) 
2:41 p.m.
Steve Harris wrote:
The cell is arranged in vectors though, so might not be optimized for
classical DSP algorithms.
The upcoming vmx2/altivec2 on the other hand, will rewire the double
registers for taking complex FFTs and such.
Because there
isn't enough demand for it. Only musicians have any
serious use for that kind of hardware, whereas half the planet needs
accelerated graphics - especially with all the eyecandy that
Microsoft, Apple, the KDE and Gnome people etc have decided we
need. ;-)
Yes, except that the Cell processor is quite DSP like with 8 floating
point processors per cell,
... I dont know if it will ever become afordable
in some package thats available to consumers, but it would be very good
for audio processing.
It will be afordable at some point in time ... in a consumer package
from sony.
6:08 a.m.
One could think about using 3D graphics hardware for audio DSP purposes. There
are commercial projects which do that (only for Windows AFAIK).
Cheers,
Andreas
----- Original Message -----
From: "David Olofson" <david(a)olofson.net>
To: "The Linux Audio Developers' Mailing List"
<linux-audio-dev(a)music.columbia.edu>
Sent: Tuesday, February 22, 2005 10:21 AM
Subject: Re: [linux-audio-dev] Linux DSP Hardware?
On Tuesday 22 February 2005 05.41, jipi wrote:
Hi All,
I was thinking,
we always have dedicated graphic cards for gaming/3D rendering etc..
why don't we have some h/w optimised audio algos running on some
FPGA/DSP/ etc...
Because there isn't enough demand for it. Only musicians have any
serious use for that kind of hardware, whereas half the planet needs
accelerated graphics - especially with all the eyecandy that
Microsoft, Apple, the KDE and Gnome people etc have decided we
need. ;-)
on linux...
Dito. The state of accelerated audio on Linux should realistically
relate to the corresponding on Windows and Mac in the same way as 3D
acceleration on Linux vs Windows and Mac - and it pretty much does, I
think... Some popular hardware is supported by Free/Open Source
drivers to some extent, some vendor has tried to support the Linux
community to some extent, and that's about it.
look at these.. are there simple/cheap/open
versions of these?
Simple: Not possible, unless you'll settle for a toy synth...
Cheap: Cheap and good are basically mutually exclusive when it comes
to hardware. The best you can do is to use high volume components.
Currently, that means standard general purpose DSP chips for small
devices, and probably AMD64 chips for heavier gear.
Open: Only if you're ready to pay a premium for the "lost revenue"
resulting from opening up the "trade secrets". You don't want to
design some cool hardware only to have some foreign company make a
clone of it, sell it dirt cheap (*you* paid the development costs!)
and put you out of business. That doesn't mean you have to close both
the design *and* the programming info, but try to explain that to the
management of your average company... Also try to explain why they
should be taking the risk of making reverse engineering easier for no
significant monetary gain.
http://www.lyrtech.com/DSP-development/audio/index.php
http://www.zpeng.com/Articles/Section1/digitalaudio.html
http://www.altera.com/products/devkits/partners/kit-ate-dmck.html
http://lts1pc19.epfl.ch/repository/Simeonov2004_737.pdf
what we require is a separate card which can take a few channels of
audio lines and process them in a cheap FPGA/DSP (put in your
favourite
**HW LADSPA** algo).. and route them back to the main audio card..
If it's actually supposed to do something serious, it won't be cheap.
Really powerful DSPs are nowhere near cheap.
If you're into dedicated hardware anyway, why not just hook up a PC
(SBC, perhaps; though you still get more power/$ if you buy standard
mainstream PC components) running RTLinux or RTAI? Cheaper and much
easier to deal with...
of course I am for the idea of using clusters of
linux PCs while
some of them do different types of audio processing,
but not everyone has access to more than 1 PC.. : >
Well, if you can get any DSP hardware worth using, you might as well
get another PC... As an extra bonus, you get a "universal machine",
as opposed to some oddball DSP card that you're hard pushed to even
get it to do what you purchased it for.
Now, if you really don't want to use another PC, and want lots of dirt
cheap processing power, how about learning some EMU10k1 asm? :-)
Seems to have more DSP power than your average studio sampler - and
since it's a high volume product, just like the 3D accelerators, it
lets you see some of the "silicon is free" effect. That's the closest
audio gets to the state of 3D acceleration currently, AFAIK.
//David Olofson - Programmer, Composer, Open Source Advocate
.- Audiality -----------------------------------------------.
| Free/Open Source audio engine for games and multimedia. |
| MIDI, modular synthesis, real time effects, scripting,... |
`-----------------------------------> http://audiality.org -'
--- http://olofson.net --- http://www.reologica.se ---
6:23 a.m.
On Tue, Feb 22, 2005 at 11:11:25 +0100, Andreas Kuckartz wrote:
One could think about using 3D graphics hardware for
audio DSP purposes. There
are commercial projects which do that (only for Windows AFAIK).
There are also some free projects, but IIUC, the kinds of precessing you
can do are quite limited, it has to be fairly high latency as you need to
move the audio data to the card in large blocks.
- Steve
1:22 p.m.
Steve Harris <S.W.Harris(a)ecs.soton.ac.uk> writes:
On Tue, Feb 22, 2005 at 11:11:25 +0100, Andreas
Kuckartz wrote:
The OpenVIDIA project[1] opens up nVIDIA GPUs for general purpose
computing. I suppose this could include audio, but I have no idea
what the latencies would be. The bandwidth to the GPU is quite
impressive.
[1] http://openvidia.sourceforge.net
--
joq
One could think about using 3D graphics hardware
for audio DSP
purposes. There are commercial projects which do that (only for
Windows AFAIK).
There are also some free projects, but IIUC, the kinds of precessing
you can do are quite limited, it has to be fairly high latency as
you need to move the audio data to the card in large blocks.
4:42 p.m.
GPGPU /Audio and Signal Processing
http://www.gpgpu.org/cgi-bin/blosxom.cgi/Audio%20and%20Signal%20Processing/…
.html
----- Original Message -----
From: "Jack O'Quin" <joq(a)io.com>
To: "The Linux Audio Developers' Mailing List"
<linux-audio-dev(a)music.columbia.edu>
Sent: Tuesday, February 22, 2005 6:25 PM
Subject: Re: [linux-audio-dev] Linux DSP Hardware?
Steve Harris <S.W.Harris(a)ecs.soton.ac.uk>
writes:
On Tue, Feb 22, 2005 at 11:11:25 +0100, Andreas
Kuckartz wrote:
The OpenVIDIA project[1] opens up nVIDIA GPUs for general purpose
computing. I suppose this could include audio, but I have no idea
what the latencies would be. The bandwidth to the GPU is quite
impressive.
[1] http://openvidia.sourceforge.net
--
joq
One could think about using 3D graphics hardware
for audio DSP
purposes. There are commercial projects which do that (only for
Windows AFAIK).
There are also some free projects, but IIUC, the kinds of precessing
you can do are quite limited, it has to be fairly high latency as
you need to move the audio data to the card in large blocks.
23 Feb
23 Feb
12:06 a.m.
Andreas Kuckartz wrote:
GPGPU /Audio and Signal Processing
http://www.gpgpu.org/cgi-bin/blosxom.cgi/Audio%20and%20Signal%20Processing/…
this looks really promising. thanks for the link Andreas!
jipi
27 Feb
27 Feb
2:25 p.m.
On Tue, 2005-02-22 at 10:23 +0000, Steve Harris wrote:
On Tue, Feb 22, 2005 at 11:11:25 +0100, Andreas
Kuckartz wrote:
<ignorant question> So why can't you move smaller chunks more often?
--
Florin Andrei
http://florin.myip.org/
One could think about using 3D graphics hardware
for audio DSP purposes. There
are commercial projects which do that (only for Windows AFAIK).
There are also some free projects, but IIUC, the kinds of precessing you
can do are quite limited, it has to be fairly high latency as you need to
move the audio data to the card in large blocks.
5:08 p.m.
On Sun, Feb 27, 2005 at 10:25:47 -0800, Florin Andrei wrote:
On Tue, 2005-02-22 at 10:23 +0000, Steve Harris
wrote:
<wild guesswork> Youre misusing the texture processing stuff, the cards
aren't optimised to do it (especailly sending stuff back to the host), and
it all has to go over the AGP bus.
The hardwar is not designed to do streaming processing, so it not
supprising if it can't do it very well.
- Steve
On Tue, Feb 22, 2005 at 11:11:25 +0100, Andreas
Kuckartz wrote:
<ignorant question> So why can't you move smaller chunks more often? One could think about using 3D graphics hardware
for audio DSP purposes. There
are commercial projects which do that (only for Windows AFAIK).
There are also some free projects, but IIUC, the kinds of precessing you
can do are quite limited, it has to be fairly high latency as you need to
move the audio data to the card in large blocks. 
18 Feb
18 Feb
8:20 a.m.
New subject: [linux-audio-dev] AlsaModularSynth and Q*-tools (Kalsatools)
Hello,
due to new responsabilities at SuSE I will no longer have the time to
develop and maintain the many Q*-tools I developed in the past years.
While some of them have been obsoleted by other nice tools, part of them
might be worth to be further maintained or integrated into larger apps.
Recently I got increased feedback mail regarding QAMix. I believe that the
concept of this configurable mixer offers an interesting solution to the
challenge of managing the wide range of hardware we find for soundcards.
I moved all sources to alsamodular.sourceforge.net
In case anybody is interested in either continuing the development or
reusing the code, please let me know.
Matthias
1:01 p.m.
On Fri, 2005-02-18 at 12:08 +0100, Clemens Ladisch wrote:
True but the emu10k1/2 instruction set is well known.
Lee
what if we
want to experiment with h/w dsp?
The DSP on emu10k1 cards is the only one supported in Linux.
(e.g. the 1820m from creative professional aka
emu)
I don't know how similar that DSP is to the one on Creative's game
("consumer") cards, but it probably is somewhat related. But Creative
doesn't release documentation, so we can forget it. 
5:31 p.m.
Hey Jipi,
There has been some fuss in the past about linux drivers for some of the
Creamware products. It's been mentioned that drivers for linux are back
under development but creamware has swayed on this issue before. I
couldn't say exactly what is going on in this area, but I consider these
one of the nicer and affordable dsp options out there. unfortunately
mine has been collecting dust as i have given up on trying to write a
workable driver for it.
see the scope platform at creamware.com.
creamware forum w/ dated mentions of linux drivers:
http://www.planetz.com/forums/viewforum.php?forum=5&18745
if you find anything useful please let us know :). you just might be
better off trying to get some audio distributed on a cluster of x86
machines running l4linux or something as opposed to optimizing dsp
routines for a completely different arch. maybe someone is already
doing something like this?
-s
On Fri, 2005-02-18 at 19:00, jipi wrote:
Hi folks,
currently, all signal processing algos are being done in software for
Linux Audio.
are there any hardware accelerated support for audio hardware when doing
these sort of algos?
what I mean is, graphics card manufacturers have hardware acceleration
where the X servers can support those acceleration. do we have it in audio?
for now, RME cards do not have DSPs in them yet. (as far as i know)
they only have audio signal routings and high quality audio paths.
what if we want to experiment with h/w dsp? (e.g. the 1820m from
creative professional aka emu)
jipi
21 Feb
21 Feb
5:31 a.m.
Shane wrote:
There has been some fuss in the past about linux
drivers for some of the
Creamware products. It's been mentioned that drivers for linux are back
under development but creamware has swayed on this issue before. I
couldn't say exactly what is going on in this area,
In March 2004, a mailing list for OSX/Linux developers was formed.
The last mail is from September 2004 and says that the paperwork
required for an NDA so that people can start talking about how to
design any driver hasn't yet been done.
Clemens
7009
days inactive
7018
days old
linux-audio-dev@lists.linuxaudio.org
18 comments
11 participants
participants (11)
-
Andreas Kuckartz -
Clemens Ladisch -
David Olofson -
Florin Andrei -
Jack O'Quin -
Jens M Andreasen -
jipi -
Lee Revell -
Matthias Nagorni -
Shane -
Steve Harris