DIY PC audio interface

[Rochey]

agreed.

I think ADAT is a good medium for transporting audio in the 44.1KHz range at 24bits. Many I've spoken to have said that they are comfortable with that.

My concern is that, as we move into the portable laptop game, ADAT becomes less of an option.

But, one step at a time - the ADAT route is probably the best way to start!

Cheers

Rochey

 

[daArry]

we can get higher sample rates with adat by utilising s/mux -again might require some dsp action tho :roll:

EDIT: i'm content with 24/44.1 at the end of the day tho

 

[gyraf]

[quote author="daArry"]we can get higher sample rates with adat by utilising s/mux -again might require some dsp action tho[/quote]

Then we couldn't use the chipsets, the computer interface, or the software drivers. So we could as well define and build our own standard in that case..

None of these things are easy. No free lunch..

Jakob E.

 

[Rochey]

lets get this adat board out of the way first then - proove that it works and go from there.

If we can mod the B box to be as modular as possible, there is nothing stopping us from adding another interface to the box instead of the ADAT out.

what do you think?

 

[ToshiroTamigi]

Hello everybody.
This is my first post here

I must remember that to make functional the hardware part of the project you need to implement software drivers, that is not an easy task theese days...

So
why don't concentrate our efforts to maybe modding an existing hardware platform like, for example EMU Based soundcards for wich exist a poweful open source driver (http://www.kxproject.com/index.php)?

there are a lot of soundcard using emu chips around, beginning from live, audigy from creative and APS sound cards.

Some improvements can be replace the ADC/DAC sets with new ones, replace the analog sections and so on.

what do you think about?
Alessio

 

[Rochey]

*verycool*

although from what i can see, most of those cards only support 2 channels

I'd like to see us able to do a project with 8 channels per unit. So far, the ADAT project looks most suitable

 

[tmbg]

ADAT would be a plus, since I have a Hammerfall

I still want to do a TDIF-ADAT converter, so I can use my DM-24 more completely I can't find any commercial ones for sale anymore.


BUT, I would LOVE to start working with MADI, either by buying an existing MADI interface card (I know RME makes some MADI stuff), or by building a MADI PCI card.

Anyone can point me at MADI whitepapers, so I can get an idea of how the thing works?

 

[TomWaterman]

Hi,

MADI is an awesome technology for large channel counts / sample rates etc but hardly anyone supports it. AFAIK SSL and Euphonix are the only big guns using it....Sony dropped it, RME are the only interface manufacturer and people like Yamaha are not interested because of mLAN. I doubt Digidesign will ever embrace it as well.

I reckon AES would be the best choice - its reliable at high-rates and a common format with better error checking than most.

ADAT is a lost cause IMO and would not make sense for the future - it frustrates me, losing channels at higher rates.

On the otherhand IP LAN for audio is cool - but I think you would need to use UDP(?) for that, like someone already stated it needs to be real-time, i.e if something drop-outs it cannot be resent later as it would in normal IP LAN systems.

BSS Soundweb is another that uses ethernet connections for transfer but AFAIK they use their own protocol and do not put the audio data in standard IP packets.

Good luck Rochey!!! This is an ambitious project thats for sure.

Cheers Tom

 

[tmbg]

audio over ethernet is a neat idea, but audio over IP won't work so well.

Reason being that it's not guaranteed enough.

What we'd want to do is use ethernet sorta like MADI. Write our own drivers, and just use it as a physical data interface.

I just read that 64 channel MADI is 98mbit/sec, guess what! So is ethernet

http://www.nt-instruments.com/X0-ASP-pLngCateId_219-pIntLevel_4-pLngPageId_661-X1-default.htm
has some interesting stuff on MADI. Too bad the RME MADI card is $1400

 

[Kev]

[quote author="Rochey"] What: PC/Mac Audio interface ...
Why: Because having digital outputs for many of the pre's etc designed here to put straight into a PC would make a fantastic addition to their functionality [/quote]

Ok the what I get
even though it may require writing drivers and bug fixing on some applications ...
A certain application my never work however nothing is impossible and I have seen things in the past that did have me second guessing everything in the computer world.

Why ...
digital transfer one to one ... one at a time is very do-able.
I get scared when I see MULTIPLE
even the pro gear gets this wrong and good distribution of clock may end up being more expensive than all your analog gear put together.

At this stage the only digital interface I am using is the ADAT Lightpipe and this is only the AI3 and that B box. The AI3 slaves well and so works on the 001 and TCM interfaces OK.
No 96K here so I think it's life is limited.

On the subject of clock and digital signal distribution in general ... we in broadcast TV have trouble with equipment and dropouts. I don't understand the details but we have been OFF the air a number of time due to strange digital issues even on gear that has been faultless for months ??

The whole computer re-boot / re-set sort of thing.
" So what was wrong ? "
" ... don't know, I reset the card. "

Even when it is working - can we be sure it is working properly ?
I still do analog transfers.

I have also decided to postpone, where possible, all D/A and A/D purchases except bargains and purely for the experiment.

We are continuing to see so many changes in this area you will have to be quick with your developments.

 

[pilo]

why don't concentrate our efforts to maybe modding an existing hardware platform like, for example EMU Based soundcards for wich exist a poweful open source driver (http://www.kxproject.com/index.php)?

this was where I start with ADC I add, with succes, TI adc on a simple SB live sound card already, and it works fine with KX drivers.

I though that firewire was a better idea than ethernet... maybe I'm wrong. I already wrote some UDP and TCP/IP programs,and there's already an existing jack driver (under linux) for sending and receiving sound over ethernet. Don't know how much latency there is, but I think we need to write a specific driver t achieve good latency. That's why I think writing drivers for firewire is, maybe, easier than PCI cards...
Making a pci is not a good idea, I think , because PCI is going to disapear, and making only a few piece of the card will cost a lot of money.

I think the easiest solution is to use firewire... I don't know which chip we can use, if there are already easy to use interface chip, or if a FPGA can help... and the fpga can also encode and decode ADAT as well I think

 

[Rochey]

like i said - there are two players catering for this market

Bridgeco and Wavefront Semi.


TI does have a 1394 solution - but it's aimed at very specific customers.

I've already pinged one of the guys at Wavefront/TC Electronics to find out more.

Again - the prob is that this is a BGA package. Whilst my layout skills are pretty good with eagle, I'm a little scared of dealing with BGA packages!

 

[mcs]

[quote author="pilo"]I though that firewire was a better idea than ethernet... maybe I'm wrong.[/quote]
Remember Ethernet != TCP/IP. You can transmit packets over Ethernet without using any standard network protocol. That would solve both the latency issues (I think) and the PCI issue. If you application talks Ethernet it doesn't matter if the Ethernet chip is on a PCI bus or some other future bus standard. It shouldn't matter what Ethernet chip is used either (as long as it's not an RTL8139 :wink.

Best regards,

Mikkel C. Simonsen

 

[tmbg]

mcs, that's sorta what I was getting at. Use an ethernet segment, that's NOT connected to a regular network, NOT routed or switched, just use it at the physical level. Or maybe IP level, but physical level would be better.

I just dunno how much access to the hardware we have! :/ It'd probably be easier to do something like this in linux where the drivers are already open source, but then we dont have the pretty winders recording software that we need

 

[pilo]

Remember Ethernet != TCP/IP. You can transmit packets over Ethernet without using any standard network protocol.

yes of course you're right. But in this case, we have to rewrite a driver for a card... easy to do with linux, but I think it's not so easy with win/mac. :sad:

 

[mcs]

[quote author="pilo"]But in this case, we have to rewrite a driver for a card...[/quote]
No, you can transmit and receive raw Ethernet packets in most OSs. As far as I know all BSD/Linux systems, WinNT/2000/XP, OS/2 and probably OSX also support it.

VirtualPC and Win4Lin uses this to support NetBEUI for instance.

Best regards,

Mikkel C. Simonsen

 

[pilo]

No, you can transmit and receive raw Ethernet packets in most OSs

mmm yes, but do you think it's possible to acheive good latency?
under linux, which I know well, we must use jack with alsa driver to get good latency time...
But I never try raw mode (and 2 minutes I didn't knew it exists ) so maybe it's possible to use small buffers

 

[mcs]

[quote author="pilo"]mmm yes, but do you think it's possible to acheive good latency?[/quote]
If the Ethernet port is connected to a dedicated link, or a non-crowded switched Ethernet then yes. The port should not be used for other purposes of course.

But I never try raw mode (and 2 minutes I didn't knew it exists ) so maybe it's possible to use small buffers

The Ethernet chips include small FIFO buffers, but they are probably too small. So I guess some kind of driver that transfers the packets between the Ethernet interface and a memory buffer is probably needed. I know that's what VPC/2 uses at least. But don't ask me how to write it :grin:
I have only written drivers for slow PIO-mode ISA cards...

Best regards,

Mikkel C. Simonsen

 

[Rochey]

Guys,

A quick FYI on the Dice Chip - PC and MAC drivers should be released in late Q1 of next year.

There is a Ref Board available for it. There is no real software specifically for the ADC?s and DAC?s. The boards will ship with an SDK including the RTOS for the ARM. TC provide a CLI that you can use for setup of the DICE II, including setting the I2S receivers and transmitters to run in their various possible formats (ie. Left Justified, 24bit, MSB first etc.).

So, we have a few months to get the frontend sorted...

Who's excited?

 

[pilo]

@mcs
mmmm can be an interesting things to do maybe I have a second ethernet card here, but I don't know how much time it will take to try to write an alsa driver for it... and I don't know where to start lol but as the ethernet driver I use is open source, maybe it's doable?

@rochey
How much is it for the ref board? the Dice II chip seems to be a good one! I looked at it abot one years ago, but it was on TCelectronic website! I didn't know wavefront made one too??!!?? on tcelectronic website they say that it's avalaible in BGA and QFP package, none of it can be solder by us?