Re: [linux-audio-user] Re: [linux-audio-dev] Re: [Alsa-devel] Firewire Audio Card Support

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

Subject: Re: [linux-audio-user] Re: [linux-audio-dev] Re: [Alsa-devel] Firewire Audio Card Support
From: Brad Fuller (brad_AT_sonaural.com)
Date: Fri Nov 19 2004 - 04:19:45 EET


Mark Knecht wrote:

>On Fri, 19 Nov 2004 02:24:59 +0100, Florian Schmidt <mista.tapas_AT_gmx.net> wrote:
>
>
>>>rom my POV a more interesting idea would be to do an external sound
>>>device, probably 1394 based since that will work for more people.
>>>Please remember that a PCI card is almost useless for laptop users
>>>unless we're trying to put this into a cardbus formal also. That adds
>>>money.
>>>
>>>If it was 1394 based then you can put a 1394 adapter in your PC for
>>>$20 and then everyone uses the same audio unit. We control how it
>>>works, so we can follow specs or do it in our own standard. You get
>>>the advantage of probably more channels and better SNR, but you do
>>>have to package the unit in a box or some type to be of general use.
>>>
>>>Anyway, those are some ideas for you to chew on. Hope I haven't poked
>>>a balloon with a pin here...
>>>
>>>
>>No, i find the alternative of a 1394 device completely acceptable, too. But
>>how much cheaper would it be? I suppose the logic for talking to the 1394 bus
>>[?? i don't know anything about firewire, except for 1. serial, 2. faster
>>than USB] can be put into a FPGA again, right?
>>
>>For the sake of an example, let's choose a stereo full duplex device with
>>48khz only samplerate, and with medium to good quality AD/DA's. So we got
>>like 15-30 bucks for the DA/AD's. What's the rest? How expensive is the FPGA
>>to control all this? What else is needed? Ok, a case mustn't be pretty, so i
>>suppose anything will do -> 2-3$ :)
>>
>>Flo
>>
>>
>Well, I guess my thought is that with a 1394 device we can just buy
>standard links and Phys and sort of wire things together without going
>to a full-fledged bus structure like PCI. I may be wrong about that.
>The most common Link devices are 1394 OCHI and they are generally PCI
>based so that puts us back into all of this stuff.
>
>Think about this from another direction though. The 2-channel cards
>are always going to be cheap since that's what most of the world wants
>and that's where the big companies provide value. I don't think we can
>do anything at that number of channels that makes a lot of financial
>sense.
>
>However, what about a much bigger devices, competing more or less with
>an RME HDSP 9652 or a DigiFace? If we went that direction then there
>isn't all that much incremental cost to add the channels (we can talk
>about this later) but we get another degree of flexibility. Think of
>this like a Digiface, or a MultiFace, or a Delta-1010 class device,
>but most importantly with built-in reprogrammable DSP capability.
>wouldn't that be cool? How about the ability to run LADSPA plugins in
>hardware. To me that sound exciting, and would open up a really
>interesting new way to use all the programming talent we have around
>these forums.
>
>If we could come up with a process to take a ladspa plugin and map it
>to gates in an FPGA then Linux audio would suddenly jump up to the
>level of product like the higher end Creemware machines and start
>approaching some of the lower-end pro versions of Pro Tools.
>
>Instead of a $400 2 channel PCI card we might end up with a $600
>16-in/16-out device with hardware signal processing on board. To me
>this is probably a better place to go. If we do all this work ten we
>want to start working towards an architecture that will last.
>
>
Taking ladspa and mapping it to FPGA: how? and how would you do this
efficiently, if you could do it? A C function to VHDL function
convertor? (it's been a long time since I've worked with FPGAs. I'm sure
there are advances)
It might be more cost effective to use DSPs -- that is: more cost
effective in the long run for everybody -- mostly the end user.

brad


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

This archive was generated by hypermail 2b28 : Fri Nov 19 2004 - 04:23:10 EET