Multisurface GigaAce I/O port is greyed out on secondary suface

[GuilhemParticipant]

Please, can you tell me why the I/O port – GigaAce card Slot is not accessible from the FOH surface ?
so cannot use tie lines

it’s showing fine on the MON console
See pic .

What am I doing wrong ?

Mixrack is showing on both console so having to patch from mixrack 1-64 (FOH)
65-128 (MOn)

setup:

Cti1500 – Mon console (Primary) connected to the internal gigaACE socket on the CDM32 MixRack

Cti1500 – FOH console (seconduray) connected to gigaACE card I/O installed in the MixRack.

both surfaces have different IP
role are setup for both consoles

Attachments:

You must be logged in to view attached files.

[BrianParticipant]

With the DLive system, only I/O cards installed in the MixRack and Primary Surface (the one that is plugged into the built in GigaAce ports on the MixRack) are available/usable. Any cards installed in other surfaces are not going to be available. You should be connecting the FOH surface (the secondary surface) to the MixRack using the built in GigaAce ports on the surface connected to the I/O card in the GigaAce card installed in the MixRack. You should be routing I/O at the FOH surface through the built in connection and not an I/O card installed in that surface.

[msteelParticipant]

I believe that what you are seeing is this:
1) The CDM32 only has one IO port, so as a secondary surface, the FOH must be connected to a GigaACE port installed in Port 1.
2) The signals coming into Mix Rack IO Port 1 are coming from the FOH surface I/O sockets, and the signals are sent to Mix Rack IO Port 1 go to the surface’s headphone jack PAFL and output sockets. As @brian said, IO Ports are not supported on a secondary surface, just a primary surface.
3) The FOH console has detected that Mix Rack port 1 is, in fact, connected to its own built-in GigaACE port. Because it knows this, it also knows that only some of the signals are valid, and it knows what they are. As a result, it does not allow you to route to/from the GigaACE directly, and instead shows that IO to you as surface sockets.
4) The MON console does not know what is connected to IO Port 1 on the Mix Rack. So, it does not do any translation for you, and just shows you that there is a card there and lets you figure out what signal is what on the card.

I would not expect that you would use tie lines in a situation like this. If you are designating channels 1-64 for FOH and 65-128 for MON, then you simply choose which Mix Rack sockets go the those channels. The difficulty that would arise is if you want to use surface IO from one surface on the other/both surfaces. In that case you must do the patching on the surface where the IO physically resides.

[msteelParticipant]

A note on why I think IO ports are not supported on secondary surfaces:
1) Secondary surfaces are always connected through an IO Port.
2) IO Ports have a limitation of 128 channels in each direction.
3) A surface (primary or secondary) uses some of the channels in the GigaACE link for Mic/Line, AES/EBU and headphone signals.
4) As a result, there are not enough channels left to support an IO Card. If A&H had chosen to allow it, at best the upper channels on the IO card would not be accessible.
(Note that the GigaACE protocol itself and the built in GigaACE ports have a much higher channel count capability than the IO card slots – I believe the white paper on GigaACE says it can handle more than 300 channels in each direction. Therefore it makes sense that a primary surface, using built-in GigaACE ports on each end, can support all the surface Mic/Line/AES sockets as well as multiple IO Ports in the largest S-class surfaces)

Now, if you are actually wanting to put an IO card in a secondary surface, I have not tried it, but I have wondered if it might be possible to use an IO card in a secondary interface anyway.
1) A&H have published some of the channel mappings between a surface’s IO sockets and IO Ports. These appear to be fixed mappings between the surface and its built in GigaACE card.
2) Since these mappings appear to be fixed, I have wondered if the audio might always be sent regardless of whether the surface is primary or secondary.
3) If in fact, the audio is always sent, then it would be accessible by patching from the appropriate channels of the Mix Rack GigaACE card.
4) Because the secondary surface limits the user form patching unsupported channels, routing of this type would need to be done on a primary surface.
5) Also, of course, only about half of the IO Port’s channel count would be accessible.
If anyone tries this out, please report back to the forum because people would want to know…

[Author]

Posts