Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Class: AVProcessor
#1
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.
  • 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.
[/INDENT]

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
Reply
#2
Again I am focusing on the things that are used everyday, not all the set up stuff. My Meridian 861 is primarily an audio processor although it does switch the video source. These are my fields

Power: Off, Standbye, On

Source Select: This be a simple select on a string field assuming that the association of different physical audio and video inputs with "sources" is made at setup time.

Volume Absolute: Set linear 0..100 or log -50db..0db volume level

Volume Up/Down: Increment or decrement volume by one unit.

Mute:

Audio Process: Mono, Stereo, Tri-field, Dolby Pro, Dolby HD etc.

Audio Stream: A read only field which tells you the format of the input audio such as mono, stereo, multi-channel, LPCM etc.

Lip Sync Delay: Increment/Decrement and absolute value. Useful if some older films are not properly synchronised

PJG
Reply
#3
Something like Lip Sync Delay would be outside of this device class. It would just be provided by driver specific fields, since it's not something that would necessarily be widely supported. The other stuff is fine. Well the volume will always be a percentage, since that's the only portable scheme. A driver can of course provide a native volume field if it wants to.
Dean Roddey
Explorans limites defectum
Reply
#4
How about controls for multiple zones... sources and volume?
tia, Ron

My HT equipment I want to control by CQC (some day hopefully)
Yamaha CX-A5100, Dune HD pro 4k, Dune HD Pro 4k plus, ISY 994i, LG 86" 4k FP, and a projector in the future
Reply
#5
That's all part of the 'multi-unit' scheme. Each device class can support multiple units in the same device. There are defined field naming conventions for that. So it would be able to handle that, which will be more obvious once I get back to updating this one.
Dean Roddey
Explorans limites defectum
Reply
#6
OK, I took a whack at this one.
Dean Roddey
Explorans limites defectum
Reply
#7
Removed the volume, adjust volume, and mute fields. These are now part of an Audio device class, which I've added a thread for. Various devices will implement this functionality, so it's good to have it as a separate device class, so that you can have generic interfacing to any device that implements this functionality.

And did some more clarification and cleanup regarding multi-unit naming conventions.
Dean Roddey
Explorans limites defectum
Reply
#8
I plan to produce a V2 driver for my Meridian 861 over the weekend. As this is a PDL driver, it does not use the device classes, but I plan to adopt the same naming convention for the fields and enumerated values. What do I do about fields such as LipSyncDelay and AudioStream which are not part of your specification? Do I leave them as they are are, or add the AVPRC# prefix to them as well?

PJG
Reply
#9
pjgregory Wrote:I plan to produce a V2 driver for my Meridian 861 over the weekend. As this is a PDL driver, it does not use the device classes, but I plan to adopt the same naming convention for the fields and enumerated values. What do I do about fields such as LipSyncDelay and AudioStream which are not part of your specification? Do I leave them as they are are, or add the AVPRC# prefix to them as well?

PJG
We'll have to wait a bit for Dean to reply. I've started the conversion of the JVC driver and have the same issue. I don't think that using the AVPRC# prefix is appropriate as it makes the fields look like base class fields. I was planning to indicate an extended field by adding a suffix to the base name like AVPRC-X# so AVPRC-X#LipSynchDelay and AVPRC-X%AudioStream. I think others could argue that since they aren't extensions of the base class that they should have simple names like LipSynchDelay and AudioStream.

I can work either way but it would be nice if we all follow a single convention for additional fields.
Mark Stega
Reply
#10
Mark Stega Wrote:I can work either way but it would be nice if we all follow a single convention for additional fields.

I agree that there should be a single conventions. I am going to leave these additional fields as they are until Dean decides what is best.

PJG
Reply


Possibly Related Threads…
Thread Author Replies Views Last Post
  Class: Security Dean Roddey 34 35,406 01-02-2019, 12:26 PM
Last Post: Dean Roddey
  Class: Weather Dean Roddey 6 6,682 10-11-2018, 11:09 AM
Last Post: Dean Roddey
  Class: Thermostat Dean Roddey 17 26,453 01-29-2016, 10:15 AM
Last Post: Dean Roddey
  Class: SceneCtrl Dean Roddey 20 20,818 03-31-2015, 12:38 PM
Last Post: Dean Roddey
  Class: Irrigation Dean Roddey 8 9,526 01-28-2015, 12:09 PM
Last Post: Dean Roddey
  Class: NowPlaying Dean Roddey 8 9,778 09-23-2014, 02:01 PM
Last Post: Dean Roddey
  Class: Switcher Dean Roddey 9 10,611 08-20-2014, 08:17 AM
Last Post: Dean Roddey
  Class: Projector Dean Roddey 29 26,981 08-11-2014, 08:56 AM
Last Post: Dean Roddey
  Class: Lock Dean Roddey 5 7,185 07-31-2014, 01:24 PM
Last Post: Dean Roddey
  Class: ContactClosure Dean Roddey 7 8,736 07-31-2014, 10:14 AM
Last Post: Dean Roddey

Forum Jump:


Users browsing this thread: 1 Guest(s)