Re: [linux-audio-dev] Re: GPL Audio Hardware

From: Pieter Palmers <pieterp@email-addr-hidden>
Date: Tue Apr 04 2006 - 23:38:36 EEST

Richard Smith wrote:
> On 4/4/06, carmen <ix@email-addr-hidden> wrote:
>
>
>>>how expensive is a firewire port ?
>>>firewire stuff is THE niche to fill.
>>>most newer firewire devices are not supported if if i understand
>>>correctly.
>
>
> I'll ask. That's a fairly large difference to the current design
> though. But if there was enough interest perhaps.
> For it to fit into the current model someone would have to do the VHDL
> code for a firewire interface rather than PCI. I don't think Tim is
> opposed to a totally different design but there would be less reuse
> from what they already have.

If you want to build a firewire soundcard, use the 1394 chipsets already
available from different manufacturers. Don't start writing your own
VHDL... it's not worth it. They did the $2M investment to develop the
ASIC and are selling their chips for a pretty good price.

 From what I understand the BridgeCo DM1500, the successor of the DM1000
that is used in e.g. the edirol FA101 etc, has a price tag that is about
the same of a FPGA that can implement the same functionallity.

It should also be able to do single packet latency processing with the
DM1500 (1 firewire packet equals 8 frames). This would make the
roundtrip latency of the DM1500 - D/A - A/D - DM1500 about 2*8/Fs +
AD/DA latency. This comes down to about 1-2ms depending on the
dataconverters used.

I've recently looked at the datasheet of the DICE-II chipset, and that
also handles all firewire to audio (I2S) conversion and framing for >32
channels in each direction. But I don't know how it performs.

Count some extra latency introduced by the PC host controller though.
I'm sorry to say, but a PCI based system will always be intrinsically
lower latency than a FW based system. This is because there is a
PCI-to-FireWire bridge present (the host controller). On top of that,
virtually all host controllers are OHCI compliant, with only a few
vendors selling OHCI chipsets (TI, VIA, NEC, ...) upon which all card
manufacturers base their designs. Apparently only TI based OHCI chipsets
perform good wrt lowest latency they can handle (although I can't prove
this, someone that tested them told me).

Why reinvent the wheel? If anything firewire related should be built,
the best thing would be a firewire host controller that has built in
support for (de)framing the firewire packets, directly into host memory.
But why bother using firewire device then...

And then we're not even talking about the drivers that have to be
written... The freebob project at this point consists of only 2 people,
notwithstanding the fact that we do have active manufacturer support and
all nescessary documentation. The hardware is out, is priced pretty good
and is of quite good quality (e.g. the edirol fa-101, $500 at
zzsound.com). The basic functionallity is already present for a year
(demo-ed at LAC last year), and we (at least I) expected that getting
that code ready in time for LAC would help us getting more people
interested in helping. But alas, up till now no contributions have been
made.

So I ask myself: Would anyone here pay much more than $500 for a similar
device that probably won't reach the same performance as currently
available devices, and where the drivers still have to be written for.
Based upon my experience, I might be sceptical, but I don't think so.

My opinion: If the community wants a GPL like firewire audio device, I
suggest that you base it on the DM1500 chip, and help us out with
FreeBob. That way you can actually get to a decent device with a decent
performance in a realistic timeframe.

Pieter Palmers
FeeBob developer

PS: Although the previous might make you think the opposite, I'm NOT on
the BridgeCo payroll nor do I own any BridgeCo shares.

PPS: The FreeBob project is written in such a way that other firewire
based devices can be supported too. For the moment the DM1x00 based
devices are the only ones we have the nescessary info for. But there
might be others soon.
Received on Wed Apr 5 00:15:06 2006

This archive was generated by hypermail 2.1.8 : Wed Apr 05 2006 - 00:15:06 EEST