More than one audio codec on a PC mobo

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

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

-Lasse

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.

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.

Yup. Afraid that is true :-(

I'll probably leave that part to another engineer :-)

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

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.

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.

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?

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 it's a trivial problem. ;-)

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

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

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

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

That complicates the issue *many* fold.

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.

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.

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

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.

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.

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.

No, I always leave that to the clients.

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

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

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.

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

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.

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

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. ;-)

Different universes. Your problem is trivial, by comparison.

at

adc clock or sample rate clock?

-Lasse

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.

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.

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

We'll see :-)

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, t here has to be a connection to "slave" all the ADCs off a main sample clock

-Lasse

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?

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).

Write a good spec!

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

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

Den mandag den 3. marts 2014 00.17.27 UTC+1 skrev snipped-for-privacy@attt.bizz:

, there has to be a connection to "slave" all the ADCs off a main sample cl ock

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

-Lasse

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.

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.

Because they can't get it anywhere else.

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

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.

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

What you want to look into is not AC'97 but the more modern Intel High Definition Audio (HDA)specification. It supports 500 bit slots for input (~15 32 bit channels) multi codec streams and synchronization.

HDA codecs are very cheap. Realtek ALC889 go for ~0.6$ in single digit quantities.

The interface would be predominantly a FIFO with a few ornaments.

Regards Werner Dahn