| Cellular Mitosis |
Hey guys,
I have been pondering an idea recently, and thought I would bounce it off some of you.
My idea is to develop a cheap solution for a multitrack digital home recording studio.
It is broken down into these peices:
- Analog to Digital Converters
- digital audio to ethernet converters
- PC with an ethernet card
Basically, you have a bunch of mics set up in a recording studio. Each mic is connected to an analog to digital converter. this ADC outputs a stream of digital samples, in SPDIF or similar.
Each ADC connects to a "black box" which takes in digital audio samples, strips off the SPDIF headers and such, wraps them up in a IP packet, and sends them onto the ethernet.
The PC is receiving all these packets from all the black boxes, and is writing the audio tracks to disk.
This idea is cheap, because you can use commodity PC hardware and networkign hardware.
This idea allows you to have conplete control over the audio quality of your recordings, as you decide what ADC to purchase (this is the only peice of the equation which affects audio quality).
This idea is scalable, in that you can set up a 4 track recoding studio, only to later decide you need 16 tracks. You simply add more equipment, and dont lose any of you original investment.
Also, there is no reason you can't have more than one PC receiving packets, as long as you have some method of syncronizing the blackboxes. In fact, there should be no theoretical limit to the number of concurrent tracks you can record.
This idea has been sitting in the back of my mind for probably a year now, but only recently have I decided it might be feasible to implement. Take a look at the picoweb server prototype:
http://www.picoweb.net/download/ccol9908.pdf
There, they demonstrate the feasability of interfacing a microcontroller to a standard ISA ethernet card, including a full TCP/IP stack.
anyone's thoughts on this are welcome.
-jason
jason@pepas.com |
|
|
| tschrama |
Nice idea... if you can get it to work.. could be very nice .. could you do a ball-park calculation off the band width needed in each node of your network.. Wouldn't you need a DSP manage all those megabits..?
thijs |
|
|
| Cellular Mitosis |
well,
assuming 44k/16bit audio tracks,
44100 x 16 = 705600 bits/sec, just for the raw samples.
705600
1411200
2822400
5644800
8 tracks would require more than 5.6 Mbit of bandwidth.
this assumes zero collisions, and does not take into account the overhead of ethernet packet headers.
so, with several NICs in one machine, you could provide more tracks than you will probably need.
however, 100Mbit might be a better way, to account for header overhead and network collisions, etc. |
|
|
| Cellular Mitosis |
Standard networking follows the OSI 7 layer model.
each layer is an abstraction, so that each layer doesnt have to know anything about the layers below it.
each layer wraps the data in more headers.
for an entertaining tutorial, see:
http://www.pe.net/~rlewis/Resources/james.html
7 ...
6 ...
5 ...
4 transport (TCP)
3 network (IP)
2 data link (802.3 ethernet frames)
1 physical
for efficiency, lets say for now we only use up to the IP layer.
from this:
http://www.networkmagazine.com/article/NMG20000727S0013
we see that an ethernet header is 26 bytes:
7 byte preamble
1 byte start of frame
6 byte MAC address (destination)
6 byte MAC address (source)
2 byte frame type
up to 1500 bytes (data)
4 byte CRC footer.
however, apparently the first 8 bytes is considered to be at the physical layer, and is not considered in the typical 1518 byte maximum ethernet packet?
then we have the IP header,
http://www.cis.ohio-state.edu/cgi-bin/rfc/rfc0791.html
which is at least 20 bytes.
thus, even with no samples, our packet is 46 bytes if I am correct.
if we were going for a little better than 50% efficiency, we would need 24 samples at 16 bits each, thus 48 bytes of data.
for 75% efficiency, we need 72 16 bit samples in each packet (190 byte packets)
100Mbit is looking like the way to go. |
|
|
| jduncan |
uh, ok sorry........had to interject here.
First, you should ***REALLY*** try to aim for a bit rate higher than 16 bit /44.1kHz for this......in all seriousness.
Secondly, debating about whether or not to use 100MBit or not is pointless as you cant buy anything slower anymore (or if you can its obsolete and the 100MBit hardware is no more expensive, if not actually cheaper).
So do the calculations again, assuming a 100MBit network and say 24 bit/ 192kHz optimally but at least 24/96 |
|
|
| Cellular Mitosis |
calm down there, my plans are to make it scalable to 96/24, but I was just doing feasability calculations.
the 10mb or 100mb thing is a debate over "can I get away with using ISA NICs" or "do I have to use PCI NICs".
I think I effectively demonstrated that ISA NICs are not the way to go, as they would strain to do 8 tracks of 44/16, making the whole solution not worthwhile.
The implication here is that with PCI, not only could you use more than 8 tracks of 44/16, but the possibility of higher sample rates and resolutions is opened up.
but besides this, debating over 100 vs 10 is not "pointless", as I am sure it woudl be much easier to learn how to interface with an ISA card vs a PCI card, not to mention ISA NICs are cheaper.
hopefully future posts in this thread will be a little more constructive and polite. |
|
|
| jduncan |
cellular, ok im sorry i really didnt mean to come across as rude.
I'll go back and clarify some things as well as respond.
check these two links:
[URL=http://queen.pricewatch.com/search/search.idq?ne=36501&l=36455&CiCodePage=Windows-1252&cr=isa+nic&qc="ISA"*+AND+"NIC"*]ISA Price check[/URL]
[URL=http://queen.pricewatch.com/search/search.idq?ne=36501&l=36455&CiCodePage=Windows-1252&cr=nic+pci&qc="NIC"*+AND+"PCI"*]PCI Price Check[/URL]
As you can see, PCI nics start @ $3, ISA @ $7. Big deal, either way they are both insanely cheap.
Also keep in mind, that more and more newer motherboards dont actually have ISA slots anymore so if you want this to work on all new computers effectively thats out. Interfacing the card is fine, you can make your thing run over tcp/ip, its really not that difficult to do.
The cards drivers add an abstraction removing any difference between pci and isa.
ISA is an old, outdated standard that should not be used for any new products, in a way similar to the thread about people using 2N3904's etc in new designs, its really not something you should do.
I'm sorry I offended you with that, it wasn't my intention, I'm just trying to set you straight. |
|
|
| jduncan |
| dammit, the url's didn't work properly......just copy and paste the link part out, but those prices i posted below are correct anyway. |
|
|
| jduncan |
sorry, i just noticed that i think you were referring to the network on the adc end. the interfacing here is an issue, i'll give you that and i apologize for some of what i said before. however, if you're going to use multiple 10 MBit cards, that's pretty ridiculous.
additionally, now that we're talking about the adc end, use an all-in-one ethernet ASIC.
its much cooler. |
|
|
| Cellular Mitosis |
| cool, I'll look into to all in one ethernet ASIC's, thanks for the tip :) |
|
|
| tschrama |
Hi,
welll.. seems you got if figured out OK... this goes a little over my head ... thanks for the links .. they will really help undetstand more about digital audio and stuff
go for it .. and succes..
Thijs |
|
|
| Havoc |
Only problem will be to sort out all the packets when they start to arrive out of order after some collisions and retransmits. You will need a lot of buffers. Keep in mind that ethernet maxes out at about 70% of available bandwith.
Sounds like you're after soundweb: http://www.bss.co.uk/soundweb/overview.htm |
|
|
| jduncan |
| havoc: that's not a problem......just run a tcp/ip stack on the sender and use tcp connections.....it inherently sorts out out of order packets. |
|
|
| UrSv |
Sounds like a nice idea. I just have one question:
How do you syncronize the sources? I mean when you have say a drum machine a couple of mikes on vocals and guitars and these send stuf to the network and collisions occur they will retransmit at various points in time and the arrival of individual packets from inidividual sources are not syncronized. This even without thinking about the start times for initial transmitting. Are you going to encapsulate an absolute time reference in your packet and have all sources set to reference time? Am I missing something here?
(SoundWeb seems to be for "broadcast" type transmissions which means one source goes to one or many receivers which needs no sync so they would not have any problems.)
/UrSv |
|
|
| hifiZen |
I would use a dedicated ethernet for this sytem, to ensure that there is no other traffic to congest the network and cause unnecessary collisions. The second thing i would do is a few calculations to ensure that the required bandwidth will fit nicely within the capabilities of your 100Mbps limit, along with a simple statistical analysis of collision behaviour. This will ensure that all packets are guaranteed (to a very high percentage) delivery without errors. The analysis would also help determine the size of buffers you'll need for worst-case, out-of-order packet reception. Since i'm feeling lazy right now, i'm not going to do a sample calculation. I'm sure it's not that hard to do.
Synchronization over an asynchronous link can be a problem, though not insurmountable. One method is to use an absolute time reference system, similar to what is employed in isochronous firewire links. The master controller (eg your primary ADC) will have a high-quality, stable crystal oscillator and a set of counters keeping a large absolute time count (say 48 bit or so). Periodically, this time count is captured and sent out on the network to the other nodes, which compare it against their internal counts, and use the difference to make small adjustments to their own clocks. Unfortunately, this is not easy to implement over ethernet, since the precise timing of the timebase packet transmission is a factor in accurately correcting the other clocks.
Perhaps the best method would be to use a single remote box for all of your audio I/O. That way, a single master clock can reside in the box, and data returning from the computer just has to be sent back at the same rate it is coming in from the remote box. You could equip the remote box with ASRCs to handle data format and clock rate mismatches on data coming in from other sources.
I recall discussing this very idea once before on this forum, while also talking about building a standalone DSP... perhaps there's some info in an old post that you may find useful. |
|
|
| Sawzall |
| I would take a look at the Klotz Vladis system. While its not really expensive (thats a relative thing), it is a pretty damn good system. It is used all over the world and seems to have a good technical base. They interface to all sorts of automation, production and storage systems. That being said, start cloning. |
|
|
| Cellular Mitosis |
indeed, synchronization is the main problem i have been thinking about.
The way I was originally going to do it was all the ADC's would be streaming samples to my black boxes, and the black boxes would be waiting for the "go" singal to start transmitting those samples to the central computer. Since they would all be on the same physical link, the time difference would be so small between when each of them received the go signal that it would be largely undetectable. Even if it were, the user would be given the option to pad some of the tracks with empty samples at the beginning (after everything has been recorded).
However, this is sort of a mute point, because even if they all start at exactly the same instant, there is no guarantee that each ADC has a perfect 44.1k oscillator in it. Being even just slightly off would manifest into big synchronization problems if you were recording for an hour or so.
I have decided to do things another way, which should simultaneously solve the synchro problem, and at the same time make more efficient use of the bandwidth.
I thought about what the main advantage of TCP was. That is, it guarantees reliable in-order delivery over a lossy, reordering channel.
However, the re-ordering only occurs when you go over more than one physical connection (one physical ethernet link is all the computers connected on a hub or switch, or a series of hubs or switches. If you don't get routed through something with an IP address, you are on the same physical link. yes, i know, some switches have ip addresses, buts that's different (they are for maintenance - you dont' route normal traffic to that IP address)).
I originally intended this project to only work over one physical ethernet link, so I don't need to worry about reordering. All I need is raw IP.
Using the "everyone talks at once, and if there is a collision, retransmit" idea from TCP really makes no sense in this application, because this is a very specific circumstance. Each host has an identical load, so it makes most sense for them to simply take turns. So you simply do a round robin type communication. Box 1 sends a group of samples, then box 2, then 3, etc.
We fix the number of samples they can send at a time. We also set it up such that if it is there turn and they don't have that many samples yet, they wait until they do.
This forces everyone to transmit at the rate of the slowest link in the chain. Thus, if one black box is getting 45k samples every second, and another is getting 44.1k samples per second, the faster box will simply fill up its buffers and drop enough samples such that it delivers exactly 44.1k samples per second.
One side of me thinks I should worry about making an intelligent algorithm to drop samples, such that if you have 100 in the buffer and another 10 come in, you drop every tenth sample instead of the 10 consecutive ones at the end. However, this is ridiculous, as the difference between the fastest and the slowest clocks in the ADC's will probably be very small, such that you drop 1 in thousands of samples at most.
Now, since we are all taking turns, there are zero collisions. The fact that the packets are a well known size causes another interesting phenomenon.
Normally, you have to listen to the network to see when it is available before you start transmitting. However, there is a small propogation delay involved in the signals traveling over the copper wire. Box 1 transmits his last bit at time unit 10, but I don't receive his last bit until time unit 13 because of the propogation dely. I then see that in time unit 14 there was no data being transmittied, and so I start transmitting at time unit 15. As the size of messages gets smaller, the time wasted waiting on the propogation delay grows larger.
Now, if you are transmitting to each other, you can both talk at the same time, as there are sepparate send and receive wires. But what about when you both want to talk to the same third party?
If you knew the size of everyone's packets in advance, you can start transmitting as you are receiveing the last few bits of the other boxes packet.
Lets say we have box A, box B, and the central computer, C. The delay between A and B is 10. the delay between the boxes and the computer is 5. This means that if B is transmitting, A can start transmitting when he knows that B's tranmission is 5 time units away from completion, and there will be no collisions at the central computer. Thus, we could tweak even more bandwidth out of the network than most other situations.
by the way, I am in a networks class this semester, so if anyone has any questions about networking stuff discussed in this thread, fire away. If I don't know, I can look it up or ask my professor. |
|
|
| Cellular Mitosis |
simply dropping a sample could cause audible distortion.
Perhaps a bettern way to do it would be to go ahead and transmit the extra sample in the packet, but set a flag which tells the central computer "shorten this packet by one sample".
Then, the computer could do it with a littel more finesse, like averaging the distance between the samples on either side of the sample it decides to drop, etc.
in order to keep our synchronization, we would have to build in room for this extra sample, such that everyone either uses it to transmit an extra sample, or transmits all zeros in its place, etc, as long as the packets all stay the same size. |
|
|
| Leschwartz |
TCP/IP, basically tcp at layer 4 is not completely sufficient to keep the packets in order, account for packet delays, variable delays etc. for voice applications, let alone music sampling rates, such as hi fidelity audio. Gigabit ethernet, or at least the 802.1ad extensions would be needed at layer 2 to get better control of the packet flow, support multiple packet streams on the "ethernet backbone" to avoid the lowest probable bit rate problems one previous poster mentioned.
Therefore, additional protocol extensions to IP, such as RTP and RTCP have been specified, "real time protocol", "real time control protocol", as well as "real time streaming protocol". This is just the start of the necessary protocol extensions,. The unbrella term is VoIP, voice over IP, which involves a number of competing standards that are fighting now for market dominance, e.g.; SIP, MEGACO, MGCP, BICC, H.323, etc. have been some of the competing standards in the past several years.
All of this work is evolving now in the telecom - networking field where there is a need and interest to replace digital circuit based call control and switching with (digital) packet based streams and routing. Telecom systems also have the generic problem of needing to efficiently carry multiple streams from any point to any point, and to also collect accounting and billing information, and to make use of network services such as call forwarding, local number portability, IP Mobility, etc., etc.
Billions of dollars are being spent now to work all this out and to make the "next generation" of telecom and neworking equipment. Needless to say any one of these topics will bring a half dozen new engineering text books up in a search of general terms of the subject, like VoIP, voice/video/data convergence.
I'd recommend books by Uyless Black, an older one called "Voice over IP", and "IP Telephony". He is a prolific author of these and many other titles.
I think your idea is an interesting one overall, and when the a/d-to-networking hardware becomes cheap enough and embeddable enough we will definitely see these sorts of systems, with perhaps additionally wireless networking interfaces as well.
One idea along these lines that I had was that MIDI data as well should be able to run over ethernet, instead of that low performance serial cable. I believe Yamaha has a non-standards based or proprietary system available for high end studios, but its not an industry standard in my understanding. With midi, you don't have the basic probelm of the end to end analog to digital conversion, but you just have the problem of encoding midi data into a single standardized (digital code word) format, which based on my research a few years ago was resisted by the supporting members of the MIDI organization. I think this control over the midi standard should be taken out of the control of music equipment makers and turned over to an IETF committie, if it has not been already. Also, such a networked midi implimentation would have to impliment the higher layer IP support protocols I mentioned above like RTCP, RTSP, etc. to support the real time aspect of musical performance. |
|
|
| Daryl Low |
Have you considered skipping IP altogether and just throwing out raw Ethernet packets? IP seems overkill since you're not using any routers. In fact, if you had one Ethernet card per channel, you end up with a dedicated ful-duplex point-to-point link (via crossover cables). This should help simplify your "black box" now that you don't need to cram an IP stack on top of what you already have to do.
Since you're working with raw point-to-point Ethernet, packets will always arrive in order, and there will never be any collisions. Retransmission on CRC error is usually *NOT* done by the Ethernet controller. You just have to ensure that the black box has the smarts and enough buffers to deal with the occasional re-transmit.
The retransmission protocol can be as simple as sending an acknowledgement for every packet sent. A better algorithm would be much like what ZModem uses: the black box continuously sends packets. The master machine only sends on an error (ie. the timestamp of the packet before the corrupt packet). This is a bit more complex because the black box must keep enough old packets around to in case they need retransmission.
If you don't like having lots of Ethernet cards on your computer, make sure you use a switching hub. Never use a dumb repeating hub! A dumb repeating hub will cause lots of collisions under heavy loads. With a switching hub, you end up with each channel getting a point-to-point link to the HUB with zero collisions. The switch has its own internal buffers and it will automatically interleave the packets, so you'll never get collisions on the PC <-> switch link. The bad news is that you might overwhelm the connection to your PC or the buffers in the switch. In either case, depending on how cheap your switch is, you might start losing packets.
WARNING: Not all Ethernet chipsets are made equal. Just like there are modems and WinModems, there are smarter and dumber Ethernet chipsets. Some make the software drivers do the CRC calculations, some do it for you. Some have larger buffers, some have smaller ones. This can and will affect performance under high loads. You have been warned.
Definitely use 100Mbit Ethernet not only for the bandwidth, but because you can probably get lower latencies out of it.
If your put a periodic counter in your black box, simply attach the timestamp to each packet. If you're black box is pure hardware (ie. FPGAs or other programmable logic), then simply hook a high-resolution clock signal to an adder.
If your black box is a standard PC, use the Pentium's 64-bit high resolution counter register, though with that much overhead (sound card, PCI, CPU, OS), network iduced jitter might be the least of your concerns. In this case, you might as well record to the local hard drive and reassemble during post processing.
As long as you stamp each packet, you can align the streams during post-processing, assuming the black boxes have a reasonably accurate clock, there shouldn't be much jitter. What little jitter there is between each black box's clocks will definitely be smaller than the round trip latencies (ping times) over Ethernet. As such, there's really nothing you can do to fix the inter-clock jitter in real-time.
As far as giving the "go" signal... why bother? When your black box is running, just have it start slamming out samples. The master machine simply ignores the samples until it's ready to record. After all, this is how traditional analogue recording equipment usually works anyways.
The basic strategy is to unload as much work onto the master computer as possible. The critical real-time work is all in the black boxes, they must be as simple (and thus hopefully as deterministic) as possible. They will probably be the toughest part, especially if you're gonna use FPGAs or embedded CPUs. Hopefully they'll teach you that in school :) |
|
|
| Leschwartz |
| Daryl, you can't correctly assume that point to point will work for this application, since there are more than two elements peer to peer or client to server in operation, as I will explain further below. And further you can not correclty assume or assert that "raw" ethernet packets will arrive in order, for many reasons, but for one specific to this application, since its not possible to presume that every packet will be transmitted in order with respect to a multithreaded higher layer application which may need to open several communication streams between the functional partners. What you esstentially and incorrectly are trying to analogize is an external buss system in which multiple point to point communications are strictly ordered, somewhat like like in fiber channel or token ring, but even more so with respect to this higher layer applications proceedural requirements. Think about all of the logic glue that is required just to make a "simple" internal buss system work for a single multi-element autotomus system. Ethernet does not work that way, and way not designed to work that way. And applications running over ethernet do not work that way, they need some help from IP, and the other communication protocols I mentioned. To be successful in the market place this application would have to work in a way that will allow other companies to introduce complimentary products and functions. Sorry and respectfully, if you think differently at this point you have some more studying to do. I would prefer to be one of those people who encourage other peoples creative thinking but I'm not going to participate in a conversation where the engineering basics are mangled. The right way to think about this is to study current engineering trends, instead of trying to re-invent the wheel. See the texts I recommended. Your overall approach, trying to limit this to a star configured point to point, single threaded application would be so restrictive and limited as to be rediculus. Further when applications are created, standard libraries are used from software vendors who provide all of the protocols needed for the full stack required to support all of the application's functionality. If you were actually designing the application you would concentarte on the application and again use standard libraries for the interface as well. At this stage of the game an application is not going to come into existance with one person doing it all hardware software etc. from scratch a-z, or even just all of the hardware or just all of the software himself either from scratch. If this were a single autotomus system using a simple serial protocol for communication between two end elements it could be done that way, but we were talking about moving the whole set of capabilites foward several decades and making it truely networkable. Ethernet and the other protocols I mentioned were designed to do a whole lot more than a serial protocol, don't hobble ethernet or the applcation under discsuuion to make it fit into a simpler scheme than it was meant to serve. I think that there are a number of half considered or confused ideas in this thread and I have a feeling this discussion may turn less constructive, so I'm out. I hoped to move the dicsuuion forward by intorducing some points about how it is really done in the real world but the conversation is now regressing. Best wishes to you and your projects. This message is genuinely not meant as a flame but I will not participate in this disscussion any further. |
|
|
| Daryl Low |
| Like the saying goes... "A little knowledge can be a dangerous thing". I'll take a look at your suggested reading. Thanks for politely correcting me, it's greatly appreciated. |
|
|
| peranders |
Have you thought this through? Why make it complicated?
You need one iMac and a firewire AD/DA and a software (ProTools Lite, it's for free) and you are running! If you want more inputs check M-Audio, their products fits both Mac and PC, not extremely expensive. Ethernet sounds not so reliable. |
|
|
| madalo |
i think the TCP/IP idea rocks, it will be extremely scalable, even once firewire has already gone by the wayside.
I think your timing issue is not that tough, the time stamp idea, imho, is the way to go. its the typical method of internet streaming media to keep audio and video synchronized. if you connect a physical sync clock to your black boxes, and wrap the sample packet in a sync packet before you wrap it in a TCP/IP packet, the PC will be able to re-sync them, no prob.
A great source of information on this process can be found in the Windows Media SDKs
PS: if your putting everything on a PCB, just control your ethernet chip with a micro-controller. leave some room for flexibility in the design.
cheers mate, good luck |
|
|
| madalo |
Leschwartz has pretty much hit the nail on the head, no wheel re-invention in this project. use tcp/ip for what it is, as it already works wonderfully. your packeting and transmission from the black box is a two-chip affair (off-the-shelf, even). One thing i do disagree with Leschwartz is not being able to do everything solo, at least thats what I interpreted his post to mean. Sure in engineering companies every proceedure is departmentalized, but I'm sure lots of us in this forum have worn all the hats from time to time. probably plenty of us are even now concurrently working on hardware, firmware, and software development... and if youre not you should be... shame on you :D
later, Dan |
|
|
| Electro |
| Leschwartz, is on the right track. TCP/IP bogs down when the black box have to re-send the packet again. Real-time protocols are better for data that doesn't need to be re-analysed. Video Conferencing works on real time protocol. In video conferencing software, do you want to wait for the last frame to be re-sent or do you want to skip that frame and go on to the next. |
|
|
| johan |
Use this one:
http://magic.gibson.com/thisismagic.html
MaGIC, a new digital transfer protocol from Gibson Labs.
This looks like a very promising format.
| quote: |
Media-Accelerated Global Information Carrier (MaGIC)
Revolutionary new Digital Media distribution standard
Audio, video, control information
Standard CAT-5 (Ethernet) cable
Vastly increased bandwidth (more data)
Much lower latency (higher speed)
Much longer cable lengths with no signal degradation
Only available distribution method for new DVD-A (DVD-Audio) format specifications
Scalable, linkable and upgradeable system
Multiple applications:
High-Resolution Audio / Video distribution
Home Automation Systems
Commercial Wiring Installations
Consumer Products
Telecommunications Products
Low-latency Real-time System
250 µs point-to-point latency times across 100 meters
Works as free-standing or controlled (host-based)
Intelligent, self-identifying networking
Studio and stage systems include Routing Matrix software
Standard Connections
Conforms to IEEE 802.3 physical layer
Uses standard CAT-5 cable and RJ-45 connector
Supports wireless networking
Cost-efficient, easily-accessible cables and jacks
Superior Bandwidth
Up to 32 channels (fully duplexed)
Up to 32-bit data stream
Up to 192 kHz sampling rates
Supports multiple control channels (up to 100 MIDI)
Conforms to multi-channel DVD-A 32/192k specification
Supplies Phantom Power
Scalable and upgradeable
|
|
|
|
| alvaius |
I think this concept sounds interesting, and it has certainly been applied in other applications, i.e. digital, etc.
Some thoughts:
In terms of Firewire being long gone, I think you will find that that does not happen. 1394B will push data rates out past 800mbps and give 100 meter distances. Add in the isochronous data transfer capability and you have a set of capabilities that are beyond Ethernet for certain applications.
I think the biggest issue is going to be synchronization and jitter as many people have stated. While A/D's have gotten cheap, it is still takes money and design expertise to design a really good clock source for low jitter to take advantage of those A/Ds.
Not only will you need a low jitter clock source in each of your Ethernet enabled modules, but those modules will all need to be locked in step in some method. A highly accurate clock will not help, since you still need to synchronize the modules. If you can synchronize the modules, you could probably live without as much clock accuracy as you could simply re-sample the signals at the PC end to remove clock speed variations between the modules. An accurate clock would probably improve the issue though.
In terms of micro-synchronization, you could probably grab a 125MHz clock off the Ethernet PHY Receiver. Have to check some data sheets to see which of them bring this out. They need to generate a recovered clock, it is just a matter of whether you have access to it.
Even if you do not, you may want to consider a different method. Your PC will likely be the standard time base for the system (I think it will have to be)... and that is another problem, because the clock on the $20 PCI NIC in your PC is neither accurate or low jitter. Actually, nothing in your PC is terribly accurate beyond the time clock and even then.... As your PC is the "master" of the system, you could send out a "data stream" that is unique, i.e. a byte sequence say 8-10 bytes that you know what it is. Of course, you will need to detect if it collides or not. On the receiver end, you could put a CPLD/FPGA between the Ethernet MAC and Ethernet PHY and detect this sequence. This will allow you access to an unprocessed data stream that has little added other than the jitter/latency of clock and data recovery. I don't think you would be able to transmit the unique data stream with any sort of regularity or frequency such that you could generate a PLL off of it, but you could use it to "reset" or "set" a time base on the individual modules that could then be used to time-stamp the audio packets. I think to make this all work though, you would need to develop a customer ethernet card for the PC that could also detect this time base generated signal as you would have little to no control over when you initiated the data signal and how much time it takes to actually come out of the NIC as different NICS would have different levels of latency, jitter, etc.
I think this is one of those problems that sounds simple to start, but when you start to turn it into a robust quality system, you find there are lots of pitfalls, and fixing them removes some of the advantages you started out with. I think what you are trying to do is doable, it is all a matter of the quality statement you are trying to achieve. |
|
|
| madalo |
Hey guys, just thought I'd put a few keystrokes to keep this idea/thread alive...
alvaius - this isn't meant as a complaint or insult, but I think you're suggesting to over-design the project. I can say with a high degree of certainty that letting software take care of synchonization is the best method - using the ethernet as a semi-transparent transmission medium. This entire process could be implemented of any physical medium including Firewire. 2nd, I didn't say that Firewire was gone or obsolete in any way. To re-phrase what I said is that TCP/IP with still be around long after Firewire is obsolete.
johan - I read the standard and the website about Magic. It's very cool, and looks basically like what Jason wants to do. The sychronization method they use is very interesting, but it requires more or less tearing apart and rebuilding a custom protocol stack. They claim 80 picoseconds of jitter. I find this standard very interestng, but expensive to implement initially.
jason - take a look at the Magic site and look at the over-all concept. Consider a $600 eval board and if you want to make your own software, another $2500.
Gibson is a musical instrument company, who wants to integrate this technology as a way to bring music from the instrument itself into the recording software. Thats where we reach a big difference in what this product is vs. our homebrew setup. Latencies aren't a big issue with us.
In the Magic system, effects done in real time justify the powerful Sharc DSP. Custom protocol stack assebly/disassembly I would gather is done by the Xilinx PLD (in reference to the pictures of the Magic Eval. kit). The other small square chips near the left of the Xilinx are probably something like Cirrus CS8952 Ethernet driver.
I have used the CS8900 controller before. They work great and easy to control with a micro, I imagine the 8952 (100Mbps) is relatively similar.
A minimal amount of real-time processing needs to occur here, basically inclusion of a [media type] compatible sychonization packet, and TCP/IP packet. So get rid of the Sharc and the Xilinx parts. Although they aren't really expensive, they take a very high level of expertise and equipment to use.
Motorola, Analog Devices & Microchip technology offer hybrid DSP/micro devices. Powerful processing of a DSP, with simple control of a micro. They can use perhaps from 50 to 100 instructions. Thats nothing compared with a pure DSP or microproccessor, so they aren't difficult to get running.
The DSP/micros run up to 100 Mhz - 150 Mhz and offer enough processing power to take data from your ADC and arrange the media synchonization packets, and TCP/IP stack. Perhaps you could set up a small RAM buffer with it too, to make up for network latency or stalls. It would also cover the basic micro functions of controlling the ethernet chipset and the ADC chipset as well. Keep in mind, that this setup is only for 1 "black box".
Also I mentioned "media type" synchonization. By media type, I mean whatever SDK you will use for creating your recording/editing software. Your timing/synchronization packets generated in the black box will need to be compatible with whatever methodology described in the SDK.
Myself - I am quite familiar with Windows Media SDK. This whole project could be done in Windows Media, but there must be 100's of other brands. I don't know about prices, but I do know that Windows Media SDK is free. (and sometimes it works with Windows!)
As for "black box" synchronization, I would recommend a 50ohm coax, non-terminating at the box, connected with BNC "T" connectors on front or rear panel of each box. Provide a very stable master-clock, and terminate the open end of the cable run. Careful attention to grounding, signal path and trace impedances with give you a very accurately synchronized clock to each ADC module.
Over all it's not as fancy as the Magic system, but I don't think its wise to reinvent a real-time transmission protocol for a homebrew set. As well, I think a lot of the real-time DSP functions aren't really neccessary in a recording environment. They can all be done in the computer afterward.
Anyway, bedtime (again!) cheers guys, good night.
Dan
PS: Ultimately with enough internet bandwidth, you could have a remote recording studio - Or - Say you want to record 'your' band live in another city, but you can't go... they take the black boxes with them and plug it to a broadband internet connection, then you just sit at home and record, controlling the mixing and everything. Of course thats just an afterthought. |
|
|
| psarin |
hi
going back to your original post about taking inspiration from the picoweb project - have you thought of using udp sockets rather than tcp/ip sockets?
(just look up 'udp' information on google).
in my realtime systems programming work, i've found that the full-shebang handshaking of tcp/ip just bogs down the network (you'd be lucky to achieve 25-40% of the bandwidth in a 100Mbps system, but you'd ensure 100% data continuity). using udp, you can really get 80-90% of the bandwidth, with some dropped frames, but usually you can design integrity checks into your data format, such that elementary checks at the recieving end make sure that you are not getting garbage.
in general though, i like the way this thread started out. let me know if you want to collaborate; i've built the picoweb thingy some time ago (it was a lot of fun!) and have a fair amount of DSP/realtime systems programming background.
i had been toying around with ideas on the reverse of what you're suggesting, i.e.
consumer hard-disk music storage unit (tivo etc)
-> broadcasting digitally overly wireless-lan
-> powered speakers with builtin wireless recievers and DAC to
convert the digital stream and reproduce music.
it would be hard to make it a hi-fi application, but it would be some fun. ... as would be your recording idea!
cheers -
pradeep |
|
|
| alvaius |
Madalo, no insult taken.
However, I was trying to describe a system that works exclusively over ethernet/TCP-IP, without extra wires, modified protocol stacks, etc. ,etc. The system you describe requires an extra co-ax to be run to every unit. Extra wires, extra drivers, isolation, etc.. This did not seem to be in theme with the origal post. Even with your scheme, you would still need some level of sophistication in your clocking scheme to guarentee an equal number of samples from every unit, or the ability to measure unit time.
At the module end, I think my idea is actually fairly simple to implement and could cover off all the timing and synchronization issues. The only thing I don't like is my suggestion for a custom PCI NIC for the PC, but I am open to thoughts on how to fix this and achieve the goals.
I think that it is a given that 100 MBPS is needed. To that end, I would suggest using an MCF5272 from Motorola which has a 10/100 MAC built in. They are reasonably inexpensive and you can readily find a Linux port for them. They also have a MAC if you want to do some basic DSP work. Add a $2 PHY from National and you are all set. You have access to the MII port between the two and could watch for data patterns for synchronization.
I am not sure that I would make much use of DSP on the modules. A 1.7 GIG P4 Pentium could take the place of numerous DSPS, whether they be Shark, DSP563xx, etc. This keeps the modules simpler. (If you don't believe me on the DSP Horsepower claim, go to BDTI and check their tests). Contrary to what TI may tell you, the fastest DSP processor is not a DSP at all. It would be a toss-up between a Motorola 7455 or a P4-2.8GIG.
One issue you will find with 100meg ethernet is that almost all the MAC and MAC\PHY combos have ethernet interfaces with the exception of a few chips from SMSC. That is why I suggest the MCF5272. However if you want an external MAC\PHY, you may want to consider the MCF5249 processor for the great audio interfaces and large internal memory, not to mention flexible ports. It may make for an easier system than a DSP. |
|
|
| haldor |
The subject of sending audio over networks was recently discussed on the www.churchsoundcheck.com. This is more than just an intellectual exercise. There are several players in this market for live sound and recording studios. To quote Ray Rayburn who definitely knows something about digital audio:
| quote: | Gibson’s MaGIC
Yamaha's mLAN
Peak Audio's CobraNet
They all are similar but not exactly the same. The similarity is that they provide a multi-channel digital audio transport mechanism. Here are a few of the differences:
AES3 which is sometimes called AES/EBU carries two channels over a shielded twisted pair cable or coax. It is not a network but strictly point to point. Maximum distance is around 100 meters.
SPDIF is the "consumer version" of AES3 runs only over coax and relatively short distances.
MaGIC uses the "physical layer" of Ethernet. In other words they use Cat 5 cable and "RJ45" style connectors but after that the similarity ends. They say they can send 32 audio channels each direction over a Cat 5 cable of up to 100 meters long. This is not a network but strictly a point to point connection. Their big advantage is low latency. MaGIC is looking like it’s getting a bit closer to reality. The guitar with the MaGIC output has been announced but not delivered. They are selling development boards in an effort to try to get manufacturers on board. Last year they did not even have development boards.
MADI is a multichannel version of AES3 and allows up to 56 channels over a cable but with shorter distances such as in a control room.
mLAN uses Firewire or IEEE1394. It is a real network. It is compatible with other mLAN devices on the 1394 network, but not all audio over 1394 is mLAN so you must not assume that non mLAN devices will work just because they are also using 1394. One of the limitations is distance. 1394 works fine over short hops around a room, but is not suitable for long distance connections. I note that Yamaha has licensed CobraNet and has come out with their first CobraNet products.
CobraNet is fully compliant with all the Ethernet rules, and is transported over standard Ethernet networks or other networks that can carry Ethernet such as ATM. It is a real network and allows signals to come on and off the network at any point. A single Cat 5e can carry up to 64 channels of audio each way if Fast Ethernet is used (100BaseT). The same cable can carry up to 640 channels of audio each way if Gigabit Ethernet is used. Fiber versions are available. Over copper wire a single run can be up to 100 meters and using fiber distances in excess of 70,000 meters are possible. Standard Ethernet techniques can be used to build networks that are highly reliable with automatic changeover of failed components or links. Something like 28 companies have licensed CobraNet, and many products are available.
Conclusions:
Just about all of the above can be converted to AES3 as the most basic interface type so you should be able to get almost any sort of digital audio converted to any other form.
AES3 is the most basic and almost everything else can be converted to this.
SPDIF is only on your consumer gear, but can often just connect to an AES3 input and work. If not converter boxes are available.
MaGIC you don't have to worry about yet since nothing is shipping :>)
MADI is usually only found on recording studio gear and can be converted to AES3.
mLAN is found on some recording studio gear and a few other things and can be converted to AES3 if needed.
CobraNet is what the vast majority of the sound reinforcement gear is using, and can be converted to or from AES3.
So I would say you don't have to worry unless you buy into something which can't convert to AES3.
Ray A. Rayburn
Application Engineer
Peak Audio a division of Cirrus Logic, Inc.
http://www.PeakAudio.com/
|
|
|
|
| madalo |
haldor - interensting post, it's commercially viable! yeah! (in churches no less!)
alvaius - thanks for reply. for a stand-alone single ethernet cable connection, i don't see any way around making a custom nic. that's essentially what the Magic system uses but not pci & more stack mods. i haven't yet taken a look at the others haldor mentioned. looking at it this way, a custom nic wouldn't be any harder than custom hardware in the black boxes. the only disadvantage i see of the single ethernet cable is you may be limited to a single node. I think you have to forget about routers and switches. you could definately make the custom nic fully TCP/IP compatible even though it has a lot of trick features.
i have a feeling that its possible to do it either way, nic or coax. jason's (cellular mitosis) oiginal post was based around the word "cheap" and using off the shelf computer parts for the networking segment. Other than that, I think we're genrally headed in the right (at least constructive) direction, it's too bad some people left the discussion so early.
pradeep - if any of this becomes more than just a day dream, your dsp skills will be appreciated :D
i like udp, its more efficient for real time. good for my windows media. it's the real-time breakfast of champions. i have to note though, that if were using this system to record, rather than real-time transmission - and the availability of an over-run (latency) buffer in the transmitter is an option - wouldn't 100% data integrity be better trade for the efficiency (think CLASS A). it's not running a very large number of channels anyway. i guess that's why i've never veered far away from the TCP/IP stack. i dunno, what would we call this thing? "quasi-real-time virtual recording"? :)
anyway, now i've started to make us sound like a product development team, but.... what were talking about is slowly becoming in the same caliber as the current systems being marketed. where's the manager!? - has anyone seen a post from Jason recently? By the time he reads this, we may be finished - ahead of schedule, but over budget :D
Cheers, Dan
PS: - on a project i once went over budget on coca-cola - |
|
|
| peufeu |
Some people still subscribed to this thread ?
I have a board streaming audio over UDP right now. Version 2 PCB is in the works (actually it should be assembled by the end of the week).
If some people here are still interested, go there :
http://www.diyaudio.com/forums/show...023#post1497023 |
|
|
|
