15 Dec
2004
15 Dec
'04
7:31 p.m.
On Wed, 2004-12-15 at 13:59, Mark Knecht wrote:
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.
I see, that makes it more complex.
On 15 Dec 2004 13:03:24 -0800, Fernando Lopez-Lezcano
<nando(a)ccrma.stanford.edu> wrote:
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.
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. - 1394a (400Mb/S)
- 1394b (800+Mb/S)
Let me know what you find. I'm curious, maybe there are tools available
that are open source.
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. 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. 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. 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.
Send me urls if you find any... Sounds like the right kind of hardware
to use for this.
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. 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