Configuring eAudioCast Sources Manually

Owned by Jonathan Simon
Last updated: Mar 03, 2022
4 min read

This information is presented as is. In common practice, this information will never be necessary as MMS will always configure this automatically.

In blocks showing communication with an amplifier or amplifiers, right facing arrows indicate data sent to the amplifier and left facing arrows indicate data received from the amplifier. Additionally, the document will refer to the bytes after the zone byte in a command or response as the “data bytes”. All commands and response are formatted:

<command byte><zone byte><data bytes>

 

Indexing Remote Sources

In order to configure eAudioCast sources manually, it’s important to first understand how amplifiers figure out where to request audio from when an eAudioCast source is selected. Consider a scenario where there are two eSeries amplifiers, A and B. Each have two sources. Their model is irrelevant for this example. In order for amp B to receive audio from source 2 on amp A, amp B must know the eAudioCast device ID for A, a UUID, and the 0-based source position on that amp. This source position does not correspond to the source IDs used in the source selection command (03). Rather, source 1 is 0, source 2 is 1, etc.

Assigning Amplifier UUIDs

The eAudioCast device ID is always a UUID. By definition, it must be universally unique if “the universe” is defined as the network on which the amps reside. It doesn’t actually matter what the UUID is derived from, but MMS will always define an amp’s UUID automatically upon inclusion into its System. If an MMS is present, it is imperative that an amp’s UUID not be changed. The MMS will change it back, causing confusion between MMS and other control points.

Retrieving Short IDs

To actually assign a UUID to an amp, that device’s short ID is required. This can be retrieve in a number of ways.

Short ID Retrieval Method One (Device Info)

To get the short ID for all amps in a given amp stack, use the 14 command:

--> 14FF06 <-- 94FF00069301B605060708 <-- 9byte4FF0006A00006090A0B0C0D0E0F10 <-- 94FF000693015A01020304

 

Three amplifiers replied, two M120es (model ID 93) and one M801e (model ID A0 ). The format of the data bytes of the 94 response is structured as follows

byte 1: 00

byte 2: major firmware version (6)

byte 3: model

byte 4-5: short ID

byte 6-n: assigned zones

 

In our example, the M120es have short IDs of 01B6 and 015A while the M801e has a short ID of 0006.

Short ID Retrieval Method Two (Zone Assignments)

This method gets the ID of the specific amp the command is received by over a TCP tunnel.

--> 2FFF <-- AFFF01B605060708

 

The format of the data bytes of the AF response is structured as follows:

byte 0-1: short ID

byte 2-n: assigned zones

Using the Short ID

Once the amp’s short ID is known, its UUID can be define. To do this, use the Network Settings command (3A) with the UUID option (05).

The format of the data bytes of this command is:

byte 0-1: short ID

byte 2: option (always 05 in this case)

byte 3-18: UUID

 

This command should always be sent to all zones (FF) so this command will look like:

--> 3AFF01B605001F77C6F99C075442C3C570081522B3

 

To verify that the value was stored properly, send a Network Settings command with the UUID query option (85). The amp should respond with exactly what you sent it to set the UUID.

Remote Source Structure

All remote sources contain the slot the sources exists in, the UUID of the device that backs the remote source, and the 0-based source index that backs the remote source. They may have a hex encoded UTF-8 string for a name as well, although this is not required. There are 32 remote source slots, 00 through 1F.

 

To inspect the remote sources, send the 4F command to all zones. Without any data bytes, this command will retrieve all remote sources. If the data bytes contain a single byte, that byte will be interpreted as a slot request and the amplifier stack will respond just that slot’s definition. If more than one byte is provided, it will be interpreted as a remote source definition.

 

The format of the data bytes of a given response is:

byte 0: slot ID

byte 1-17: UUID of device that backs remote source

byte 18: 0-based source index of the source that backs the remote source

byte 19-n: hex encoded UTF-8 string for a remote source name

 

Empty remote source slots will only contain the slot ID and no further bytes.

 

Consider the first response:

4FFF00DE04ACF7D206224B846970A359BEF63300506C617965725F4140373042334435393733364342

It resides in slot 00.

It is backed by a device with a UUID of DE04ACF7D206224B846970A359BEF633.

The source on that device is the 00th source.

It has a name of Player_A@70B3D59736CB (in this case, it’s an MMS output)

Defining Remote Sources

To define a remote source, send a command structured exactly like the responses received. Using the UUID from our UUID discussion, this example will define a new remote source into the last slot (1F) backed by the second source on that device. It will also request that slot back for verification.

 

Selecting Remote Sources

Use the same source selection command as for physical sources. Offset the remote source’s slot by 0x20. For example, to select remote source slot 02 into zone 1, send: