05-14-2013, 09:12 PM
(This post was last modified: 08-03-2014, 08:52 AM by Dean Roddey.)
General Description
[INDENT]This thread is for the discussion of standardization of AVProcessor type devices. The general concerns of such devices are control over power, mute, volume, source selection, and audio processing modes. Those are by far the common day to day control functions required. These types of devices are commonly multi-zoned so effectively there are multiple repeated sub-units in the same box.
The issue of processing modes is particularly troublesome for this type of device. The possibilities are legion, and there is no way any generic list will be possible. To make things worse, some devices do not have a consistent view of such modes in terms of what the control system has to send to select them and what it reports as the selected mode. This plays havoc with any attempts to create a simple and consistent view of them.
Drivers that implement this class are also likely to implement the Audio class as well, for volume/mute control, the Power class for zone and main power control, the Switcher class for source selection, and possibly the Tuner class.
[/INDENT]
Fields Provided
[INDENT]The general form of fields for this device class is:
AVPRC#sub~fieldname
See Multi-Unit Considerations below, which are special for this device class.
Power Management Issues
[INDENT]Any drivers that implements this class MUST also implement Power.[/INDENT]
Multi-Unit Considerations
[INDENT]It is extremely common for these devices to contain multiple sub-units, each of which is designed to control a zone of its own. Even when not, it is not uncommon that such a device may later be replaced by one that does. Therefore it is REQUIRED that the field names use per-zone prefixes. Even if single zoned, a sub-unit prefix MUST be used.
It is highly RECOMMENDED that the driver allow each sub-unit to be named by the user. Until such user names are provided, the driver MUST provide default sub-unit names for each supported zone. If the device itself does not provide or imply such names, it is SUGGESTED that they be just Z1, Z2, etc... User naming is not required, but naming the zones allows the user to switch zones much more easily if hardware is swapped about, by just assigning these user provided names to new zones on the new hardware.
It is likely that any driver implementing this class will also implement the Audio, Power, and Switcher device class, and possibly others. If so, the same prefixing convention MUST be apply to the fields of those classes that are zone specific.
It is common in this device class that zones will not necessarily be completely identical in their capabilities, i.e. audio modes and sources are often more restricted in the non-primary zones. So client code MUST NOT make assumptions that one zone will have the exactly same functionality as another, unfortunately.[/INDENT]
Backdoor Commands/Queries
[INDENT]There are none at this time[/INDENT]
[INDENT]This thread is for the discussion of standardization of AVProcessor type devices. The general concerns of such devices are control over power, mute, volume, source selection, and audio processing modes. Those are by far the common day to day control functions required. These types of devices are commonly multi-zoned so effectively there are multiple repeated sub-units in the same box.
The issue of processing modes is particularly troublesome for this type of device. The possibilities are legion, and there is no way any generic list will be possible. To make things worse, some devices do not have a consistent view of such modes in terms of what the control system has to send to select them and what it reports as the selected mode. This plays havoc with any attempts to create a simple and consistent view of them.
Drivers that implement this class are also likely to implement the Audio class as well, for volume/mute control, the Power class for zone and main power control, the Switcher class for source selection, and possibly the Tuner class.
[/INDENT]
Fields Provided
[INDENT]The general form of fields for this device class is:
AVPRC#sub~fieldname
See Multi-Unit Considerations below, which are special for this device class.
- CurAudioMode. This field MUST be a read only String field, which contains the name of the current audio mode. It MAY be an enumerated field but that is not necessary and the large number of possible values often makes it undesirable to bother with. It just provides the text description of the current audio processing mode. If there is the possibility that no mode is set, then one of the values MUST be None.
- SetAudioMode. This field MUST be a write only, enumerated String field, with a limit that enumerates the available audio processing modes that the zone supoprts. We make no attempt to define these values. Any generic code must read the field info, extract the field limits info, and use the list obtained.
Power Management Issues
[INDENT]Any drivers that implements this class MUST also implement Power.[/INDENT]
Multi-Unit Considerations
[INDENT]It is extremely common for these devices to contain multiple sub-units, each of which is designed to control a zone of its own. Even when not, it is not uncommon that such a device may later be replaced by one that does. Therefore it is REQUIRED that the field names use per-zone prefixes. Even if single zoned, a sub-unit prefix MUST be used.
It is highly RECOMMENDED that the driver allow each sub-unit to be named by the user. Until such user names are provided, the driver MUST provide default sub-unit names for each supported zone. If the device itself does not provide or imply such names, it is SUGGESTED that they be just Z1, Z2, etc... User naming is not required, but naming the zones allows the user to switch zones much more easily if hardware is swapped about, by just assigning these user provided names to new zones on the new hardware.
It is likely that any driver implementing this class will also implement the Audio, Power, and Switcher device class, and possibly others. If so, the same prefixing convention MUST be apply to the fields of those classes that are zone specific.
It is common in this device class that zones will not necessarily be completely identical in their capabilities, i.e. audio modes and sources are often more restricted in the non-primary zones. So client code MUST NOT make assumptions that one zone will have the exactly same functionality as another, unfortunately.[/INDENT]
Backdoor Commands/Queries
[INDENT]There are none at this time[/INDENT]
Dean Roddey
Explorans limites defectum
Explorans limites defectum
