Gibson MaGIC

Media-accelerated Global Information Carrier (MaGIC) is an audio over Ethernet protocol developed by Gibson Guitar Corporation in partnership with 3COM. It allows bidirectional transmission of multichannel audio data, control data, and instrument power.

MaGIC
Manufacturer Info
ManufacturerGibson Guitar Corporation
Development date1999 (1999)
Network Compatibility
SwitchableNo
RoutableNo
Ethernet data ratesFast Ethernet
Audio Specifications
Maximum sampling rate192 kHz
Maximum bit depth32 bits

Revision 1.0 was introduced in 1999; the most current revision 3.0c was released in 2003.[1]

MaGIC is used in several guitar products such as Gibson Digital Guitar.

Capabilities

  • Uses Category 5 UTP cables up to 100 m long
  • Frame-compatible with Fast Ethernet
  • 32 channels, 192 kHz sampling rate
    • 32-bit integer audio
    • 32-bit floating point audio
    • 24-bit integer audio with 4-bit channel status and 4-bit channel command
    • 32-bit raw data
  • Supports line network topology, star topology, and a combination of the two

Network protocol

In terms of ISO OSI model, MaGIC can use physical and link layer (MAC/LLC) based on 100 Mbit Fast Ethernet signalling specified in IEEE 802.3/IEEE 802.3af and IEEE 802.2, however MaGIC implements proprietary network and application layers which can be used with different physical layers such as Gigabit Ethernet or optical media.

The frame consists of 1776 bytes. The network protocol encapsulates each frame application data (1506 bytes) into media payload (1024 bytes) and control payload (352 bytes) fields of the frame. The media payload is reserved for low-latency synchronous audio and video data, and control payload may encapsulate MaGIC control messages, MIDI data, and other protocols.

Media streams are transmitted synchronously without re-sampling or buffering, ensuring minimal latency; each stream has one source and one or more destinations. Control messages are generally broadcast to entire network - each device processes the destination address and forwards to all neighbors if necessary.

Application protocol

A MaGIC device consist of the following logical entities:

  • Unit - an access point that sends and receives control messages;
  • Components - access points for control applications such as power on/off switches, volume controls, control surfaces, or graphical user interfaces;
  • Ports - represent either physical connections or user applications which send media to the network;
  • Media Slot Routers - oute media data streams between through the network.

Individual control capabilities of the device are exposed through the MaGIC Control Protocol (MCP), which allow communication with Components in other devices (a maximum of 65535 per device).

The network elects a System Timing Master (STM) which is the source of synchronization on for all devices. Timecode formats includes MaGIC timecode and MIDI Time Code.

The control data in consist of 12-bit Control Message Code (CMC) 4-bit status field, 32-bit Source (Unit and Component, 16-bit each) and 32-bit Destination, and may contain up to 32 Kbytes of data in multiple frames.

The CMCs are defined into four classes:

  • Network Management Messages (0-127)
  • Well Known Application Protocols (128-511) - used for encapsulation of well-known high level protocols or for transporting messages with well-known format and structure (like MIDI).
  • User Control Messages (512-1023) - proprietary user messages
  • Reserved (1024-4095).

Control links are bi-directional communication pipes between several MaGIC devices, intended for control applications. For example, a control link allows the knob on one device to regulate the remotely located volume on another device through the MaGIC network. Control links allow remote management from a computer with a sophisticated GUI which would act as a network supervisor that would manage other applications. Devices may also establish control links using proprietary mechanisms as long as they are compliant with this specification.

Network management messages

CMC Name Description
0x01Operation CompletionStatus Used for error reporting
0x03Change of STMForces device resynchronization
0x05Address AdvertisementUsed for device address auto-configuration. Tentative address broadcast
0x07Address ConflictReports an address conflict between two or more devices.
0x09Neighbor AdvertisementReports device symbolic name to neighbor devices
0x11Add/Remove Link RecordAdds or removes a record to/from the control link table of a device component.
0x13Establish/Drop Control LinkEstablishes or disconnects a control link between two remote components.
0x15Read/Clear Link TableReads or erases a control link table of a device component.
0x17List of Linked ComponentsProvides list of addresses for linked components.
0x19Read Link ParametersRead parameters of a particular control link.
0x1BList of Link ParametersProvides information about a control link.
0x31Set routing tablePrograms port routing table.
0x33Read routing tableAccesses port routing table data.
0x35Routing table dataReports content of port routing table.
0x41MuteTransmits a list of data slot enable/disable masks.
0x51Read AttributeRequests an attribute value
0x53Attribute ValueTransmits the requested attribute value.

[2]

gollark: I see.
gollark: If *a lot* of people want change, *and* can somehow coordinate on this, in the face of people trying to stop them, and it doesn't go horribly wrong somehow.
gollark: That's not exactly better if it leads to worse outcomes.
gollark: I mean, if you go around trying revolutioning, this will:- probably turn out badly for you- also probably not do much
gollark: I don't agree. "People" in aggregate can, but you aren't that.

References

This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.