[jeffs7]

quote:

---

Originally posted by millst

I really dislike what I hear coming out of many of the other desks on the market compared to the iLive. The desks I dislike seem to be running at 96k or higher. The iLive runs at 48k.

---

The Yamaha M7CL and CL series run at either 44.1k or 48k and it is available as a setting on each console. I personally have only ever observed it set to 48k. The PM5D can run at 44.1k, 48k, 88.2k, or 96k. There are lots of reasons why a mixer can sound bad, from poor mic preamps to bad processing algorithms. Personally, I would suspect one of these long before I would ever suspect something inherent to the clockrate itself.

I definitely agree with the request for faster boot up and operation and a lower noise floor. The waiting time for the surface or editor to connect is ridiculous! I have yet to buy the iPad app because am afraid to find out it has the same long wait time and then be out the money. I would also like buttons that did not feel so flimsy.

As far as software goes, I think it would be nice to be able to save the layer you are in on each bank in scenes and to allow more special characters (!-,: etc.) in scene and show names.

The biggest thing I would not only want, but expect, is better technical documentation about the hardware and software. In fact, I would like that about the current generation as well.

~Jeff

[jeffs7]

Jeff,

Actually, this was not recorded through a switch. It was the mixrack ACE port through a crossover directly into the computer’s gigabit NIC.

I did filter the results in Wireshark to the source MAC of the mixrack only, but I am fuzzy on the whether the graph shows the filtered or unfiltered results. I will try to repeat the procedure later and generate a packets-per-second graph at the same time.

One possible theory that was advanced to me by A&H tech support was that the computer is interacting with the test due to its inability to keep up.

~Jeff

[jeffs7]

Silent. That was an iDR-32 ACE port connected directly to a SuperMicro server with Intel gigabit Ethernet ports. This was based on a 1 minute capture.

~Jeff

[jeffs7]

Really? Do you have any idea what this hardware 2.0 will entail? Having just bought a new iLive system a month ago, this is a little disappointing.

~Jeff

[jeffs7]

Yep, sadly it is not that.

I have been going through the troubleshooting process with Cisco. They seem to believe that the iLive is sending out traffic which occasionally tops 100mbps and the switch is dropping it during those periods. I am not sure if this is true, but I did take a capture with Wireshark and there does seem to be a regular pattern of spikes.

[img]icon_paperclip.gif[/img] Download Photo/File: ACE_Mixrack_Direct.png
12.42 KB

~Jeff

[jeffs7]

Chris,

Thanks for testing, but mine is not an “S” model. Just a regular C2960, so I am suspicious that could be the reason it worked for you and not me. If you wouldn’t mind, could you issue a “sh int” and “sh cont util” for me roughly 5 minutes after you start the iLive? (The counters are averaged over a 5 minute span).

I have done just that with Wireshark and opened a support case with A&H and it seems like the switch is dropping frames. The “sh cont util” indicates the controllers are running at 100% for those ports, yet the traffic is well below the spec sheet both for total bandwidth and packets per second.

I have contacted everybody I know: A&H, Cisco support forums, my boss at work, my company’s network consultant, and the Cisco Networking Academy at my local community college. Everybody is out of ideas.

~Jeff

[jeffs7]

Yep, I am sure the cables are not at fault. It works with the same cables for a direct connection.

I was talking about this problem with my boss at work (IT department) and he was intrigued, so he let me take home one of their cheap managed HP ProCurve switches. It worked right out of the box! Now I am seriously pissed and confused by the Cisco.

~Jeff

[jeffs7]

It is a Cisco 2960-24TT-L (the L indicates Lan Base). I am running version 15.0. Starting with the switch in the factory default state, I have disabled every recommended protocol and then some and it still will not connect. It seems like the switch just cannot keep up with the connection because it is reporting a lot of dropped frames on those interfaces.

~Jeff

[jeffs7]

To answer multiple posts at once:

It is in its own vlan. In fact, it is the only thing on the switch at the moment.

It is an ACE-to-ACE connection using the ACE ports.

I have the same problem: the network-to-network connection never failes but the ACE always does over my Cisco switches. It sometimes says “mixrack connection lost” and other times it says “mixrack connection failed”. As an interesting test, I borrowed a HP Procurve switch from work and that functions just fine for ACE. I am now scratching my head.

~Jeff

[jeffs7]

quote:

---

Originally posted by tk2k
What you’re forgetting are Talkback, PAFL, and those one-only features. Yes, there could be an option to drop a certain number of channels, but there’s pragmatic issues as well.

For example, two grabbing the same thing at the same time, the monitor engineer trying to EQ the snare, while the FOH engineer tries to as well…. its just crazy. You need a split, and iLive can’t magically double the number of channels.

Basically, if you need a 2nd console, you have the budget for a second iLive T. I see no reason why A&H would do this.

Could they? Probably, or something like it. would it be hard? yes. very.

iDR-48, T-112, Mixpad
College

---

Yes, but that is really more of a reason why it should not be done, rather than why it could not be done. The OP asked if it was even possible in hardware, which I think it might be.

Obviously, you would have to have some major software re-writes to support two independent surfaces or you would have to deal with sharing the same PAFL and talkback bus. The EQ example is already an issue with any kind of concurrent control (Surface, Editor, Mixpad, Onemix, Tweak). For some people, myself included, I would not mind having a second surface, such as an R72, as a small sidecar.

For most people, a second Mixrack with a digital split would still be the way to go.

~Jeff

[jeffs7]

With all due respect, I do not see why it is not possible, at least in hardware.

From a networking standpoint, A&H says that ACE is layer 2 Ethernet compliant. This means that frames with layer 2 MAC addresses are sent across that link, which may or may not encapsulate higher layer data (such as IP addresses, port numbers, etc.). From my own investigations with the editor, it would seem that control data, metering data, and other information is transmitted over layer 3 IP packets, which are encapsulated into layer 2 frames and sent over the link. Audio data (I am not positive on this yet, but if you give me a few days to run a test, I can verify) is sent via layer 2 directly.

Frames are identified by their MAC address; at this layer, IP addresses are irrelevant. Network switches make forwarding decisions based on MAC address alone*. This means that any network switch can be inserted into the ACE link and correctly switch frames, so long as every surface has a unique MAC address. Therefore, it would be up to a software implementation to make use of those packets frames. At least in theory.

~Jeff
Cisco CCNA

*Note that layer 3 switches might include features such as static routing and IGMP snooping which also incorporate some IP address-based logic.

[jeffs7]

It was a T112 and iDR-32. I actually submitted this to them in the form of a trouble ticket and this was the response:

quote:

---

Hi Jeff,

Thanks for your email.

We have recreated the issue you describe and our R&D team will be looking into it.

Apologies for any inconvenience this has caused you.

Best Regards
Allen & Heath Technical Support

---

I know it was not a major issue, but to me it is attention to these small details that make a product “professional” or not, so I definitely appreciate their response.

~Jeff

[jeffs7]

Anybody? Is this documented and known or simply accepted as standard behavior of a “professional” mixer?

I suppose I will submit an actual support ticket and find out what the official answer is.

~Jeff

[jeffs7]

quote:

---

Originally posted by Mr B

Hi Jeff (A&H) the point about STP is interesting, would that also affect the original Ethersound + control data type of setup.
The reason I ask is I use a Gigabit switch at either end of a lump of fibre to form the link between surface and rack, now I am sure it has Spanning Tree “on” which I believe allows me to have a CAT5 link in place simultaneously just in case some accident befalls the fibre.
I have run this system for quite some time without any issues (I think), I do limit the bandwidth available to each link to 100mb I seem to be able to disconnect either the CAT5 or the fibre (one at a time of course) without any perceptible loss of audio or control.
I admit I am not a networking genius so I sure could be making a mistake or I could just be confused.

Thanks
Ian B.

---

Some switches have something Cisco calls an EtherChannel. What this does is to aggregate multiple links of the same speed running between the same switches as a singular link, with data running down both simultaneously. Then if one link suddenly drops out, the switches will immediately reallocate traffic between the remaining link(s). It sounds like this is what is happening because you say you can disconnect one or the other and have the audio continue uninterrupted.

~Jeff

[jeffs7]

quote:

---

Originally posted by ahjeff

With STP, the switch transmits packets. These will interfere with the audio.
…
Hope this helps

---

Thanks, that does help my understanding greatly! I wanted a little review on how STP works (I am CCNA), so I opened up the gigantic Cisco book and re-read the chapter on STP.

If I am correct in my understanding, the packets the switch transmits interfere with the audio because they cause a delay in forwarding. That is, when the switch is first powered on, it goes through and decides if there are any redundant links and disables them. Until that is finished (~50s), all frames are blocked. Then, if there is any change in the network, it will have to re-converge by repeating the procedure and taking another ~50s.

To prevent this, I can disable STP on that VLAN only and leave STP running on my data VLAN (for internet access, not control data)? Of course this relies on the assumption that I can use VLAN trunking between switches (my switches have 1G uplinks with QoS so bandwith should not be a problem).

I am glad to know about the latency – somebody told me that switches would add too much to be useful.

~Jeff

[Author]

Posts