As you may know, at the Musikmesse last week, we announced a technology preview of the tech that we will be releasing in an upcoming upgrade for the Mobile I/O Family.
If you did not see or hear the announcement, you can watch a video of the presentation here (note the first 20 seconds or so are in German, but we switch to English after that):
We have announce a set of Core technologies that will form the basis of an upgrade for existing MIO's, LIOs and ULN-8s as well as the basis for future products. These Core technologies are comprised of the following:
1) USB2 Class Audio with MH sureClock transport. - This provides 192 channel (96in/96out) communication at 1x rates - The audio clock and the USB transport clock are decoupled in HW
2) MH Router - This provides 1024x1024 channel router @ 192k on every unit - The router transports audio in one sample - All audio sources and sinks are connected via the router - 1024 channels is large enough that it is effectively infinite
3) MH Link - Each unit has 2 MHLink ports - Each MHLink port provides 128 channels of audio in and out @ 192k - Audio is transported with 1 sample of latency - This is built on the Gigabit Ethernet Physical layer - Connections are on Cat 5 - Cables are inexpensive and ubiquitous - Cables can run 100m between nodes - Connections are transformer coupled, so no ground loops - Fully integrated with the MH Router - Transports audio clock
4) MH Link + MH Router Enabling Technology: - No more aggregate devices - No more legacy I/O to bridge mix busses from box to box - Makes all boxes look like one box to the mixer and the computer
5) MH Router integrates all I/O in the unit - USB - MH Link - ADAT - AES/EBU - SPDIF - Analog - MADI - Not all products will have all I/O types
6) In practice, the combination of MH Link and MH Router mean that audio can be transported from the input point on one box to the output point on the next box with 4 samples of latency, and each additional MHLink hop adds an additional 2 samples of latency.
Since all boxes have two MH Link ports, you can chain boxes as you like. Unlike FireWire and USB, the MHLink is not a bus, so each link has the full bandwidth available to it in both directions.
Since we integrate Automatic delay compensation into the system, effectively each box that you add to the system adds 2 samples of system latency.
For example, if you have 8 boxes to implement a 64 channel system, the system will add 16 samples of overall latency to ensure that all channels are aligned regardless of which box it comes from. This amounts to 333 microseconds of additional latency if you are operating at 48k. At higher sample rates, the latency scales down.
The presence of the router on every box means that any input on any of the boxes can be routed or multed to any output on any of the boxes. This includes the USB, which could be connected to different computers on different boxes.
7) Since the computer transport is USB Class Audio, the units can be used with any host that supports USB Class Audio -- this includes Mac OS X, iOS, Windows and Linux.
8) Of course, in keeping with our commitment to future-proof products, this is an upgrade for every FireWire interface that we have ever shipped.
There have been many questions about what we discussed and I wanted to clear as many of them up as a can. Please find a bit of a FAQ below. In addition, we'll be posting a tech talk that goes into some additional detail. The talk has been recorded, and it is being edited now. We'll post a link once it has been posted to YouTube.
Here is the list with the most asked questions:
*** Q1: I don't understand; is this an upgrade or a different box?
This is an upgrade. It applies to every unit we have ever shipped. 13 years ago, we said future proof, and we meant it.
*** Q2a: USB 2.0? not USB 3, Thunderbolt etc.?
The USB 2 is what we consider to be the baseline for the upgrade and future products. There are a few important points as to why we choose USB2 as the baseline:
1) Every single device you would want to use these with supports USB2 and USB2 Class audio. 2) Neither USB 3 nor Thunderbolt have class implementations for audio - so that means that custom drivers are required, and for the platforms that do not support custom drivers, that means that you simply cannot interoperate. 3) We have been able to implement an exceptionally capable transport layer on top of USB2; we can do 96 channels in and out at 48k (192 channels total) which far exceeds the needs of most of our customers. 4) We have this all working now.
That does not mean that we will not implement USB3 or Thunderbolt. It just means that we are not ready to *talk* about it yet.
*** Q2b: But if you use all the UBS2 bandwidth how do I add a USB drive to the USB bus?
On the Mac (at least) each USB connector is on its own bus. So you can use the different connectors. That being said, if you use a USB3 hub, the USB2 and USB3 busses are actually completely separate (on the same connector) -- so you can attach the interface on USB2 and a USB3 drive, and the two devices will both get full bandwidth.
*** Q2c: Multiple boxes on one USB 3.0 port using a hub might come in very handy…
You don't need to do this because of MHLink -- multiple boxes on the USB bus gets us back to the situation with FireWire -- where each box is independent and you need an aggregate to use them together. MHLink aggregates in HW.
*** Q3a: Will the old FW ports remain, or will everything be swapped so that only the new USB/MH Link interfaces remain?
Everything will be swapped. All the computers that support FireWire also support USB2, so there is no compatibility break, and maintaining support for FireWire would increase the end-user cost of the upgrade.
*** Q3b: Will USB2 bus-power a Mobile I/O?
No.
*** Q3c: Will USB3 bus-power a Mobile I/O?
No.
*** Q3d: Will ThunderBolt bus-power a Mobile I/O?
No.
*** Q4: When I connect multiple computers which will show the Miomixer? All of them or is one the master?
We are still working on this, so we are going to defer answering it until we have a more complete story to tell.
*** Q5: Can I record to two computers at the same time for redundancy?
Yes.
*** Q6: What's all this about 1 sample of latency and USB?
The USB latency is higher than one sample (obviously). USB2 uses 125 microsecond isoch periods. Latency on the USB bus is quantized in units of isoch periods. In the sureClock implementation, we need to have 2 packets plus a couple of samples of safety offset on the input and output side of the USB. The 2 packets correspond to 250 microseconds of latency in each direction.
On the computer side, there is some additional transport latency due to the way that the USB hardware works -- 2 or 3 packets worth. So that is an additional 250-375 microseconds.
On top of that you have the audio buffer latency that is determined by the size of the audio buffer you choose in your host -- that's going to be the same regardless of the transport protocol.
All told the transport latency adds up to around 1 - 1.5 ms (maybe a little bit more) at all sample rates. This is consistent with what we were able to achieve on FireWire.
*** Q7: So very exciting - love the Ethernet connectivity - love to hear the details on USB in/out latencies. But isn't the 1 sample stuff is being taken way out of context?
It is a little bit, in that the USB <-> Computer latency is higher, and is generally dominated by the buffer size you choose for the host.
But the latency is 2 samples per hop (1 sample for input to the MH Router and 1 sample for output from the MH Router) on the box -> box connection, which is much, much lower than anything that can be achieved with other high-bandwidth transports and allows for the aggregation of boxes in a way that we cannot achieve on USB, FireWire or something like Dante.
The latency would be achievable on something like MADI, but MADI does not have the channel counts that we can attain with MHLink, nor does it have the bandwidth for control data, and it has much more expensive and less generally available cabling.
*** Q8: How is MADI integrated?
The tech is done. The realization in specific products is still being determined.
*** Q9: Is this a real ethernet connection? If yes, wouldn't it make sense to connect the device via ethernet to your pc?
Yes it is a real ethernet connection. It is possible to connect via the computer. That being said, MHLink generates packets at a much higher rate than computers really want to deal with, and there are real challenges in getting the latency down to what we wish to achieve when using an ethernet connection that is controlled and shared with a GP OS with a full networking stack.
In addition, while it may not be the case for PCs, in Mac and iOS, current machines do not ship with Ethernet connectors on the hardware, so you are back to needing an adapter. That is not the case for USB.
*** Q10: How can USB be superior to FW in aspects of CPU load and performance?
Modern USB HW uses the same DMA engines that FireWire used. All the data transport is done via DMA, and does not require CPU intervention. In addition, USB audio transport is headerless, so there is no need to do payload extraction and header pre-pending for USB (whereas it is required for FireWire), so the actual CPU intervention is lower for USB than for Firewire.
*** Q11a: Are the 96 channels a total channel count?
It is 96 in and 96 out at 1x (44/48) rates (so 192 total). For each doubling of the sample rate, the total number of channels goes down by half. So 2x rates are 48in/48out and 4x rates are 24in/24out.
*** Q11b: Is this tied to the number of boxes?
No -- the USB channel I/O is controllable independently from the number of boxes, so, for example, if you are mixing in the MIO mixer on one box, you would be able to do so with a much higher number of output channels from your DAW, without having to add additional boxes (for channel count). Depending on what you were doing, you may need more boxes for DSP.
*** Q12: Why is that high channel count not achievable with Firewire?
There are two components for overall transport performance - the capabilities of the computer and the capabilities of the device. The current MIO hardware implements the FireWire protocol layer on a DSP, and a significant amount of the overall limitations are due to CPU and bus bandwidth limitations on that HW. In addition, on the Computer side of things, the number of DMA contexts that is required to be supported by a FireWire controller is fairly low (we pretty much only guaranteed of having 4 input DMA and 4 output DMA contexts).
So those combined together limit the ability to stream the theoretical maximum channels. In contrast, with sureClock, we have implemented the USB transport layer in hardware (without a software component), and that allows us to reach the actual channel bandwidth of USB. In addition, on the Computer Side, USB controllers are required to support DMA for all endpoints up to the bandwidth limit. So bottlenecks are removed on both sides of the USB.
While we could implement the sureClock on top of FireWire as well, at this stage of the game, there really is no point, because every machine with FireWire also has USB, but many machines with USB do not have FireWire.
*** Q13: What's the timeframe?
Some time this year. We'll firm that up when we can.
*** Q14: What's the cost?
Not yet determined, but it will be affordable.
*** Q15: Can we have exact features?
Of course not! As Gustav Graves said in "Die Another Day" -- "It's not a secret. It's a surprise."
*** Q16: and how it's going to become available ?
For existing users, it will be an upgrade like the 2d Card was; new masterboard and new backpanel. It will be field-installable, and we will also offer a factory upgrade service.
For new units, it will be included as part of the unit.
*** Q17: Are there pictures?
Not at the present time. The development hardware we have is not representative of the final product.
*** Q18: How and where is the +dsp available and how do we control it. In class compliant mode especially.
All of the processing you have come to know and love on our hardware will be available on the new hardware - simply with more available DSP. For example, the Firewire transport engine consumed all of one DSP and about 15% of the the other DSP on the 2d Hardware. sureClock uses no DSP at all. The MH Router would consume 100% of the 2d DSP; on the new hardware it uses no DSP at all. As far as the specific forward looking aspects of your question -- we are still working on this aspect, and we'll share more when we can.
*** Q10: I only have one box -- why do I care about this?
Four reasons:
1) Interoperability with whatever platform you want to use at the moment. 2) More of what you already love about your box -- more processing, more channels, more plugins. 3) Easy expandability -- if you need more in the future, you can add more seamlessly. 4) The new processor architecture has a minimum of 1000 times the available memory as compared to the 2d Card. This means that the memory limitations that occur on 2d are simply gone.
If you have further questions, please post them and we'll do our best to answer when we can.
Kérdés
kzl65398
Hátha mást is érint a hír.
Hi Folks,
As you may know, at the Musikmesse last week, we announced a technology preview of the tech that we will be releasing in an upcoming upgrade for the Mobile I/O Family.
If you did not see or hear the announcement, you can watch a video of the presentation here (note the first 20 seconds or so are in German, but we switch to English after that):
Part 1:
https://www.facebook.com/photo.php?v=584657858292385
Part 2:
https://www.facebook.com/photo.php?v=584662884958549
To summarize:
We have announce a set of Core technologies that will form the basis of an upgrade for existing MIO's, LIOs and ULN-8s as well as the basis for future products. These Core technologies are comprised of the following:
1) USB2 Class Audio with MH sureClock transport.
- This provides 192 channel (96in/96out) communication at 1x rates
- The audio clock and the USB transport clock are decoupled in HW
2) MH Router
- This provides 1024x1024 channel router @ 192k on every unit
- The router transports audio in one sample
- All audio sources and sinks are connected via the router
- 1024 channels is large enough that it is effectively infinite
3) MH Link
- Each unit has 2 MHLink ports
- Each MHLink port provides 128 channels of audio in and out @ 192k
- Audio is transported with 1 sample of latency
- This is built on the Gigabit Ethernet Physical layer
- Connections are on Cat 5
- Cables are inexpensive and ubiquitous
- Cables can run 100m between nodes
- Connections are transformer coupled, so no ground loops
- Fully integrated with the MH Router
- Transports audio clock
4) MH Link + MH Router Enabling Technology:
- No more aggregate devices
- No more legacy I/O to bridge mix busses from box to box
- Makes all boxes look like one box to the mixer and the computer
5) MH Router integrates all I/O in the unit
- USB
- MH Link
- ADAT
- AES/EBU
- SPDIF
- Analog
- MADI
- Not all products will have all I/O types
6) In practice, the combination of MH Link and MH Router mean that audio can be transported from the input point on one box to the output point on the next box
with 4 samples of latency, and each additional MHLink hop adds an additional 2 samples of latency.
Since all boxes have two MH Link ports, you can chain boxes as you like. Unlike FireWire and USB, the MHLink is not a bus, so each link has the full bandwidth available to it in both directions.
Since we integrate Automatic delay compensation into the system, effectively each box that you add to the system adds 2 samples of system latency.
For example, if you have 8 boxes to implement a 64 channel system, the system will add 16 samples of overall latency to ensure that all channels are aligned regardless of which box it comes from. This amounts to 333 microseconds of additional latency if you are operating at 48k. At higher sample rates, the latency scales down.
The presence of the router on every box means that any input on any of the boxes can be routed or multed to any output on any of the boxes. This includes the USB, which could be connected to different computers on different boxes.
7) Since the computer transport is USB Class Audio, the units can be used with any host that supports USB Class Audio -- this includes Mac OS X, iOS, Windows and Linux.
8) Of course, in keeping with our commitment to future-proof products, this is an upgrade for every FireWire interface that we have ever shipped.
There have been many questions about what we discussed and I wanted to clear as many of them up as a can. Please find a bit of a FAQ below. In addition, we'll be posting a tech talk that goes into some additional detail. The talk has been recorded, and it is being edited now. We'll post a link once it has been posted to YouTube.
Here is the list with the most asked questions:
*** Q1: I don't understand; is this an upgrade or a different box?
This is an upgrade. It applies to every unit we have ever shipped. 13 years ago, we said future proof, and we meant it.
*** Q2a: USB 2.0? not USB 3, Thunderbolt etc.?
The USB 2 is what we consider to be the baseline for the upgrade and future products. There are a few important points as to why we choose USB2 as the baseline:
1) Every single device you would want to use these with supports USB2 and USB2
Class audio.
2) Neither USB 3 nor Thunderbolt have class implementations for audio - so that
means that custom drivers are required, and for the platforms that do not
support custom drivers, that means that you simply cannot interoperate.
3) We have been able to implement an exceptionally capable transport layer on top
of USB2; we can do 96 channels in and out at 48k (192 channels total) which
far exceeds the needs of most of our customers.
4) We have this all working now.
That does not mean that we will not implement USB3 or Thunderbolt. It just means that we are not ready to *talk* about it yet.
*** Q2b: But if you use all the UBS2 bandwidth how do I add a USB drive to the USB bus?
On the Mac (at least) each USB connector is on its own bus. So you can use the different connectors. That being said, if you use a USB3 hub, the USB2 and USB3 busses are actually completely separate (on the same connector) -- so you can attach the interface on USB2 and a USB3 drive, and the two devices will both get full bandwidth.
*** Q2c: Multiple boxes on one USB 3.0 port using a hub might come in very handy…
You don't need to do this because of MHLink -- multiple boxes on the USB bus gets us back to the situation with FireWire -- where each box is independent and you need an aggregate to use them together. MHLink aggregates in HW.
*** Q3a: Will the old FW ports remain, or will everything be swapped so that only the new USB/MH Link interfaces remain?
Everything will be swapped. All the computers that support FireWire also support USB2, so there is no compatibility break, and maintaining support for FireWire would increase the end-user cost of the upgrade.
*** Q3b: Will USB2 bus-power a Mobile I/O?
No.
*** Q3c: Will USB3 bus-power a Mobile I/O?
No.
*** Q3d: Will ThunderBolt bus-power a Mobile I/O?
No.
*** Q4: When I connect multiple computers which will show the Miomixer? All of them or is one the master?
We are still working on this, so we are going to defer answering it until we have a more complete story to tell.
*** Q5: Can I record to two computers at the same time for redundancy?
Yes.
*** Q6: What's all this about 1 sample of latency and USB?
The USB latency is higher than one sample (obviously). USB2 uses 125 microsecond isoch periods. Latency on the USB bus is quantized in units of isoch periods. In the sureClock implementation, we need to have 2 packets plus a couple of samples of safety offset on the input and output side of the USB. The 2 packets correspond to 250 microseconds of latency in each direction.
On the computer side, there is some additional transport latency due to the way that the USB hardware works -- 2 or 3 packets worth. So that is an additional 250-375 microseconds.
On top of that you have the audio buffer latency that is determined by the size of the audio buffer you choose in your host -- that's going to be the same regardless of the transport protocol.
All told the transport latency adds up to around 1 - 1.5 ms (maybe a little bit more) at all sample rates. This is consistent with what we were able to achieve on FireWire.
*** Q7: So very exciting - love the Ethernet connectivity - love to hear the details on USB in/out latencies. But isn't the 1 sample stuff is being taken way out of context?
It is a little bit, in that the USB <-> Computer latency is higher, and is generally dominated by the buffer size you choose for the host.
But the latency is 2 samples per hop (1 sample for input to the MH Router and 1 sample for output from the MH Router) on the box -> box connection, which is much, much lower than anything that can be achieved with other high-bandwidth transports and allows for the aggregation of boxes in a way that we cannot achieve on USB, FireWire or something like Dante.
The latency would be achievable on something like MADI, but MADI does not have the channel counts that we can attain with MHLink, nor does it have the bandwidth for control data, and it has much more expensive and less generally available cabling.
*** Q8: How is MADI integrated?
The tech is done. The realization in specific products is still being determined.
*** Q9: Is this a real ethernet connection? If yes, wouldn't it make sense to connect the device via ethernet to your pc?
Yes it is a real ethernet connection. It is possible to connect via the computer. That being said, MHLink generates packets at a much higher rate than computers really want to deal with, and there are real challenges in getting the latency down to what we wish to achieve when using an ethernet connection that is controlled and shared with a GP OS with a full networking stack.
In addition, while it may not be the case for PCs, in Mac and iOS, current machines do not ship with Ethernet connectors on the hardware, so you are back to needing an adapter. That is not the case for USB.
*** Q10: How can USB be superior to FW in aspects of CPU load and performance?
Modern USB HW uses the same DMA engines that FireWire used. All the data transport is done via DMA, and does not require CPU intervention. In addition, USB audio transport is headerless, so there is no need to do payload extraction and header pre-pending for USB (whereas it is required for FireWire), so the actual CPU intervention is lower for USB than for Firewire.
*** Q11a: Are the 96 channels a total channel count?
It is 96 in and 96 out at 1x (44/48) rates (so 192 total). For each doubling of the sample rate, the total number of channels goes down by half. So 2x rates are 48in/48out and 4x rates are 24in/24out.
*** Q11b: Is this tied to the number of boxes?
No -- the USB channel I/O is controllable independently from the number of boxes, so, for example, if you are mixing in the MIO mixer on one box, you would be able to do so with a much higher number of output channels from your DAW, without having to add additional boxes (for channel count). Depending on what you were doing, you may need more boxes for DSP.
*** Q12: Why is that high channel count not achievable with Firewire?
There are two components for overall transport performance - the capabilities of the computer and the capabilities of the device. The current MIO hardware implements the FireWire protocol layer on a DSP, and a significant amount of the overall limitations are due to CPU and bus bandwidth limitations on that HW. In addition, on the Computer side of things, the number of DMA contexts that is required to be supported by a FireWire controller is fairly low (we pretty much only guaranteed of having 4 input DMA and 4 output DMA contexts).
So those combined together limit the ability to stream the theoretical maximum channels. In contrast, with sureClock, we have implemented the USB transport layer in hardware (without a software component), and that allows us to reach the actual channel bandwidth of USB. In addition, on the Computer Side, USB controllers are required to support DMA for all endpoints up to the bandwidth limit. So bottlenecks are removed on both sides of the USB.
While we could implement the sureClock on top of FireWire as well, at this stage of the game, there really is no point, because every machine with FireWire also has USB, but many machines with USB do not have FireWire.
*** Q13: What's the timeframe?
Some time this year. We'll firm that up when we can.
*** Q14: What's the cost?
Not yet determined, but it will be affordable.
*** Q15: Can we have exact features?
Of course not! As Gustav Graves said in "Die Another Day" -- "It's not a secret. It's a surprise."
*** Q16: and how it's going to become available ?
For existing users, it will be an upgrade like the 2d Card was; new masterboard and new backpanel. It will be field-installable, and we will also offer a factory upgrade service.
For new units, it will be included as part of the unit.
*** Q17: Are there pictures?
Not at the present time. The development hardware we have is not representative of the final product.
*** Q18: How and where is the +dsp available and how do we control it. In class compliant mode especially.
All of the processing you have come to know and love on our hardware will be available on the new hardware - simply with more available DSP. For example, the Firewire transport engine consumed all of one DSP and about 15% of the the other DSP on the 2d Hardware. sureClock uses no DSP at all. The MH Router would consume 100% of the 2d DSP; on the new hardware it uses no DSP at all. As far as the specific forward looking aspects of your question -- we are still working on this aspect, and we'll share more when we can.
*** Q10: I only have one box -- why do I care about this?
Four reasons:
1) Interoperability with whatever platform you want to use at the moment.
2) More of what you already love about your box -- more processing, more
channels, more plugins.
3) Easy expandability -- if you need more in the future, you can add more
seamlessly.
4) The new processor architecture has a minimum of 1000 times the available
memory as compared to the 2d Card. This means that the memory limitations
that occur on 2d are simply gone.
If you have further questions, please post them and we'll do our best to answer when we can.
Best regards,
B.J. Buchalter
Metric Halo
http://www.mhlabs.com
Link to comment
Share on other sites
válasz erre a kérdésre
Recommended Posts
Archived
This topic is now archived and is closed to further replies.