More than one audio codec on a PC mobo

[Joerg]

upsidedown@downunder.com wrote:

On Fri, 28 Feb 2014 16:18:41 -0800, Joerg <invalid@invalid.invalid
wrote:

No. I wanted to know how to line up umpteen audio codecs in a way that
they talk to a PC and remain 100% synchronous. Using ADCs for otyher
markets is expensive.

You did not say anything about expected production volumes (just a one
off project or thousands of units) and hence is it feasible to design
your own PCI card.

Initially in the hundreds/year but must have a chance to become a
high-vlumen product without major architectural changes.

If you have to design your own PCI card, what is wrong with the old
stereo audio ADCs such as the CS5394, apart from the board space
needed for 10+ stereo ADC chips ?

Nothing wrong with that. I was simply wondering if there'd be any
simpler and more contemporary method, for example via USB. This is how
SDR is done, with huge data streams.

It has differential inputs, a 2 Hz audio high pass (so no DC
measurement) and I˛S interface. It can operated both in master or
slave mode, put one in master mode and the rest in slave mode and tie
all the clock signals together.

Of course you will need a FPGA to convert these I˛S signals serial
signals to something usable for a computer, such as 32 bit parallel
words/sample to presented to the PCI bridge chip.

If some serial interface such as Ethernet, USB or PCIe is used, then
put the sample from every channel into the same frame (preferably 32
bits/sample to simplify CPU load), thus all samples from a particular
time would be guarantied to be available in the same frame.

Yes. I know pretty much how to do it, was just wondering if there is an
alternative to a brute force FPGA approach.

Then you will have to think how you will get the data from the PC
interface card into memory, perhaps DMA or interrupt driven. However,
if every sample will generate an interrupt, there would be 40000
interrupts each second at 40 kHz sampling rate, which is quite a lot.
Transferring 40 samples for each interrupt would give 1000
interrupts/second, which is a reasonable value.

If the data is to be processed with some soft-RT system, such as
Windows or Linux, you may still need quite a lot of software FIFO
buffering between the ISR and user mode code.

So it is not just the ADC interface you need to consider but also
other parts of the system, in order to avoid making some local
optimizing that greatly harms the rest of the system.

Yeah, writing our own driver, that will be a major bear and this is at
least half the reason why I asked for an already existing
"off-the-shelf" method. And maybe with ADAT there is one. Although
somewhat limited as well, AFAIK even the high channel number Focusrite
Safire interface is restricted to 16 audio channels into the PC. But ...
this could be an avenue with less engineering effort than a card with a
big old FPGA on there and having to write our own driver.

--
Regards, Joerg

http://www.analogconsultants.com/

 

On Sat, 01 Mar 2014 10:04:04 -0800, Joerg <invalid@invalid.invalid>
wrote:

upsidedown@downunder.com wrote:
On Fri, 28 Feb 2014 16:18:41 -0800, Joerg <invalid@invalid.invalid
wrote:

No. I wanted to know how to line up umpteen audio codecs in a way that
they talk to a PC and remain 100% synchronous. Using ADCs for otyher
markets is expensive.

You did not say anything about expected production volumes (just a one
off project or thousands of units) and hence is it feasible to design
your own PCI card.


Initially in the hundreds/year but must have a chance to become a
high-vlumen product without major architectural changes.

Those two requirements are mutually exclusive. There are many
tradeoffs to be made that will go one way vs. the other (NRE vs. per
unit costs).

If you have to design your own PCI card, what is wrong with the old
stereo audio ADCs such as the CS5394, apart from the board space
needed for 10+ stereo ADC chips ?


Nothing wrong with that. I was simply wondering if there'd be any
simpler and more contemporary method, for example via USB. This is how
SDR is done, with huge data streams.

But not with such an undefined specification. Data rate isn't the
problem, either. You're only talking about 100Mb/sec (15MB/sec), or
so.

It has differential inputs, a 2 Hz audio high pass (so no DC
measurement) and I˛S interface. It can operated both in master or
slave mode, put one in master mode and the rest in slave mode and tie
all the clock signals together.

Of course you will need a FPGA to convert these I˛S signals serial
signals to something usable for a computer, such as 32 bit parallel
words/sample to presented to the PCI bridge chip.

If some serial interface such as Ethernet, USB or PCIe is used, then
put the sample from every channel into the same frame (preferably 32
bits/sample to simplify CPU load), thus all samples from a particular
time would be guarantied to be available in the same frame.


Yes. I know pretty much how to do it, was just wondering if there is an
alternative to a brute force FPGA approach.

There may be but you won't like them any better. ;-)

Then you will have to think how you will get the data from the PC
interface card into memory, perhaps DMA or interrupt driven. However,
if every sample will generate an interrupt, there would be 40000
interrupts each second at 40 kHz sampling rate, which is quite a lot.
Transferring 40 samples for each interrupt would give 1000
interrupts/second, which is a reasonable value.

If the data is to be processed with some soft-RT system, such as
Windows or Linux, you may still need quite a lot of software FIFO
buffering between the ISR and user mode code.

So it is not just the ADC interface you need to consider but also
other parts of the system, in order to avoid making some local
optimizing that greatly harms the rest of the system.


Yeah, writing our own driver, that will be a major bear and this is at
least half the reason why I asked for an already existing
"off-the-shelf" method. And maybe with ADAT there is one. Although
somewhat limited as well, AFAIK even the high channel number Focusrite
Safire interface is restricted to 16 audio channels into the PC. But ...
this could be an avenue with less engineering effort than a card with a
big old FPGA on there and having to write our own driver.

The driver shouldn't be a big deal. If you use an existing bridge
(PCI or PCI-E, or such) the driver should be all but done. The FPGA
doesn't have to be that big. I2S/TDM is about as simple as it gets.
The gate count will be miniscule and you don't need many I/O, either.

 

[Joerg]

krw@attt.bizz wrote:

On Sat, 01 Mar 2014 10:04:04 -0800, Joerg <invalid@invalid.invalid
wrote:

upsidedown@downunder.com wrote:
On Fri, 28 Feb 2014 16:18:41 -0800, Joerg <invalid@invalid.invalid
wrote:

No. I wanted to know how to line up umpteen audio codecs in a way that
they talk to a PC and remain 100% synchronous. Using ADCs for otyher
markets is expensive.
You did not say anything about expected production volumes (just a one
off project or thousands of units) and hence is it feasible to design
your own PCI card.

Initially in the hundreds/year but must have a chance to become a
high-vlumen product without major architectural changes.

Those two requirements are mutually exclusive. There are many
tradeoffs to be made that will go one way vs. the other (NRE vs. per
unit costs).

Not necessarily. For example, the sampler I have designed is expensive
because of a >$10 diode. But the concept is such that all it'll take to
make this a cheap mass product is finding a lower cost diode with
sufficient instead of stellar performance. The architecture is geared
towards low cost. If I had gone the brute force route like in pricey
sampling scopes it wouldn't be.

If you have to design your own PCI card, what is wrong with the old
stereo audio ADCs such as the CS5394, apart from the board space
needed for 10+ stereo ADC chips ?

Nothing wrong with that. I was simply wondering if there'd be any
simpler and more contemporary method, for example via USB. This is how
SDR is done, with huge data streams.

But not with such an undefined specification. Data rate isn't the
problem, either. You're only talking about 100Mb/sec (15MB/sec), or
so.

For USB the spec is fixed. Often the SDR guys don't even come close to
the USB3.0 max data rate but they use this standard.

It has differential inputs, a 2 Hz audio high pass (so no DC
measurement) and I˛S interface. It can operated both in master or
slave mode, put one in master mode and the rest in slave mode and tie
all the clock signals together.

Of course you will need a FPGA to convert these I˛S signals serial
signals to something usable for a computer, such as 32 bit parallel
words/sample to presented to the PCI bridge chip.

If some serial interface such as Ethernet, USB or PCIe is used, then
put the sample from every channel into the same frame (preferably 32
bits/sample to simplify CPU load), thus all samples from a particular
time would be guarantied to be available in the same frame.

Yes. I know pretty much how to do it, was just wondering if there is an
alternative to a brute force FPGA approach.

There may be but you won't like them any better. ;-)

Yup. Afraid that is true :-(

Then you will have to think how you will get the data from the PC
interface card into memory, perhaps DMA or interrupt driven. However,
if every sample will generate an interrupt, there would be 40000
interrupts each second at 40 kHz sampling rate, which is quite a lot.
Transferring 40 samples for each interrupt would give 1000
interrupts/second, which is a reasonable value.

If the data is to be processed with some soft-RT system, such as
Windows or Linux, you may still need quite a lot of software FIFO
buffering between the ISR and user mode code.

So it is not just the ADC interface you need to consider but also
other parts of the system, in order to avoid making some local
optimizing that greatly harms the rest of the system.

Yeah, writing our own driver, that will be a major bear and this is at
least half the reason why I asked for an already existing
"off-the-shelf" method. And maybe with ADAT there is one. Although
somewhat limited as well, AFAIK even the high channel number Focusrite
Safire interface is restricted to 16 audio channels into the PC. But ...
this could be an avenue with less engineering effort than a card with a
big old FPGA on there and having to write our own driver.

The driver shouldn't be a big deal. If you use an existing bridge
(PCI or PCI-E, or such) the driver should be all but done. The FPGA
doesn't have to be that big. I2S/TDM is about as simple as it gets.
The gate count will be miniscule and you don't need many I/O, either.

I'll probably leave that part to another engineer

--
Regards, Joerg

http://www.analogconsultants.com/

 

[Joerg]

Lasse Langwadt Christensen wrote:

Den torsdag den 27. februar 2014 19.01.33 UTC+1 skrev Joerg:
Lasse Langwadt Christensen wrote:

Den torsdag den 27. februar 2014 02.38.03 UTC+1 skrev Joerg:
Lasse Langwadt Christensen wrote:
Den torsdag den 27. februar 2014 01.42.23 UTC+1 skrev Joerg:
bitrex wrote:
On 2/26/2014 2:42 PM, bitrex wrote:
On 2/25/2014 5:01 PM, Joerg wrote:
Folks, The AC97 standard describes only up to four
sound chips operated simultaneously, on page 21:
ftp://download.intel.com/support/motherboards/desktop/sb/ac97_r23.pdf
What if one would like to connect, say, 20 of them
and all are supposed to run nicely synchronous? Like
in a digital mixer board for music.
Here's a dirt cheap way to get a ton of analog audio
inputs: Buy one of these:
http://www.ebay.com/itm/M-Audio-Profire-Lightbridge-/201042188530?pt=US_Computer_Recording_Interfaces&hash=item2ecf0c58f2
4 ADAT lightpipe in/outs And then get 4 of these:
http://www.soundonsound.com/sos/jun04/articles/behringerada.htm
Then you have 32 analog inputs to Firewire, all synced
sample-accurate via ADAT clock. If you need more, buy
another Lightbridge and sync both setups via their Word
Cock connectors.
I neglected to ask if the requirement for 20+ channels of
synced audio to the computer was for a one-off
installation, or was a requirement for some kind of
product that you're developing. If it's the latter I'm
curious as to what the application is, because as shown
multitrack audio recording to the PC is a completely
solved problem with commodity-priced hardware already
available.
It's not a one-off but for a product. Can't talk about the
application but essentially it's the processing of
electrical signals that (luckily) happen to be spectrally
in the audio band. Phase synchronicity of all channels to
each other and dynamic range are the key parameters.
a good start would be to feed them all from the same
oscillator, that should take care of the hardest problem,
getting the sample rate exactly the same though there might a
pll for some sample rates..
Feding the same clock is easy but something must make sure that
the samples are all kept in time-sync. Even when they dump
their data in sccessive order.
I understand could you occasionally feed all the inputs from a
calibration source? sorta like a clapper board


Yes, that is possible but painful because it requires extra muxes.



might only require one if there is a way to just add it to the inputs
say if you have a virtual ground one all the input amps, mux that
between a reference signal and your virtual ground potential

Possible but I'd rather not mess with the input side if I can avoid it.

if you want to get fancy something like a prbs to get a nice
correlation peak must it be done real time?


Not really but close. If there is a delay of a few seconds that's
ok but

there will be signals coming in all the time, continuously.


ok, so you'll be processing it in real time, I'd think that an fpga
or MCU with USB giving you a nice stream of all you channels would be
less hassle than trying to get the whole windows/linux audio system
to play nice with multiple channels

something like a small FPGA for sync and de-serializing and an
FT2232H for USB. One channel for configuring the FPGA, other as
parallel FIFO

That is a good method but like all others requires a chunk of digital
design. Maybe we just have to do it if ADAT or something else won't pan out.

--
Regards, Joerg

http://www.analogconsultants.com/

 

On Sat, 01 Mar 2014 11:02:26 -0800, Joerg <invalid@invalid.invalid>
wrote:

krw@attt.bizz wrote:
On Sat, 01 Mar 2014 10:04:04 -0800, Joerg <invalid@invalid.invalid
wrote:

upsidedown@downunder.com wrote:
On Fri, 28 Feb 2014 16:18:41 -0800, Joerg <invalid@invalid.invalid
wrote:

No. I wanted to know how to line up umpteen audio codecs in a way that
they talk to a PC and remain 100% synchronous. Using ADCs for otyher
markets is expensive.
You did not say anything about expected production volumes (just a one
off project or thousands of units) and hence is it feasible to design
your own PCI card.

Initially in the hundreds/year but must have a chance to become a
high-vlumen product without major architectural changes.

Those two requirements are mutually exclusive. There are many
tradeoffs to be made that will go one way vs. the other (NRE vs. per
unit costs).


Not necessarily. For example, the sampler I have designed is expensive
because of a >$10 diode. But the concept is such that all it'll take to
make this a cheap mass product is finding a lower cost diode with
sufficient instead of stellar performance. The architecture is geared
towards low cost. If I had gone the brute force route like in pricey
sampling scopes it wouldn't be.

Oh, good grief. Stay on subject. You will either spend a fortune on
hardware or you will have to develop it, and the software, yourself.
The size of the market tells you which way to go.

If you have to design your own PCI card, what is wrong with the old
stereo audio ADCs such as the CS5394, apart from the board space
needed for 10+ stereo ADC chips ?

Nothing wrong with that. I was simply wondering if there'd be any
simpler and more contemporary method, for example via USB. This is how
SDR is done, with huge data streams.

But not with such an undefined specification. Data rate isn't the
problem, either. You're only talking about 100Mb/sec (15MB/sec), or
so.


For USB the spec is fixed. Often the SDR guys don't even come close to
the USB3.0 max data rate but they use this standard.

So what? Who gives a crap about USB? That isn't your problem. The
hardware for your proposed widget is next to trivial. The software
probably isn't. Do you think the SDR folks haven't invested a few
dimes in software?

It has differential inputs, a 2 Hz audio high pass (so no DC
measurement) and I˛S interface. It can operated both in master or
slave mode, put one in master mode and the rest in slave mode and tie
all the clock signals together.

Of course you will need a FPGA to convert these I˛S signals serial
signals to something usable for a computer, such as 32 bit parallel
words/sample to presented to the PCI bridge chip.

If some serial interface such as Ethernet, USB or PCIe is used, then
put the sample from every channel into the same frame (preferably 32
bits/sample to simplify CPU load), thus all samples from a particular
time would be guarantied to be available in the same frame.

Yes. I know pretty much how to do it, was just wondering if there is an
alternative to a brute force FPGA approach.

There may be but you won't like them any better. ;-)


Yup. Afraid that is true :-(

There are processors with enough I2S/TDM channels but they're not
cheap. I don't even know if they're available to small markets.

OTOH, DSPs are pretty readily available, IIRC. They may be a better
solution than an FPGA, even. If you're serious about this, you might
want to check out the ADI SHARC DSPs. I think you should be able to
do most of the work in Sigma Studios, without relying on "programming"
at all. I have no idea what the licensing deal is with SS is, though.
It just works. ;-)

The SHARC may not be exactly right (not sure how to get in and out
without MLB and that's a whole different kettle). Maybe a Blackfin?

Then you will have to think how you will get the data from the PC
interface card into memory, perhaps DMA or interrupt driven. However,
if every sample will generate an interrupt, there would be 40000
interrupts each second at 40 kHz sampling rate, which is quite a lot.
Transferring 40 samples for each interrupt would give 1000
interrupts/second, which is a reasonable value.

If the data is to be processed with some soft-RT system, such as
Windows or Linux, you may still need quite a lot of software FIFO
buffering between the ISR and user mode code.

So it is not just the ADC interface you need to consider but also
other parts of the system, in order to avoid making some local
optimizing that greatly harms the rest of the system.

Yeah, writing our own driver, that will be a major bear and this is at
least half the reason why I asked for an already existing
"off-the-shelf" method. And maybe with ADAT there is one. Although
somewhat limited as well, AFAIK even the high channel number Focusrite
Safire interface is restricted to 16 audio channels into the PC. But ...
this could be an avenue with less engineering effort than a card with a
big old FPGA on there and having to write our own driver.

The driver shouldn't be a big deal. If you use an existing bridge
(PCI or PCI-E, or such) the driver should be all but done. The FPGA
doesn't have to be that big. I2S/TDM is about as simple as it gets.
The gate count will be miniscule and you don't need many I/O, either.


I'll probably leave that part to another engineer

Then it's a trivial problem. ;-)

 

On Sat, 01 Mar 2014 10:04:04 -0800, Joerg <invalid@invalid.invalid>
wrote:

upsidedown@downunder.com wrote:
On Fri, 28 Feb 2014 16:18:41 -0800, Joerg <invalid@invalid.invalid
wrote:

No. I wanted to know how to line up umpteen audio codecs in a way that
they talk to a PC and remain 100% synchronous. Using ADCs for otyher
markets is expensive.

You did not say anything about expected production volumes (just a one
off project or thousands of units) and hence is it feasible to design
your own PCI card.


Initially in the hundreds/year but must have a chance to become a
high-vlumen product without major architectural changes.

Did you do your own market research ?

I have been frequently in the situation in which the marketing
department yearly expected sales are many times the whole market
(even assuming 100 % market share .

In some cases the expected sales of 10-100 units<each year turned out
to be 1-5 units in a decade :-(

Define your interfaces in such a way, that the expensive parts can be
easily replaced with some in-house product, if those sales claims
actually materialize.

For a low volume product, have you studied existing USB sound cards
(assuming that the non-DC bandwidth is acceptable) ?

If there is a limit of how many channels can be connected to a single
host, how you checked could several virtual machine could be run on
the same host, each accessing only 4 interfaces (8 channels).

Of course, this does not solve the synchronization issue, but if
everything is running on the same host, the x86 TSC (Time Stamp
Counter) should give a clue for synchronization.

 

[Lasse Langwadt Christense]

Den sřndag den 2. marts 2014 18.50.17 UTC+1 skrev Joerg:

upsidedown@downunder.com wrote:

On Sat, 01 Mar 2014 10:04:04 -0800, Joerg <invalid@invalid.invalid

wrote:



upsidedown@downunder.com wrote:

On Fri, 28 Feb 2014 16:18:41 -0800, Joerg <invalid@invalid.invalid

wrote:



No. I wanted to know how to line up umpteen audio codecs in a way that

they talk to a PC and remain 100% synchronous. Using ADCs for otyher

markets is expensive.

You did not say anything about expected production volumes (just a one

off project or thousands of units) and hence is it feasible to design

your own PCI card.



Initially in the hundreds/year but must have a chance to become a

high-vlumen product without major architectural changes.



Did you do your own market research ?





No, I always leave that to the clients.





I have been frequently in the situation in which the marketing

department yearly expected sales are many times the whole market

(even assuming 100 % market share .



In some cases the expected sales of 10-100 units<each year turned out

to be 1-5 units in a decade :-(





That would not be a consultant's problem because he or she isn't the

person calling those shots





Define your interfaces in such a way, that the expensive parts can be

easily replaced with some in-house product, if those sales claims

actually materialize.



For a low volume product, have you studied existing USB sound cards

(assuming that the non-DC bandwidth is acceptable) ?





Yes, I am using them for something similar. But you can't have dozens of

them running fully sync'd.





If there is a limit of how many channels can be connected to a single

host, how you checked could several virtual machine could be run on

the same host, each accessing only 4 interfaces (8 channels).





I really don't want to go that route. Gets expensive and opens up a can

of worms because now we'd be relying on some OS to keep synchronisty.

The only OS I'd trust in that respect is QNX.





Of course, this does not solve the synchronization issue, but if

everything is running on the same host, the x86 TSC (Time Stamp

Counter) should give a clue for synchronization.





We need sync to be accurate to within a single ADC clock cycle.

adc clock or sample rate clock?


-Lasse

 

On Sun, 02 Mar 2014 10:12:35 +0200, upsidedown@downunder.com wrote:

On Sat, 01 Mar 2014 10:04:04 -0800, Joerg <invalid@invalid.invalid
wrote:

upsidedown@downunder.com wrote:
On Fri, 28 Feb 2014 16:18:41 -0800, Joerg <invalid@invalid.invalid
wrote:

No. I wanted to know how to line up umpteen audio codecs in a way that
they talk to a PC and remain 100% synchronous. Using ADCs for otyher
markets is expensive.

You did not say anything about expected production volumes (just a one
off project or thousands of units) and hence is it feasible to design
your own PCI card.


Initially in the hundreds/year but must have a chance to become a
high-vlumen product without major architectural changes.

Did you do your own market research ?

I have been frequently in the situation in which the marketing
department yearly expected sales are many times the whole market
(even assuming 100 % market share .

Those are the markets to get into. It's called "new product
development".

In some cases the expected sales of 10-100 units<each year turned out
to be 1-5 units in a decade :-(

In others, it's hundreds of millions - per year.

Define your interfaces in such a way, that the expensive parts can be
easily replaced with some in-house product, if those sales claims
actually materialize.

For a low volume product, have you studied existing USB sound cards
(assuming that the non-DC bandwidth is acceptable) ?

That's where he was. Synchronization is the issue.

If there is a limit of how many channels can be connected to a single
host, how you checked could several virtual machine could be run on
the same host, each accessing only 4 interfaces (8 channels).

That complicates the issue *many* fold.

Of course, this does not solve the synchronization issue, but if
everything is running on the same host, the x86 TSC (Time Stamp
Counter) should give a clue for synchronization.

The synchronization "problem", isn't. This is *not* a large system.
Perhaps ten or twelve ADCs and half that many DACs. That's easily
do-able. The layout may be some work to keep the performance needed
but that's just engineering.

Everyone is making this problem (what we're told of it, anyway) far
more complicated than it needs to be.

 

[Lasse Langwadt Christense]

Den sřndag den 2. marts 2014 22.18.50 UTC+1 skrev Joerg:

Lasse Langwadt Christensen wrote:

Den sřndag den 2. marts 2014 18.50.17 UTC+1 skrev Joerg:

upsidedown@downunder.com wrote:





[...]





Of course, this does not solve the synchronization issue, but if

everything is running on the same host, the x86 TSC (Time Stamp

Counter) should give a clue for synchronization.





We need sync to be accurate to within a single ADC clock cycle.





adc clock or sample rate clock?





The sample clock, anything that would be able to skew the analog signal

when it morphs into digital.

Thought so, that also means any kind of simple "concentrator" won't work, there has to be a connection to "slave" all the ADCs off a main sample clock



-Lasse

 

[Joerg]

krw@attt.bizz wrote:

On Sat, 01 Mar 2014 11:02:26 -0800, Joerg <invalid@invalid.invalid
wrote:

krw@attt.bizz wrote:
On Sat, 01 Mar 2014 10:04:04 -0800, Joerg <invalid@invalid.invalid
wrote:

upsidedown@downunder.com wrote:
On Fri, 28 Feb 2014 16:18:41 -0800, Joerg <invalid@invalid.invalid
wrote:

No. I wanted to know how to line up umpteen audio codecs in a way that
they talk to a PC and remain 100% synchronous. Using ADCs for otyher
markets is expensive.
You did not say anything about expected production volumes (just a one
off project or thousands of units) and hence is it feasible to design
your own PCI card.

Initially in the hundreds/year but must have a chance to become a
high-vlumen product without major architectural changes.
Those two requirements are mutually exclusive. There are many
tradeoffs to be made that will go one way vs. the other (NRE vs. per
unit costs).

Not necessarily. For example, the sampler I have designed is expensive
because of a >$10 diode. But the concept is such that all it'll take to
make this a cheap mass product is finding a lower cost diode with
sufficient instead of stellar performance. The architecture is geared
towards low cost. If I had gone the brute force route like in pricey
sampling scopes it wouldn't be.

Oh, good grief. Stay on subject. You will either spend a fortune on
hardware or you will have to develop it, and the software, yourself.
The size of the market tells you which way to go.

I have a different philsophy. First I will look for what's already out
there, what it costs, whether it can possibly be licensed or maybe even
used as is. One should avoid re-inventing the wheel.

To that end Bitrex and Peter have given the excellent advice to check
out ADAT. Which is what I will do once this project gets into the R&D phase.

If you have to design your own PCI card, what is wrong with the old
stereo audio ADCs such as the CS5394, apart from the board space
needed for 10+ stereo ADC chips ?

Nothing wrong with that. I was simply wondering if there'd be any
simpler and more contemporary method, for example via USB. This is how
SDR is done, with huge data streams.
But not with such an undefined specification. Data rate isn't the
problem, either. You're only talking about 100Mb/sec (15MB/sec), or
so.

For USB the spec is fixed. Often the SDR guys don't even come close to
the USB3.0 max data rate but they use this standard.

So what? Who gives a crap about USB? ...

Almost everyone does these days. It's the "bus du jour".

... That isn't your problem. The
hardware for your proposed widget is next to trivial. ...

For someone familiar with FPGA it probably is but only when the
non-trivial issue of software is handled as well. A nicely programmed
FPGA will only be a brick otherwise.

... The software
probably isn't. Do you think the SDR folks haven't invested a few
dimes in software?

Sure they have but they also have used some existing stuff, probably
researched it out the same way I am trying to in this case.

It has differential inputs, a 2 Hz audio high pass (so no DC
measurement) and I˛S interface. It can operated both in master or
slave mode, put one in master mode and the rest in slave mode and tie
all the clock signals together.

Of course you will need a FPGA to convert these I˛S signals serial
signals to something usable for a computer, such as 32 bit parallel
words/sample to presented to the PCI bridge chip.

If some serial interface such as Ethernet, USB or PCIe is used, then
put the sample from every channel into the same frame (preferably 32
bits/sample to simplify CPU load), thus all samples from a particular
time would be guarantied to be available in the same frame.

Yes. I know pretty much how to do it, was just wondering if there is an
alternative to a brute force FPGA approach.
There may be but you won't like them any better. ;-)

Yup. Afraid that is true :-(

There are processors with enough I2S/TDM channels but they're not
cheap. I don't even know if they're available to small markets.

OTOH, DSPs are pretty readily available, IIRC. They may be a better
solution than an FPGA, even. If you're serious about this, you might
want to check out the ADI SHARC DSPs. I think you should be able to
do most of the work in Sigma Studios, without relying on "programming"
at all. I have no idea what the licensing deal is with SS is, though.
It just works. ;-)

The SHARC may not be exactly right (not sure how to get in and out
without MLB and that's a whole different kettle). Maybe a Blackfin?

That could be an option. Licensing should not be an issue. But first
I'll see if there alrady is an ADAT solution where people developed all
or most of this already.

[...]

--
Regards, Joerg

http://www.analogconsultants.com/

 

[Joerg]

upsidedown@downunder.com wrote:

On Sat, 01 Mar 2014 10:04:04 -0800, Joerg <invalid@invalid.invalid
wrote:

upsidedown@downunder.com wrote:
On Fri, 28 Feb 2014 16:18:41 -0800, Joerg <invalid@invalid.invalid
wrote:

No. I wanted to know how to line up umpteen audio codecs in a way that
they talk to a PC and remain 100% synchronous. Using ADCs for otyher
markets is expensive.
You did not say anything about expected production volumes (just a one
off project or thousands of units) and hence is it feasible to design
your own PCI card.

Initially in the hundreds/year but must have a chance to become a
high-vlumen product without major architectural changes.

Did you do your own market research ?

No, I always leave that to the clients.

I have been frequently in the situation in which the marketing
department yearly expected sales are many times the whole market
(even assuming 100 % market share .

In some cases the expected sales of 10-100 units<each year turned out
to be 1-5 units in a decade :-(

That would not be a consultant's problem because he or she isn't the
person calling those shots

Define your interfaces in such a way, that the expensive parts can be
easily replaced with some in-house product, if those sales claims
actually materialize.

For a low volume product, have you studied existing USB sound cards
(assuming that the non-DC bandwidth is acceptable) ?

Yes, I am using them for something similar. But you can't have dozens of
them running fully sync'd.

If there is a limit of how many channels can be connected to a single
host, how you checked could several virtual machine could be run on
the same host, each accessing only 4 interfaces (8 channels).

I really don't want to go that route. Gets expensive and opens up a can
of worms because now we'd be relying on some OS to keep synchronisty.
The only OS I'd trust in that respect is QNX.

Of course, this does not solve the synchronization issue, but if
everything is running on the same host, the x86 TSC (Time Stamp
Counter) should give a clue for synchronization.

We need sync to be accurate to within a single ADC clock cycle.

--
Regards, Joerg

http://www.analogconsultants.com/

 

On Sun, 02 Mar 2014 09:46:01 -0800, Joerg <invalid@invalid.invalid>
wrote:

krw@attt.bizz wrote:
On Sat, 01 Mar 2014 11:02:26 -0800, Joerg <invalid@invalid.invalid
wrote:

krw@attt.bizz wrote:
On Sat, 01 Mar 2014 10:04:04 -0800, Joerg <invalid@invalid.invalid
wrote:

upsidedown@downunder.com wrote:
On Fri, 28 Feb 2014 16:18:41 -0800, Joerg <invalid@invalid.invalid
wrote:

No. I wanted to know how to line up umpteen audio codecs in a way that
they talk to a PC and remain 100% synchronous. Using ADCs for otyher
markets is expensive.
You did not say anything about expected production volumes (just a one
off project or thousands of units) and hence is it feasible to design
your own PCI card.

Initially in the hundreds/year but must have a chance to become a
high-vlumen product without major architectural changes.
Those two requirements are mutually exclusive. There are many
tradeoffs to be made that will go one way vs. the other (NRE vs. per
unit costs).

Not necessarily. For example, the sampler I have designed is expensive
because of a >$10 diode. But the concept is such that all it'll take to
make this a cheap mass product is finding a lower cost diode with
sufficient instead of stellar performance. The architecture is geared
towards low cost. If I had gone the brute force route like in pricey
sampling scopes it wouldn't be.

Oh, good grief. Stay on subject. You will either spend a fortune on
hardware or you will have to develop it, and the software, yourself.
The size of the market tells you which way to go.


I have a different philsophy. First I will look for what's already out
there, what it costs, whether it can possibly be licensed or maybe even
used as is. One should avoid re-inventing the wheel.

If it's already out there, there is no value added to do it again.
Find a different idea, unless you're looking for a fight with an
entrenched competitor.

To that end Bitrex and Peter have given the excellent advice to check
out ADAT. Which is what I will do once this project gets into the R&D phase.


If you have to design your own PCI card, what is wrong with the old
stereo audio ADCs such as the CS5394, apart from the board space
needed for 10+ stereo ADC chips ?

Nothing wrong with that. I was simply wondering if there'd be any
simpler and more contemporary method, for example via USB. This is how
SDR is done, with huge data streams.
But not with such an undefined specification. Data rate isn't the
problem, either. You're only talking about 100Mb/sec (15MB/sec), or
so.

For USB the spec is fixed. Often the SDR guys don't even come close to
the USB3.0 max data rate but they use this standard.

So what? Who gives a crap about USB? ...


Almost everyone does these days. It's the "bus du jour".

So buy it! You're focusing on the trivial. Almost every uC now has
USB. Free.

... That isn't your problem. The
hardware for your proposed widget is next to trivial. ...


For someone familiar with FPGA it probably is but only when the
non-trivial issue of software is handled as well. A nicely programmed
FPGA will only be a brick otherwise.

The entire project borders on the trivial. The hard part will be to
keep from screwing up the performance that even cheap parts are
capable of doing. Well, there is the software part but you already
said that was someone else's problem. ;-)

... The software
probably isn't. Do you think the SDR folks haven't invested a few
dimes in software?


Sure they have but they also have used some existing stuff, probably
researched it out the same way I am trying to in this case.

Different universes. Your problem is trivial, by comparison.

It has differential inputs, a 2 Hz audio high pass (so no DC
measurement) and I˛S interface. It can operated both in master or
slave mode, put one in master mode and the rest in slave mode and tie
all the clock signals together.

Of course you will need a FPGA to convert these I˛S signals serial
signals to something usable for a computer, such as 32 bit parallel
words/sample to presented to the PCI bridge chip.

If some serial interface such as Ethernet, USB or PCIe is used, then
put the sample from every channel into the same frame (preferably 32
bits/sample to simplify CPU load), thus all samples from a particular
time would be guarantied to be available in the same frame.

Yes. I know pretty much how to do it, was just wondering if there is an
alternative to a brute force FPGA approach.
There may be but you won't like them any better. ;-)

Yup. Afraid that is true :-(

There are processors with enough I2S/TDM channels but they're not
cheap. I don't even know if they're available to small markets.

OTOH, DSPs are pretty readily available, IIRC. They may be a better
solution than an FPGA, even. If you're serious about this, you might
want to check out the ADI SHARC DSPs. I think you should be able to
do most of the work in Sigma Studios, without relying on "programming"
at all. I have no idea what the licensing deal is with SS is, though.
It just works. ;-)

The SHARC may not be exactly right (not sure how to get in and out
without MLB and that's a whole different kettle). Maybe a Blackfin?


That could be an option. Licensing should not be an issue. But first
I'll see if there alrady is an ADAT solution where people developed all
or most of this already.

[...]

 

[Lasse Langwadt Christense]

Den mandag den 3. marts 2014 00.17.27 UTC+1 skrev k...@attt.bizz:

On Sun, 2 Mar 2014 13:25:52 -0800 (PST), Lasse Langwadt Christensen

langwadt@fonz.dk> wrote:



Den sřndag den 2. marts 2014 22.18.50 UTC+1 skrev Joerg:

Lasse Langwadt Christensen wrote:



Den sřndag den 2. marts 2014 18.50.17 UTC+1 skrev Joerg:



upsidedown@downunder.com wrote:











[...]











Of course, this does not solve the synchronization issue, but if



everything is running on the same host, the x86 TSC (Time Stamp



Counter) should give a clue for synchronization.











We need sync to be accurate to within a single ADC clock cycle.











adc clock or sample rate clock?











The sample clock, anything that would be able to skew the analog signal



when it morphs into digital.





Thought so, that also means any kind of simple "concentrator" won't work, there has to be a connection to "slave" all the ADCs off a main sample clock



...or something like Ethernet AVB ("Audio/Video Bridging", basically

Ethernet, plus reserved bandwidth, plus time stamping, plus clock

extraction), or MOST.

that would quickly get complicated if you want to align ADCs better
than +/- 1/2 tsample

-Lasse

 

[Joerg]

krw@attt.bizz wrote:

On Sun, 02 Mar 2014 09:46:01 -0800, Joerg <invalid@invalid.invalid
wrote:

krw@attt.bizz wrote:
On Sat, 01 Mar 2014 11:02:26 -0800, Joerg <invalid@invalid.invalid
wrote:

krw@attt.bizz wrote:
On Sat, 01 Mar 2014 10:04:04 -0800, Joerg <invalid@invalid.invalid
wrote:

upsidedown@downunder.com wrote:
On Fri, 28 Feb 2014 16:18:41 -0800, Joerg <invalid@invalid.invalid
wrote:

No. I wanted to know how to line up umpteen audio codecs in a way that
they talk to a PC and remain 100% synchronous. Using ADCs for otyher
markets is expensive.
You did not say anything about expected production volumes (just a one
off project or thousands of units) and hence is it feasible to design
your own PCI card.

Initially in the hundreds/year but must have a chance to become a
high-vlumen product without major architectural changes.
Those two requirements are mutually exclusive. There are many
tradeoffs to be made that will go one way vs. the other (NRE vs. per
unit costs).

Not necessarily. For example, the sampler I have designed is expensive
because of a >$10 diode. But the concept is such that all it'll take to
make this a cheap mass product is finding a lower cost diode with
sufficient instead of stellar performance. The architecture is geared
towards low cost. If I had gone the brute force route like in pricey
sampling scopes it wouldn't be.
Oh, good grief. Stay on subject. You will either spend a fortune on
hardware or you will have to develop it, and the software, yourself.
The size of the market tells you which way to go.

I have a different philsophy. First I will look for what's already out
there, what it costs, whether it can possibly be licensed or maybe even
used as is. One should avoid re-inventing the wheel.

If it's already out there, there is no value added to do it again.
Find a different idea, unless you're looking for a fight with an
entrenched competitor.

For this app there are no competitors. Which usually makes license deals
easy because it means windfall bucks for the inventing company without
anyone stepping on their turf.

To that end Bitrex and Peter have given the excellent advice to check
out ADAT. Which is what I will do once this project gets into the R&D phase.


If you have to design your own PCI card, what is wrong with the old
stereo audio ADCs such as the CS5394, apart from the board space
needed for 10+ stereo ADC chips ?

Nothing wrong with that. I was simply wondering if there'd be any
simpler and more contemporary method, for example via USB. This is how
SDR is done, with huge data streams.
But not with such an undefined specification. Data rate isn't the
problem, either. You're only talking about 100Mb/sec (15MB/sec), or
so.

For USB the spec is fixed. Often the SDR guys don't even come close to
the USB3.0 max data rate but they use this standard.
So what? Who gives a crap about USB? ...

Almost everyone does these days. It's the "bus du jour".

So buy it! You're focusing on the trivial. Almost every uC now has
USB. Free.

I was hoping someone knew about a simple off-the-shelf concentrator that
could do this job but I guess other than ADAT there isn't.

... That isn't your problem. The
hardware for your proposed widget is next to trivial. ...

For someone familiar with FPGA it probably is but only when the
non-trivial issue of software is handled as well. A nicely programmed
FPGA will only be a brick otherwise.

The entire project borders on the trivial. The hard part will be to
keep from screwing up the performance that even cheap parts are
capable of doing. Well, there is the software part but you already
said that was someone else's problem. ;-)

To some extent it would also be mine because I often have to guide that.

... The software
probably isn't. Do you think the SDR folks haven't invested a few
dimes in software?

Sure they have but they also have used some existing stuff, probably
researched it out the same way I am trying to in this case.

Different universes. Your problem is trivial, by comparison.

We'll see

[...]

--
Regards, Joerg

http://www.analogconsultants.com/

 

[Joerg]

Lasse Langwadt Christensen wrote:

Den sřndag den 2. marts 2014 18.50.17 UTC+1 skrev Joerg:
upsidedown@downunder.com wrote:

[...]

Of course, this does not solve the synchronization issue, but if
everything is running on the same host, the x86 TSC (Time Stamp
Counter) should give a clue for synchronization.


We need sync to be accurate to within a single ADC clock cycle.


adc clock or sample rate clock?

The sample clock, anything that would be able to skew the analog signal
when it morphs into digital.

--
Regards, Joerg

http://www.analogconsultants.com/

 

On Sun, 02 Mar 2014 13:16:40 -0800, Joerg <invalid@invalid.invalid>
wrote:

krw@attt.bizz wrote:
On Sun, 02 Mar 2014 09:46:01 -0800, Joerg <invalid@invalid.invalid
wrote:

krw@attt.bizz wrote:
On Sat, 01 Mar 2014 11:02:26 -0800, Joerg <invalid@invalid.invalid
wrote:

krw@attt.bizz wrote:
On Sat, 01 Mar 2014 10:04:04 -0800, Joerg <invalid@invalid.invalid
wrote:

upsidedown@downunder.com wrote:
On Fri, 28 Feb 2014 16:18:41 -0800, Joerg <invalid@invalid.invalid
wrote:

No. I wanted to know how to line up umpteen audio codecs in a way that
they talk to a PC and remain 100% synchronous. Using ADCs for otyher
markets is expensive.
You did not say anything about expected production volumes (just a one
off project or thousands of units) and hence is it feasible to design
your own PCI card.

Initially in the hundreds/year but must have a chance to become a
high-vlumen product without major architectural changes.
Those two requirements are mutually exclusive. There are many
tradeoffs to be made that will go one way vs. the other (NRE vs. per
unit costs).

Not necessarily. For example, the sampler I have designed is expensive
because of a >$10 diode. But the concept is such that all it'll take to
make this a cheap mass product is finding a lower cost diode with
sufficient instead of stellar performance. The architecture is geared
towards low cost. If I had gone the brute force route like in pricey
sampling scopes it wouldn't be.
Oh, good grief. Stay on subject. You will either spend a fortune on
hardware or you will have to develop it, and the software, yourself.
The size of the market tells you which way to go.

I have a different philsophy. First I will look for what's already out
there, what it costs, whether it can possibly be licensed or maybe even
used as is. One should avoid re-inventing the wheel.

If it's already out there, there is no value added to do it again.
Find a different idea, unless you're looking for a fight with an
entrenched competitor.


For this app there are no competitors. Which usually makes license deals
easy because it means windfall bucks for the inventing company without
anyone stepping on their turf.

But if there is already something on the market that will do what you
want it to do, where is your value add? Why wouldn't a potential
customer just buy it?

To that end Bitrex and Peter have given the excellent advice to check
out ADAT. Which is what I will do once this project gets into the R&D phase.


If you have to design your own PCI card, what is wrong with the old
stereo audio ADCs such as the CS5394, apart from the board space
needed for 10+ stereo ADC chips ?

Nothing wrong with that. I was simply wondering if there'd be any
simpler and more contemporary method, for example via USB. This is how
SDR is done, with huge data streams.
But not with such an undefined specification. Data rate isn't the
problem, either. You're only talking about 100Mb/sec (15MB/sec), or
so.

For USB the spec is fixed. Often the SDR guys don't even come close to
the USB3.0 max data rate but they use this standard.
So what? Who gives a crap about USB? ...

Almost everyone does these days. It's the "bus du jour".

So buy it! You're focusing on the trivial. Almost every uC now has
USB. Free.


I was hoping someone knew about a simple off-the-shelf concentrator that
could do this job but I guess other than ADAT there isn't.

I don't see anything that makes this a real problem. Just do it. The
only issues, as I see it (with very little information about the real
application), the problem, as has been pointed out, is to make sure
you don't paint yourself in a throughput corner, a little smart analog
design, and the app that sits on top of the whole thing.

I've done 20ADCs and 16DACs (with power amps). I could have done a
better job on the analog design but the MEs had already painted me in
a corner before I started. I'll have time to do another pass later
this year (with some newer parts and more control of the project).

... That isn't your problem. The
hardware for your proposed widget is next to trivial. ...

For someone familiar with FPGA it probably is but only when the
non-trivial issue of software is handled as well. A nicely programmed
FPGA will only be a brick otherwise.

The entire project borders on the trivial. The hard part will be to
keep from screwing up the performance that even cheap parts are
capable of doing. Well, there is the software part but you already
said that was someone else's problem. ;-)


To some extent it would also be mine because I often have to guide that.

Write a good spec!

... The software
probably isn't. Do you think the SDR folks haven't invested a few
dimes in software?

Sure they have but they also have used some existing stuff, probably
researched it out the same way I am trying to in this case.

Different universes. Your problem is trivial, by comparison.


We'll see

Been there. There is nothing to the digital part of this. No FPGA,
even. ;-)

 

On Sun, 2 Mar 2014 13:25:52 -0800 (PST), Lasse Langwadt Christensen
<langwadt@fonz.dk> wrote:

Den sřndag den 2. marts 2014 22.18.50 UTC+1 skrev Joerg:
Lasse Langwadt Christensen wrote:

Den sřndag den 2. marts 2014 18.50.17 UTC+1 skrev Joerg:

upsidedown@downunder.com wrote:





[...]





Of course, this does not solve the synchronization issue, but if

everything is running on the same host, the x86 TSC (Time Stamp

Counter) should give a clue for synchronization.





We need sync to be accurate to within a single ADC clock cycle.





adc clock or sample rate clock?





The sample clock, anything that would be able to skew the analog signal

when it morphs into digital.


Thought so, that also means any kind of simple "concentrator" won't work, there has to be a connection to "slave" all the ADCs off a main sample clock

....or something like Ethernet AVB ("Audio/Video Bridging", basically
Ethernet, plus reserved bandwidth, plus time stamping, plus clock
extraction), or MOST.

 

On Sun, 2 Mar 2014 15:24:01 -0800 (PST), Lasse Langwadt Christensen
<langwadt@fonz.dk> wrote:

Den mandag den 3. marts 2014 00.17.27 UTC+1 skrev k...@attt.bizz:
On Sun, 2 Mar 2014 13:25:52 -0800 (PST), Lasse Langwadt Christensen

langwadt@fonz.dk> wrote:



Den sřndag den 2. marts 2014 22.18.50 UTC+1 skrev Joerg:

Lasse Langwadt Christensen wrote:



Den sřndag den 2. marts 2014 18.50.17 UTC+1 skrev Joerg:



upsidedown@downunder.com wrote:











[...]











Of course, this does not solve the synchronization issue, but if



everything is running on the same host, the x86 TSC (Time Stamp



Counter) should give a clue for synchronization.











We need sync to be accurate to within a single ADC clock cycle.











adc clock or sample rate clock?











The sample clock, anything that would be able to skew the analog signal



when it morphs into digital.





Thought so, that also means any kind of simple "concentrator" won't work, there has to be a connection to "slave" all the ADCs off a main sample clock



...or something like Ethernet AVB ("Audio/Video Bridging", basically

Ethernet, plus reserved bandwidth, plus time stamping, plus clock

extraction), or MOST.

that would quickly get complicated if you want to align ADCs better
than +/- 1/2 tsample

No, that's the whole purpose of these interfaces. You're right,
though, this stuff doesn't come free but Ethernet AVB is, or will soon
be, built into some uCs.

 

[Joerg]

krw@attt.bizz wrote:

On Sun, 02 Mar 2014 13:16:40 -0800, Joerg <invalid@invalid.invalid
wrote:

krw@attt.bizz wrote:
On Sun, 02 Mar 2014 09:46:01 -0800, Joerg <invalid@invalid.invalid
wrote:

krw@attt.bizz wrote:
On Sat, 01 Mar 2014 11:02:26 -0800, Joerg <invalid@invalid.invalid
wrote:

krw@attt.bizz wrote:
On Sat, 01 Mar 2014 10:04:04 -0800, Joerg <invalid@invalid.invalid
wrote:

upsidedown@downunder.com wrote:
On Fri, 28 Feb 2014 16:18:41 -0800, Joerg <invalid@invalid.invalid
wrote:

No. I wanted to know how to line up umpteen audio codecs in a way that
they talk to a PC and remain 100% synchronous. Using ADCs for otyher
markets is expensive.
You did not say anything about expected production volumes (just a one
off project or thousands of units) and hence is it feasible to design
your own PCI card.

Initially in the hundreds/year but must have a chance to become a
high-vlumen product without major architectural changes.
Those two requirements are mutually exclusive. There are many
tradeoffs to be made that will go one way vs. the other (NRE vs. per
unit costs).

Not necessarily. For example, the sampler I have designed is expensive
because of a >$10 diode. But the concept is such that all it'll take to
make this a cheap mass product is finding a lower cost diode with
sufficient instead of stellar performance. The architecture is geared
towards low cost. If I had gone the brute force route like in pricey
sampling scopes it wouldn't be.
Oh, good grief. Stay on subject. You will either spend a fortune on
hardware or you will have to develop it, and the software, yourself.
The size of the market tells you which way to go.

I have a different philsophy. First I will look for what's already out
there, what it costs, whether it can possibly be licensed or maybe even
used as is. One should avoid re-inventing the wheel.
If it's already out there, there is no value added to do it again.
Find a different idea, unless you're looking for a fight with an
entrenched competitor.

For this app there are no competitors. Which usually makes license deals
easy because it means windfall bucks for the inventing company without
anyone stepping on their turf.

But if there is already something on the market that will do what you
want it to do, where is your value add? ...

The audio pipe is a tiny little facet of the whole measurement
apparatus. The value addition is in the rest of the machine, the audio
converters are just there to provide umpteen economical high dynamic
range paths into the PC.

... Why wouldn't a potential customer just buy it?

Because they can't get it anywhere else.

To that end Bitrex and Peter have given the excellent advice to check
out ADAT. Which is what I will do once this project gets into the R&D phase.


If you have to design your own PCI card, what is wrong with the old
stereo audio ADCs such as the CS5394, apart from the board space
needed for 10+ stereo ADC chips ?

Nothing wrong with that. I was simply wondering if there'd be any
simpler and more contemporary method, for example via USB. This is how
SDR is done, with huge data streams.
But not with such an undefined specification. Data rate isn't the
problem, either. You're only talking about 100Mb/sec (15MB/sec), or
so.

For USB the spec is fixed. Often the SDR guys don't even come close to
the USB3.0 max data rate but they use this standard.
So what? Who gives a crap about USB? ...
Almost everyone does these days. It's the "bus du jour".
So buy it! You're focusing on the trivial. Almost every uC now has
USB. Free.

I was hoping someone knew about a simple off-the-shelf concentrator that
could do this job but I guess other than ADAT there isn't.

I don't see anything that makes this a real problem. Just do it. The
only issues, as I see it (with very little information about the real
application), the problem, as has been pointed out, is to make sure
you don't paint yourself in a throughput corner, a little smart analog
design, and the app that sits on top of the whole thing.

I've done 20ADCs and 16DACs (with power amps). I could have done a
better job on the analog design but the MEs had already painted me in
a corner before I started. I'll have time to do another pass later
this year (with some newer parts and more control of the project).

If ADAT doesn't pan out for some reason we'll roll our own.

... That isn't your problem. The
hardware for your proposed widget is next to trivial. ...
For someone familiar with FPGA it probably is but only when the
non-trivial issue of software is handled as well. A nicely programmed
FPGA will only be a brick otherwise.
The entire project borders on the trivial. The hard part will be to
keep from screwing up the performance that even cheap parts are
capable of doing. Well, there is the software part but you already
said that was someone else's problem. ;-)

To some extent it would also be mine because I often have to guide that.

Write a good spec!

That's the very first item when I start a design, the module spec.
Before even as much as a bypass cap gets placed in the CAD.

... The software
probably isn't. Do you think the SDR folks haven't invested a few
dimes in software?

Sure they have but they also have used some existing stuff, probably
researched it out the same way I am trying to in this case.
Different universes. Your problem is trivial, by comparison.

We'll see

Been there. There is nothing to the digital part of this. No FPGA,
even. ;-)

No FPGA would be nice. Then even I could do it

--
Regards, Joerg

http://www.analogconsultants.com/

 

[Jeorg's friend]

Jeorg,

Wavefront Semiconductor makes the ADAT chips.

Look at AES3 / SPDIF

Don't ask me why I know, but your not the first to have this problem.

Steve R.