Subject: Re: Open Source Hardware (Re: [linux-audio-user] Re: [linux-audio-dev] RME is no more)
From: Fernando Lopez-Lezcano (nando_AT_ccrma.stanford.edu)
Date: Thu Dec 16 2004 - 01:31:34 EET
On Wed, 2004-12-15 at 13:59, Mark Knecht wrote:
> On 15 Dec 2004 13:03:24 -0800, Fernando Lopez-Lezcano
> <nando_AT_ccrma.stanford.edu> wrote:
> > > 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.
>
> OK, so as I see it we have a few choices:
> (Internal)
> - PCI
>
> (External)
> - PCI - Carbus variant - some physical interface to the box
> - USB 2.0 (480Mb/S)
This had not occured to me. Maybe even easier than 1394?
I would imagine that either 1394 or usb2 would be more flexible than a
pure pci approach (ie: it would be useful for laptops). Unless, of
course, you count pcmcia interfaces but they have their own set of
problems as demostrated by rme hardware having issues with some chipsets
in linux.
> - 1394a (400Mb/S)
> - 1394b (800+Mb/S)
>
> > I would be concerned about
> > the tools. Xilinx arrays will probably need closed source and expensive
> > software.
>
> Possibly. I'm not sure yet, but it's a very valid concern. If we were
> concerned about this then we should investigate other FPGA vendors
> (Altera, Lattice & others) to see if it's the same story. I don't
> know. I did a quick search in Google's Advance page for
>
> Xilinx
> Open Source Tools
>
> and found a large number of pages talking about this stuff. It may not
> be as bad as we are worrying about. I'll check more later.
Let me know what you find. I'm curious, maybe there are tools available
that are open source.
> > What I was thinking about was this:
> > - 1394 chip (off the shelf, no programming)
>
> not true exactly. more in a minute.
>
> > - (high speed?) ucontroller (off the shelf, use one that has open
> > source tools for programming it).
>
> Yes.
>
> > - line drivers for spdif and/or ADAT (driven from the ucontroller)
>
> Yes.
>
> > - DA/AD chips (driven from the ucontroller)
>
> If we go with local conversion. More noise issues, etc., but
> manageable if we want to deal with it. Probably this ends up with a
> lower cost for a 2-4 I/O sound card, but for higher port count it will
> get ore expensive and I don't think we add much value doing that part.
> You used to be able to buy an AI-3 on EBay for around $200 IIRC. Right
> now there are none so maybe all of those are gone and we need to find
> acceptable external conversion units in different price ranges.
The DA/AD and even the spdif/adat interfaces could be optional. Or
modular. If this is an external box then that is more of an option.
> > So, this approach would reduce the problem to hardware interconnection
> > of logic parts (rather easy) and firmware for the ucontroller (hard).
>
> OK, this is where I think it gets difficult. I'll give some overview
> ideas and then we can go from there.
>
> Asynchronous 1394 is a 'memory mapped' packet. The packets are
> addressed to a specific device on the bus (Bus #, ID #) and then they
> carry an address. The 1394 model assumes that the packet is delivered
> to memory in the remote device and then the remote device does with it
> what it wants to do with it. If you delve a bit deeper into the
> hardware behind this idea what you eventually run into is that the
> 1394 controller has/needs a DMA unit and the box has memory.
I see, that makes it more complex.
> The 1394
> chip delivers the packet to memory and then the uC deals with it when
> it can. This is generally needed since the uC cannot respond fast
> enough to keep up with all the packets.
That was why I was asking if it was possible at all. I was hoping the
chip would have an option for non-mmaped access. If that were the case
then you could trade complexity (ie: mmaped ram) for speed in the
external ucontroller so that it can deal with all the packets on the
fly.
> This is the basic idea behind
> a 1394 OHCI controller. All the processor is doing is setting up a
> linked list of memory addresses. The OHCI controller is accessing that
> list, using the address in the DMA controller, and moving data in and
> out of memory. It works fine except it assumes an OHCI stack (implying
> at least part of an OS) and it assumes memory. Both of these are
> expensive in different ways when you talk about high speed data
> packets and personally I'd rather avoid it. However I cannot
> completely ignore Async operation as it's required to be recognized on
> the bus.
>
> On the other hand, Isochronous 1394 just delivers data on a channel.
> There is a destination address again, but it's just a channel number.
> (0-63, 63 being broadcast) Any device that wants the data just watches
> for packets with the right channel number, chunks it into a FIFO and
> uses it for whatever purpose. If data is missing then you get a
> crackle, snap or pop. However there is no real processor intervention
> (or doesn't technically have to be) with the data. Conceptually it
> could just arrive as a serial bit stream, be reformatted by some
> simple hardware machine into 24-bit parallel data, and be delivered to
> the D/A and you get sound. It could also be reformatted and delivered
> to s/pdif or ADAT and sent on again.
Hmmm, interesting. So this mode would be a possibility for a really dumb
and simple peripherial.
> The CPU overhead with Iso 1394 is basically very low which is why it
> works for video, etc.
>
> So, I guess the point here is that making a complete, 1394-based
> device is fairly difficult and possibly a bit more expensive than
> doing something in an FPGA. There are 1394 devices that are uC-based
> but I don't know if they are supported by Open Source tools.
>
> The other thing is that, again, as FPGAs improve you get more
> functionality over time and can add more capability to the boards.
> (Ala Creamware, etc.)
You mean hardware capabilities, right? Because a firmware based
controller would be also upgradable. And/or you could use faster chips
when they become available.
> Personally I like that idea even if it costs me
> a bit more, but I'm not making the final decision here.
This is all (for now) theory :-)
> It's
> completely open. What I can *possibly* do it try to work out some part
> costs.
>
> I think this would, like all other projects, require a web site to
> post ideas, drawings, schematics, etc. How would we do that?
> Sourceforge? Somewhere else? I can draw system diagrams very quickly
> but they need to be posted somewhere for others to look at and vote
> on.
>
> > The question would be, it this doable with available ucontrollers that
> > have open source compiler toolchains?
>
> Dunno. We could leverage the Linux 1394 stack and try to do this with
> a uC and an OHCI controller. If it's not OHCI then the Linux stack
> does us very little good.
>
> Via and others make peripheral oriented 1394 chips. They get used in
> many embedded devices and are probably about right for this sort of
> project. I could look into that over the next few weeks.
Send me urls if you find any... Sounds like the right kind of hardware
to use for this.
> Good project
> when sitting in front of the TV late at night. After we find a few
> we'd have to cross reference against Open Source tools. That would
> take some help from others.
>
> And we haven't discussed it, but maybe there are completely different
> architectural ideas we should look at. For instance, what about a
> device that ONLY worked with Jack? I have a suspicion that this might
> be interesting and less expensive, but that's just a guess right now.
> Would be sort of cool to make a card that DIDN'T work with Windows.
> ;-)
:-)
-- Fernando
This archive was generated by hypermail 2b28 : Thu Dec 16 2004 - 01:36:27 EET