Open Source Hardware (Re: [linux-audio-user] Re: [linux-audio-dev] RME is no more)

[Fernando Lopez-Lezcano]

On Wed, 2004-12-15 at 11:24, Mark Knecht wrote:
> On 15 Dec 2004 10:29:38 -0800, Fernando Lopez-Lezcano
> <nando at ccrma.stanford.edu> wrote:
> > On Tue, 2004-12-14 at 09:46, Mark Knecht wrote:
> > > On 14 Dec 2004 10:03:31 +0100, Andreas Kuckartz <A.Kuckartz at ping.de> wrote:
> > > > Lee Revell wrote:
> > > >
> > > > > Christ, what the fuck country do you live in?  Don't you understand the
> > > > > concept of people having bills to pay?  Or do you just assume the RME
> > > > > guys are independenly wealthy and just design sound cards for fun?
> > > >
> > > > Interestingly some people seem to be existing who are working on Linux for fun.
> > > > Also there is a concept known as "Open Source Hardware" which was mentioned here
> > > > before.
> > >
> > > Actually, it was Lee and I (I think) who were the main proponents of
> > > the Open Source Sound Card idea. Funny how that works out at times.
> > >
> > > My current thought is that there aren't enough people interested in
> > > doing it. Maybe I'm wrong?
> > 
> > Maybe, maybe not. One quick question I have been meaning to ask. Would
> > it be possible to completely drive the card with firmware? What I mean,
> > can all the packet processing be handled by an onboard processor in the
> > soundcard? No gate arrays? What I picture is of-the-shelf components
> > only... [*]
> > 
>    I believe this is (more or less) completely possible. Let's use two
> of the recently maligned RME's products as an example - the HDSP 9652
> and the Hammerfall Light. (Hey - imagine that?! I chose the two cards
> I own!) ;-)
> 
> [MUNCH]
>
>    With the price of Xilinx chips coming down all the time, and with
> functionality going up, I see a small card with one large FPGA, a
> small eeprom to enable a PCI enterface in the chip, and some
> transceivers for ADAT and/or s/pdif. I am just guessing that even in
> small volumes this can probably be built for under $300/card. (That's
> a total guess.)
> 
>    The nice thing about this, in my mind, is that when Xilinx comes
> out with each new generation you can imagine putting a bigger Xilinx
> chip on the same card and programming more interesting things, like
> hardware mixers. This is rally all RME did between the Hammerfall and
> HDSP line. (I'm being purposely simplistic here.)
> 
>    There are certainly HUGE challenges for a group of folks like us
> doing this. Verilog (or VHDL) design, which I don't do, compiling that
> code into something that programs the Xilinx chips (Symplicity?)
> assembly, testing, etc., but none of it is unsurmountable. It just
> takes some vision and, unfortunately, some money unless we can get
> access to some Open Source tools or, possibly, commercial tools
> through some friendly company.
> 
>    Doing this as a 1394-based external unit is really interesting, but
> is more complicated. Maybe PCI is the best for now.

I'm not so sure PCI would be the best answer for a project like this
one, and that was the point of the question. I would be concerned about
the tools. Xilinx arrays will probably need closed source and expensive
software.

What I was thinking about was this:
- 1394 chip (off the shelf, no programming)
- (high speed?) ucontroller (off the shelf, use one that has open
  source tools for programming it). 
- line drivers for spdif and/or ADAT (driven from the ucontroller)
- DA/AD chips (driven from the ucontroller)

So, this approach would reduce the problem to hardware interconnection
of logic parts (rather easy) and firmware for the ucontroller (hard). 

The question would be, it this doable with available ucontrollers that
have open source compiler toolchains?

-- Fernando