Last month, Paul Wiffen explained how he heard about mLAN a new data-transfer protocol which will allow us to send audio, MIDI, and even video down one FireWire connector. This month, he finds out from Yoshi Sawada of Yamaha's mLAN development team how the system is likely to work in practice. This is the second article in a four-part series. Read Part 1, Part 3 and Part 4.
What's So Great?
Some people I have spoken to since the first instalment of this series said that while they grasped my enthusiasm for mLAN, I didn't make it clear enough just why it is so much better than previous interface standards. To help with this, here are a few comparisons which may help you appreciate the differences in performance compared to other, more familiar interfaces.
As we wouldn't really need mLAN if it weren't for multi-channel audio transmission, let us compare mLAN with existing digital audio interfaces. The most commonly used are AES-EBU at the professional end of the industry and S/PDIF at the consumer end (although this distinction is becoming increasingly blurred). For the purposes of this comparison we can regard them as delivering the same performance, ie. stereo transmission (their bandwidth limit) from point-to-point (ie. the output of one device to the input of another) over each cable connection. Even though ADAT Optical and TDIF transmit more channels (eight), they are still point-to-point protocols. In contrast, mLAN can deliver dozens and dozens of audio channels to any device anywhere on a network.
Perhaps a fairer comparison might be with a computer interface like the Universal Serial Buss (USB), which many of you may have encountered by now on Macs or PCs. The transmission speed of USB is 12Mbps (megabits per second). IEEE 1394 or FireWire, onto which mLAN is piggybacked, can be set to run at 100, 200 or 400Mbps, ie. between eight and 33 times faster. The service interval of FireWire (ie. how often a message comes across) is 125µsecs, eight times faster than the 1msec of USB. But it is not just a question of speed. USB (like SCSI or the old Mac serial interface before it) has to be managed by a computer, so you have an enforced hierarchy with a single computer as host and numerous peripherals dependent upon it for control. mLAN is self-managing (it doesn't require all actions to be initiated from a single controlling device) and is peer-to-peer (industry jargon meaning that all connected devices have an equal status on the network). This means that you can initiate transfers from whatever connected device is most convenient, be it mixer, synth, or computer. This makes life a lot easier if you have more then one person involved in the network: the musician can do what he needs to do at the keyboards, the programmer at the computer, and the engineer at the mixing desk or effects unit.
Meet Yoshi Sawada
To get a deeper insight into how mLAN actually functions and what we, the users, might expect to get in the way of performance from it, I spoke with Yoshi Sawada of Yamaha Corp in Los Angeles. Yoshi is a key member of the mLAN development team, and was at Summer NAMM in Nashville to promote Yamaha's newly announced licensing arrangements the mLAN technology. I began by asking him how long mLAN had been under development.
"As far as a protocol for music and audio was concerned, we decided that producing our own chipset would be the best solution because of digital audio's very specific requirements. Although the I/O medium is the same on 1394, whether you are sending digital video, digital audio or whatever, there are some unique things which you have to take care of with digital audio and MIDI not least their timing relationship to one another which are best dealt with via a proprietary chipset. So we developed a chipset specifically for mLAN, which has the additional advantage that small companies need to do less work and development to support mLAN than if we simply told them how to encode the signals for transmission over 1394. Also, if MIDI data and digital audio are transmitted side-by-side, this makes the LSI chip needed to do the job cheaper, allowing manufacturers both small and large to include the technology in their systems without a significantly higher cost to the end user."
A Little Background
To understand exactly how mLAN works and how it fits into the greater scheme of IEEE 1394, it is helpful to understand the Protocol Stack (see Figure 1 below) which makes clear the relationship of each of the sub-protocols to one another and also the level of the overall protocol which they occupy. Before you study it in detail, however, I'd better explain some basic terms.
"Dividing 2400 bytes by 24, we find we can put roughly 100 channels of audio data over the 200Mbps version of 1394. It should be noted, however, that this calculation ignores the isochronous header and some other overheads. So the actual number of channels at 200Mbps works out at a little less than 100. "What about MIDI over 1394? Well, each mLAN datastream equivalent to one audio channel can carry the equivalent of eight MIDI busses, that is 128 channels of MIDI data. So theoretically, we can accomodate around 800 MIDI busses or 12,800 channels. If you use the 400Mbps version of 1394, the number of available channels for audio and MIDI would be doubled. "However, this spec only applies when you have one audio transmitter and one receiver on a single 1394 buss. If you have more audio devices or any other devices, for that matter on the buss, then arbitration overhead becomes an issue. In practice, this could reduce the audio channel capacity to around 50 at 200Mbps. But this is still an awful lot of channels down a single cable!"
Yoshi Sawada: "The most common question we get asked about mLAN is how many channels of audio data it will be able to carry, and all our literature and publicity on this subject has been left deliberately vague, for the following reason. As I've just explained, audio and MIDI takes the isochronous path. Now, we can use up to 80 percent of the total bandwidth available on the 1394 buss for isochronous data transmission [see Figure 2, which shows the percentages of the 1394 data packet used for isochronous and asynchronous data transmission]. Assuming we use the 200Mbps version of 1394, we can allocate up to around 2400 bytes for one packet of isochronous transmission. To achieve audio data transmission at 48KHz, for instance, each packet of isochronous data must contain six samples for each and every channel of audio we want to send, and each sample of audio data in the A/M Protocol requires four bytes. That means that the each audio channel will need 24 bytes per packet.
"Dividing 2400 bytes by 24, we find we can put roughly 100 channels of audio data over the 200Mbps version of 1394. It should be noted, however, that this calculation ignores the isochronous header and some other overheads. So the actual number of channels at 200Mbps works out at a little less than 100.
"What about MIDI over 1394? Well, each mLAN datastream equivalent to one audio channel can carry the equivalent of eight MIDI busses, that is 128 channels of MIDI data. So theoretically, we can accomodate around 800 MIDI busses or 12,800 channels. If you use the 400Mbps version of 1394, the number of available channels for audio and MIDI would be doubled.
"However, this spec only applies when you have one audio transmitter and one receiver on a single 1394 buss. If you have more audio devices or any other devices, for that matter on the buss, then arbitration overhead becomes an issue. In practice, this could reduce the audio channel capacity to around 50 at 200Mbps. But this is still an awful lot of channels down a single cable!"
If you've been relating this to the diagram, you'll already have realised that the 1394 Protocol is something special, in that it allows both types of information transfer; asynchronous for control and file data, and isochronous for real-time audio and video transfer. Yoshi uses Figure 1 in presentations about mLAN, and at the NAMM show, he took me through it.
"At the lowest level you have the 1394 hardware and cables, known as FireWire, or iLink by Sony. This is divided into two separate transmission paths, the asynchronous transmissions which pass via the Function Control Protocol or FCP and the isochronous transmissions which pass via the Common Isochronous Packet, or CIP.
"The Function Control Protocol is used to send the AV/C a set of control commands for AV devices and other upper-layer protocols based on asynchronous transmission, which I'll come back to later. Digital Video and MPEG data, however, is sent via the isochronous route. This is also how the Audio and MIDI Transmission Protocol that is, the mLAN part is sent. The header of each packet from the CIP clearly states whether the packet contains DV, MPEG or Music & Audio data."
"In fact, what we originally developed under the name mLAN has officially passed a Publicly Available Specification or PAS vote by the IEC and is on the way to becoming an international standard. It is now officially designated IEC 61883-6, and known as the Audio and Music Data Transmission Protocol for the IEEE 1394 medium. Obviously, people will still continue to refer to it as mLAN, as it is so much shorter and easier to say, but we will probably call it the A/M protocol from now on. This is because at Yamaha we are starting to use 'mLAN' to refer to the higher level of specific functions which will sit on top of the Protocol Stack [see Figure 1 again]. Yamaha refers to this higher level as the mLAN Connection Management and it will allow people to get even more out of the network. The best way to look at the difference between them is that the A/M protocol allows you to have multiple channels of audio, while mLAN Connection Management, as the name suggests, manages each stream of audio and MIDI.
"I envisage these mLAN Specific Functions, as they are called, fulfilling three roles, all of which apply to the entire network on both the asynchronous and isochronous side, and not just to the Audio & MIDI Transmission Protocol.
"Firstly, when using multiple streams inside the isochronous data path, you will be able to set up different routings for audio and MIDI data within those streams. This will allow much more flexible configurations of the network without generating more streams than are actually needed for the amount of material that is passing across the network."
"Secondly, connections and configurations which have been laboriously set up by the user for a specific system or situation can be automatically re-established on power-up, saving the need to completely reconfigure the system each time it is powered down and up again."
This can be seen as a sort of system configuration memory, and opens up the possibility of 'user presets', defining the configuration of the network differently for each individual user or task that the network supports.
"Thirdly, you can automate the single most problematic aspect of digital audio networks: the assignment and management of the audio synchronisation pathway. That is, which devices act as the master and generate the word clock, and how the clock is passed on reliably to the other devices in the system. A typical example of this might be the temporary changes in the sync hierarchy needed when bringing in some additional audio material from a source with no word clock input capability, before returning to the standard recording or mixdown configurations. The mLAN Specific Functions would be able to automate this process, taking the burden off the shoulders of the network user."
My thanks go to Yoshi Sawada for taking the time during a busy trade show to talk to me about some of the more advanced aspects of the Music and Audio protocol. In Part 3, next month, we will be taking a closer look at some of the mLAN products which have already been announced and examining the roles they will fulfill in an mLAN network.