MIO 2882 questions

Recording Techniques, People Skills, Gear, Recording Spaces, Computers, and DIY

Moderators: drumsound, tomb

Post Reply
jhcore
ass engineer
Posts: 49
Joined: Sat Nov 28, 2009 7:04 am

MIO 2882 questions

Post by jhcore » Sat Nov 08, 2014 2:33 pm

I just picked up a used Metric Halo 2882+DSP box today. It's playing nice with my OS (10.7) and Logic is routing everything through it properly. However, for the life of me, I can't seem to get the Monitor Controller to kick in. No matter what I do, the dial in the UI is greyed out. The tutorial video clearly shows a "Monitor R/L" option in the config dropdown, but I don't have that option (nor do I know if that's why my option is greyed out!). The levels from this MIO box are LOUD, and I'm looking for a way to temper the dbs without getting some kind of pad before the monitors.

Also, I didn't realize that one of my analog outs would be taken up by monitors. Normally I run 8 outs into a Folcrom, then back into the DAW. Now I only have six outs to play with! Would a workaround be to link up my old Saffire 40 and monitor through that?

User avatar
iC
pushin' record
Posts: 228
Joined: Wed Nov 29, 2006 6:25 pm
Location: Rockland NY
Contact:

Post by iC » Sat Nov 08, 2014 3:01 pm

are you using MIOmixer? you could lower levels thru its bussing architecture.
also pre-requisite have you updated the firmware....
i run two MIO's with a Benchmark DAC1 hanging off the AES (i don't know if the Saffire offers such a digital option) and monitor thru the Benchmark, leaving the MIO's for 16 channels/32(?) of output for inserts/summing...
"There is nothing in a caterpillar that tells you it's going to be a butterfly."
R. Buckminster Fuller

jhcore
ass engineer
Posts: 49
Joined: Sat Nov 28, 2009 7:04 am

Post by jhcore » Sat Nov 08, 2014 3:13 pm

Thanks for the reply!

Sometimes when I get some new toy, I'm dumbstruck by the myriad of options and configurations I can do with it. The 2882 is a definite case in point. When I was going through the quick setup guide, everything was going seamlessly until I hit this Monitor Controller snag. In lieu of getting this to work, what kind of bussing alchemy can you suggest to temper the volume?

And I actually don't know if I have the "Expanded" or standard version of this unit. The package of software/drivers I downloaded have updates for Legacy and 2D, but I believe it's been implicitly stated to not use one update for another! FWIW, the "+DSP" label on the front of the unit is in a tragic comic sans/Disney-esque kind of font.

User avatar
iC
pushin' record
Posts: 228
Joined: Wed Nov 29, 2006 6:25 pm
Location: Rockland NY
Contact:

Post by iC » Sat Nov 08, 2014 3:37 pm

i don't have an answer to your specific issue. That said. LEARN MIOmixer. Its dead simple, but modular (read:possibly confusing) as far as routing.
take the time to grow thru their tutorials.
http://mhsecure.com/metric_halo/support/tutorials.html
MIO mixer is on their download page.
and Google is your friend:
http://www.metric-halo.com/media/legacy ... oller.html

Seriously. these boxes are superdocumented. all your info is out there. plus they answer their Help Tickets....

Monitor Controller FAQ:

Why are some of my output trim controls greyed out in the ?Analog I/O Control? pane of the MIO Console window?

A: When you have assigned an output as part of a Monitor Path, the monitor controller takes control of that channel for the purpose of controlling its output level. Since the monitor controller is controlling the channel level, it would not make sense for the trim knob in the Analog I/O Control pane to also change that setting. As a result, the corresponding control in the ?Analog I/O Control? pane is disabled and its setting automatically updated as you adjust the Monitor Controller. If you remove that channel from all Output Paths in the monitor controller, that output will be restored to manual control in the ?Analog I/O Control? pane, and its trim knob will no longer be greyed out.

Why are some of my output routing controls greyed out in the Output Patchbay of the ?Mix/Output Routing? pane of the MIO Console window?

A: When you have assigned an output as part of a Monitor Path, the monitor controller takes control of that channel for the purpose of controlling its routing. Since the monitor controller is controlling the channel, it would not make sense for you to change the routing independently. As a result the corresponding routing control in the ?Mix/Output Routing? pane is disabled and ?greyed out?. Its setting is automatically updated by the monitor controller as you make changes, and if you remove that channel from all monitor paths, it will be restored to manual control in the ?Mix/Output Routing? pane.

Why is the Monitor Level Control and Dim button greyed out and disabled?

A: There are two reasons that the Level Control can be disabled. The first reason is that you have locked the Level Control with the ?Lock? button. The second reason is that there is no currently selected Output Path.
"There is nothing in a caterpillar that tells you it's going to be a butterfly."
R. Buckminster Fuller

jhcore
ass engineer
Posts: 49
Joined: Sat Nov 28, 2009 7:04 am

Post by jhcore » Sun Nov 09, 2014 4:35 am

Thanks again. I was getting headachey last night, so I opted to set aside this configuration issue and wait to address it today. Hopefully, with all the resources you posted, I can sort this all out.

comfortstarr
re-cappin' neve
Posts: 679
Joined: Wed May 07, 2003 4:25 am
Location: Minneapolis, MN
Contact:

Post by comfortstarr » Mon Nov 10, 2014 11:37 am

If the box isn't "2d" (expanded), I don't believe you can use the monitor control. I have a 2882 + DSP, but it's not "2d."

They're about to come out with some new thingy that upgrades the boxes (and, strangely to my mind, switches them from Firewire to USB2). I've been putting off upgrading to 2d, now I'm going to wait and see what this new thing is (whilst they've described it on their FB page, I couldn't understand it at all!).

jhcore
ass engineer
Posts: 49
Joined: Sat Nov 28, 2009 7:04 am

Post by jhcore » Mon Nov 10, 2014 1:51 pm

It looks like the crux of my issues have been because I haven't enabled Legacy support with the MIO software. And the folks at MH have been guiding me along (their customer service is fantastic!), pointing game in the direction of the appropriate software bundle.

I'm seriously considering doing the 2D upgrade; but unless there's a profoundly compelling argument for USB2 over firewire, then this latest thingy I might skip.

On that note, has anybody "field attempted" the 2D card installation. I'm not terribly mechanically inclined, but damn I could stand to save $100 or so right about now.

User avatar
iC
pushin' record
Posts: 228
Joined: Wed Nov 29, 2006 6:25 pm
Location: Rockland NY
Contact:

Post by iC » Mon Nov 10, 2014 7:48 pm

Field dressing the 2d was stupid easy.
Like unscrew the box and swap the cards easy.
"There is nothing in a caterpillar that tells you it's going to be a butterfly."
R. Buckminster Fuller

User avatar
analogika
gettin' sounds
Posts: 116
Joined: Sat Aug 17, 2013 2:41 am
Contact:

Post by analogika » Tue Nov 11, 2014 9:06 am

jhcore wrote:It looks like the crux of my issues have been because I haven't enabled Legacy support with the MIO software. And the folks at MH have been guiding me along (their customer service is fantastic!), pointing game in the direction of the appropriate software bundle.

I'm seriously considering doing the 2D upgrade; but unless there's a profoundly compelling argument for USB2 over firewire, then this latest thingy I might skip.
The profoundly compelling argument involves everything about the upgrade EXCEPT the switch to USB (which is irrelevant to the technical quality of the solution, but quite practical, given the fact that no new Macs come with Firewire out of the box anymore).

There is a HUGE upgrade in DSP power between 2d and 3d, and the routing options mean that this upgrade is one of similar magnitude to the 2d upgrade.

comfortstarr
re-cappin' neve
Posts: 679
Joined: Wed May 07, 2003 4:25 am
Location: Minneapolis, MN
Contact:

Post by comfortstarr » Tue Nov 11, 2014 2:51 pm

Sounds like analogika understands it better than I. All I know is that I'm waiting the for the details on the 3d upgrade, rather than upgrade to 2d (I had emailed MH about that, and they themselves said to wait).

jhcore
ass engineer
Posts: 49
Joined: Sat Nov 28, 2009 7:04 am

Post by jhcore » Wed Nov 12, 2014 7:26 am

Agreed. I have no great need (but desire's a different story...) to upgrade; that being said, I'm hoping the 3D release might cause the 2D card's price to go down (and as is, I seem to recall it can be found for under $300). My MBP is the last with Firewire, and I figure I'm going to get as much mileage out of that buss and computer as I can!

For right now, as long as the 2882 allows me to track easily, route out through hardware and back in for mixing/summing, then I'll be a happy camper.

User avatar
analogika
gettin' sounds
Posts: 116
Joined: Sat Aug 17, 2013 2:41 am
Contact:

Post by analogika » Sun Nov 16, 2014 6:02 am

The original mail from BJ Buchalter (chief engineer and founder of MHLabs) to the MIO mailing list back in March?this is huge. HUGE:
From: "B.J. Buchalter"
To: MIO List Discussion Forum <mobileio>
Subject: [MobileIO] More Info about our Messe Announcement

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> 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
[/quote]

Post Reply

Who is online

Users browsing this forum: Google [Bot] and 47 guests