DIY PC audio interface

[Rochey]

okay...

things are moving in the right direction. I'd like to suggest some next steps for this.

a) Define an interface (e.g. -- TDM data to and from the breakout box)
b) Get a software team together (not just 2 individuals!) is Sourceforge the best place for this?
c) Get an FPGA team together for the hardware side of the breakout box.

I believe work is already happening on a separate project for the ADC side of things, as well as the DAC.

Also, is there a better place to leave plans etc. than in this thread?

Cheers

R

 

[to-pse]

[quote author="Rochey"]okay...

things are moving in the right direction. I'd like to suggest some next steps for this.

a) Define an interface (e.g. -- TDM data to and from the breakout box)
b) Get a software team together (not just 2 individuals!) is Sourceforge the best place for this?
c) Get an FPGA team together for the hardware side of the breakout box.

R[/quote]

Looking back to your earlier question I'd say that we definately need
a processor, as we would need to "detect" what kind of break-out-
boxes there are (possibly many connected to one switch), how many
channels/rates/bit-depth they support and then we would need to "alloc"
resources - this would make it possible to use partial resources of one
breakout-box from multiple pcs (One problem there is how to generate
a unique clock to not run into problems because of skew)

Tobias

PS.: sometimes 2 people get more stuff done than a big team,
as the administrative overhead is decreased dramatically ;-)

 

[Rochey]

[quote author="to-pse"]
Looking back to your earlier question I'd say that we definately need
a processor, as we would need to "detect" what kind of break-out-
boxes there are (possibly many connected to one switch), how many
channels/rates/bit-depth they support and then we would need to "alloc"
resources - this would make it possible to use partial resources of one
breakout-box from multiple pcs (One problem there is how to generate
a unique clock to not run into problems because of skew)

Tobias

PS.: sometimes 2 people get more stuff done than a big team,
as the administrative overhead is decreased dramatically ;-)[/quote]


Okay, there's 2 options I see at this point.
a) We make this a Point to point connection (breakoutbox to pc) with the ability to daisychain breakoutboxes together. (then maybe TDM everything straight into the computer)
b) We give everything MAC addresses and be able to use 1 breakout box between lots of pc's etc.


If we go with option (a) then we can simply have a clock circuit distributed between each of the breakout boxes in the same way as we would now and then bring in the actual pcm data into the master breakout box.

That way, you may only need 1 main 'network processor' in the master breakout box (or outside of it) and then stream the data from each breakout box into it.

And voila - we've just entered a whole new world of complexity. :sad:
Ideas please - i'm feeling depressed.

 

[tmbg]

Ok, this is definitely coming together.

Rochey, before you get depressed due to feature creep, lets just work on making SOMETHING happen. to-pse, this first part is gonna fall mostly on you!

Let's define a protocol that we'll send over layer2 ethernet, and drivers which would take that data and turn it into an ASIO or WDM interface. I personally prefer ASIO, but if we can get the same performance out of WDM, so be it. Is it possible that, down the road, we can have both a WDM and a pure ASIO driver?

sample rate syncing will be interesting. Here's a proposal. MTU for ethernet frames is 1500bytes. 1500/24 is 62.5. How about we say one ethernet frame transfers 48 or 56 channels worth of data, and then we just try to get Fs frames per second over the network. How we sync that may be really tricky.

Hm, 40 channels each way at 96khz will about top out a 100mbit fdx link.

It would definitely be nice to make the protocol flexible enough that we can have anything from 2 channels of 16/44.1, to 512 channels of 16/44.1, or 128 of 24/192, or whatever.[/i]

 

[tmbg]

BTW, dont worry about the breakout hardware too much just yet. I have a friend who's a design engineer at Honeywell, designing some high end ethernet switches, and he's got experience interfacing PHYs with MCUs and FPGAs, and I'll try to rope him into this, but for now we just need to worry about the ethernet audio. That's the sticky point.

 

[Rochey]

I like nice pictures 'n stuff.
Here's what I've got in mind. - it essentially makes things as flexible as possible. That FPGA in the middle is a god-send! :grin:
If that is... we can find someone that can speak VHDL

http://www.tendolla.com/diyinterface/idea#2.pdf

Is that the kind of idea that everyone else has in mind?

 

[tmbg]

I speak VHDL!

Yeah that looks reasonable. Yes, we can make a simple CPU in the FPGA, although I think it'll be simple enough to not warrant being called a CPU... just a few state machines to do what's necessary.

Clock generation can be handled by the fpga - it has PLLs which will let you create pretty much any clock you want. We can apply a buffer and call it a master clock for other boxes.

 

[to-pse]

[quote author="tmbg"]Ok, this is definitely coming together.

Rochey, before you get depressed due to feature creep, lets just work on making SOMETHING happen. to-pse, this first part is gonna fall mostly on you!

Let's define a protocol that we'll send over layer2 ethernet...[/quote]

I give the protocol-definition a try over the weekend. A test-
implementation of device-detection / feature-detection and
allocation would probably easiest under linux, as one would not
need to write driver-code there...

For now I have to get back to do some work here ;-)

Tobias

PS.: It would be nice if we could adjust the sample-rate of the channels
individually. (Like chan 1-4 used by PC1 at 24/96 and chan 2-4 used by
PC2 at 24/44.1) - I guess that would mean that we need to reference-
clocks: one of 192khz and on at 176.4khz from which we would derive
all the others...

 

[tmbg]

Lemme know when you're ready to write test implementations of the protocols, I've got Linux programming experience, I'd like to be a part of that.

As for multiple clocks, I am pretty sure most DAW software doesnt like to deal with more than one sample rate at a time, plus it'll up the administrative overhead of the protocol significantly.

 

[Consul]

Wow... Just, wow. :shock:

I wish I could contribute to this project in some meaningful way. I guess you could just let me know when you need the web site done. :wink:

 

[to-pse]

[quote author="tmbg"]Lemme know when you're ready to write test implementations of the protocols, I've got Linux programming experience, I'd like to be a part of that.

As for multiple clocks, I am pretty sure most DAW software doesnt like to deal with more than one sample rate at a time, plus it'll up the administrative overhead of the protocol significantly.[/quote]

I will tell you when it's time "to code" ;-)

Concerning the multiple clocks: I did not mean to use them from
one DAW software, but rather use one external audio-box with 8
a/d-converters from two pcs. Like using the first four with one,
and the other four with another pc (possibly both running different
sample-rates)... that would be really neat for people using Cubase
on one PC and Gigastudio on another one...

Tobias

 

[tmbg]

I don't know if that's worth the overhead. Since this is meant to be a relatively inexpensive thing to make, it would be more reasonable to just use two breakouts, on independent segments.

 

[daArry]

damn, come a long way in a day eh :thumb:

:guinness: :green: :sam:

 

[Rochey]

[quote author="tmbg"]I don't know if that's worth the overhead. Since this is meant to be a relatively inexpensive thing to make, it would be more reasonable to just use two breakouts, on independent segments.[/quote]

what i like about this project, is that it can be dirt cheap to make (i.e use cheap adc#s and dac's in the b.box, or it can be using flagship parts. Beautiful

 

[to-pse]

Hi everyone,

I just found another standard, called "CobraNet" which even has
a VLSI-chip doing the hardware-interface:

http://www.peakaudio.com/CobraNet/CS18101/index.htm

Unfortunately this Cobranet-Standard only allows for 48khz
samplerate and is fixed to 256 Samples latency...

Tobias

 

[pilo]

.. just a few state machines to do what's necessary.

can't we use both a fpga and an external cpu, like a pic or another µP like that, and as you said a finite state machines in the fpga?

Clock generation can be handled by the fpga - it has PLLs which will let you create pretty much any clock you want. We can apply a buffer and call it a master clock for other boxes

I already use a pll1700 in my converter, for a "clean" 12.288Mhz (or other) clock. As far as I remember mcs made a board with pll1708? (actually I had pll1700 when I saw your schematic, and I copy yours but I replace the pll1708 by pll1700 )

 

[mcs]

[quote author="pilo"]As far as I remember mcs made a board with pll1708?[/quote]
Yes. And it can be used with the PLL1707 also, if you want a hardware controlled clock.

Best regards,

Mikkel C. Simonsen

 

[Rochey]

*cough cough*

cobranet blows....

but then, that's just my opinion - and noone elses :grin:

as for the PLL -- sounds good

 

[Consul]

Just out of curiosity, I thought I'd bump this and see if anyone has anything new to say. I'm quite interested in this project myself, and would like to help if I can. I'm afraid I'm no digital circuit designer, though.

 

[Rochey]

Last I understood, some of the guys were investigating using low level Linux drivers to use a standard ethernet port. This was also possible in Windows apparently. (it's somewhere in the thread).

In the mean time, I think some fellows here are working on a hardware interface. I think we need to find out if the additional drivers on standard Ethernet ports will work.

Let's wait for some feedback from the others.