Expose audio signal information

[klada]

It would be great if the library could expose the audio signal information from the current source. Knowing the current sound mode (e.g. "PCM") and channel count is quite useful for automations (automatically switch to suitable output mode).

Sound and video information can be queried through the AppCommand0300.xml interface with the following XML:

<?xml version="1.0" encoding="utf-8"?>
<tx>
 <cmd id="3">
  <name>GetInputSignal</name>
  <list>
   <param name="inputsigall"></param>
  </list>
 </cmd>
 <cmd id="3">
  <name>GetActiveSpeaker</name>
  <list>
   <param name="activespall"></param>
  </list>
 </cmd>
 <cmd id="3">
  <name>GetVideoInfo</name>
  <list>
   <param name="videooutput"></param>
   <param name="hdmisigin"></param>
   <param name="hdmisigout"></param>
  </list>
 </cmd>
 <cmd id="3">
  <name>GetAudioInfo</name>
  <list>
   <param name="inputmode"></param>
   <param name="output"></param>
   <param name="signal"></param>
   <param name="sound"></param>
   <param name="fs"></param>
  </list>
 </cmd>
 <cmd id="3">
  <name>GetAudyssyInfo</name>
  <list>
   <param name="eqname"></param>
   <param name="eqvalue"></param>
   <param name="dynamiceq"></param>
   <param name="dynamicvol"></param>
  </list>
 </cmd>
</tx>

Command to query:

curl -X POST -H "Content-Type: application/xml"  --data-binary @foo.xml http://192.168.20.22:8080/goform/AppCommand0300.xml

Output (for PCM 2.0):

<?xml version="1.0" encoding="utf-8" ?>
<rx>
<cmd>
<name>GetInputSignal</name>
<list>
<param name="inputsiga1" control="1">FHL</param>
<param name="inputsigb1" control="1">LFE</param>
<param name="inputsigc1" control="0"></param>
<param name="inputsigd1" control="1">EXT</param>
<param name="inputsige1" control="1">FHR</param>
<param name="inputsiga2" control="1">FWL</param>
<param name="inputsigb2" control="2">FL</param>
<param name="inputsigc2" control="1">C</param>
<param name="inputsigd2" control="2">FR</param>
<param name="inputsige2" control="1">FWR</param>
<param name="inputsiga3" control="0">SHL</param>
<param name="inputsigb3" control="1">SL</param>
<param name="inputsigc3" control="0">TS</param>
<param name="inputsigd3" control="1">SR</param>
<param name="inputsige3" control="0">SHR</param>
<param name="inputsiga4" control="0"></param>
<param name="inputsigb4" control="1">SBL</param>
<param name="inputsigc4" control="1">SB</param>
<param name="inputsigd4" control="1">SBR</param>
<param name="inputsige4" control="0"></param>
</list>
</cmd>
<cmd>
<name>GetActiveSpeaker</name>
<list>
<param name="activespa1" control="1">TFL</param>
<param name="activespb1" control="2">SW</param>
<param name="activespc1" control="0"></param>
<param name="activespd1" control="0"></param>
<param name="activespe1" control="1">TFR</param>
<param name="activespa2" control="0"></param>
<param name="activespb2" control="2">FL</param>
<param name="activespc2" control="1">C</param>
<param name="activespd2" control="2">FR</param>
<param name="activespe2" control="0"></param>
<param name="activespa3" control="0"></param>
<param name="activespb3" control="1">SL</param>
<param name="activespc3" control="0"></param>
<param name="activespd3" control="1">SR</param>
<param name="activespe3" control="0"></param>
<param name="activespa4" control="1">TRL</param>
<param name="activespb4" control="1">SBL</param>
<param name="activespc4" control="0"></param>
<param name="activespd4" control="1">SBR</param>
<param name="activespe4" control="1">TRR</param>
</list>
</cmd>
<cmd>
<name>GetVideoInfo</name>
<list>
<param name="videooutput" control="1">Monitor 1</param>
<param name="hdmisigin" control="1">4K50</param>
<param name="hdmisigout" control="1">--- </param>
</list>
</cmd>
<cmd>
<name>GetAudioInfo</name>
<list>
<param name="inputmode" control="1">HDMI</param>
<param name="output" control="1">Speaker</param>
<param name="signal" control="1">PCM                  </param>
<param name="sound" control="1">Stereo</param>
<param name="fs" control="1">48 kHz</param>
</list>
</cmd>
<cmd>
<name>GetAudyssyInfo</name>
<list>
<param name="eqname" control="0">MultEQ XT32</param>
<param name="eqvalue" control="0">Off</param>
<param name="dynamiceq" control="0">Off</param>
<param name="dynamicvol" control="0">Off</param>
</list>
</cmd>
</rx>

Regarding speaker/channel config: the speakers/channels with the control="2" attribute are the ones which are active. control="1" are the channels which are available on the device (the ones with speakers connected).

The above example is from a Denon AVR X4800H.

[henrikwidlund]

Nice! Do you know if pre 2016 models with their xml endpoint?

[klada]

I don't know unfortunately. I am using a Denon AVR X4800H and I don't have access to other models. I got that information by examining the communication between the D&M Android App and my device. I was curious because the app displays a lot of useful things.

What I certainly can do is providing more examples. I can also try to tcpdump more things if required.

Right now I am using a Python sensor in Home Assistant (with requests.get), to get the channel configuration (like 7.1) and signal information (e.g. DTS HD-MA) into a sensor and expose this to my Remote 3. But I thought that it would be cool if this stuff could be fetched within the update loop of this library 😄

[henrikwidlund]

I got it working locally with this library, so it's certainly doable, but it would require some refactoring. The "DTS HD-MA" kind of information is already available through the sound_mode_raw property. I'm also not sure about the videooutput, it might show analog outputs in addition to HDMI, if not, then it's already covered by the hdmi_output property. The upside is that they will work without Telnet.

[klada]

I got it working locally with this library, so it's certainly doable, but it would require some refactoring.

Wow, that was quick. Cool! TBH, I was kind of lost when trying to find a good place to implement this within this library. If you already have an idea which part needs refactoring that's good news. Do we need to ask Oliver where and how this should be implemented?

The "DTS HD-MA" kind of information is already available through the sound_mode_raw property.

I think you are mixing this up. sound_mode_raw shows the output/target sound mode. I want to get information about the input signal. For example, in sound_mode_raw I am getting STEREO, if the AVR is set to Stereo, This is not what I want to know. I want to display the actual codec. The GetAudioInfo -> signal field displays the actual codec, such as PCM, ALAC or FLAC when playing online music (tested with TIDAL connect).

And I also want to display the sample rate (GetAudioInfo -> fs ) (this attribute is not always present!).

Edit: Apparently it's different. For HDMI inputs it is pretty much as you say. For Online Music inputs the sound_mode_raw is messed up.

[henrikwidlund]

@klada I don't know if we need Oliver's approval, he also seem to be quite busy with other things as I've had a PR open for some time (this is not a complaint, just an observation).

I think we're misunderstanding each other, I didn't mean to say that sound_mode_raw is the same thing as signal, what I meant is that sound_mode_raw is the same as the sound property in the xml. But if online music is messed up with sound_mode_raw, then it makes sense to expose a new property for it. You could even return the value from the new api in sound_mode_raw and use the private field for _sound_mode_raw as a fallback. What makes it a bit more complicated is that sound_mode_raw lives in DenonAVRSoundMode.

Here is how I solved it in my fork: henrikwidlund@bb8c704

[henrikwidlund]

I actually found that quite a few of these properties are available through telnet. I changed my fork to use that instead.

[klada]

That's great news. You even got the video information, which is also awesome (see #236). 👍 👍

BTW: I have created this hack for my particular environment (I know it's quick and dirty). Don't know if it contains any valuable information. At least you can see what I do with the GetSignalInfo stuff because I really want to know whether I am dealing with 2.0 DTS-HD or 7.1 DTS-HD ;)

[dmutsaers]

Would it be possible for the integration to report the actual input signal format of the Marantz AV 10/AV 20 (e.g., PCM, DD+, Atmos)?
Right now this information isn’t available, and it's the main limitation I'm running into.

[henrikwidlund]

@dmutsaers that info should already be available in the raw sound mode, but it would work even better with the http api and telnet events.

[ol-iver]

We got a baby recently, so there are plenty things to do apart from coding now 👶

I like @henrikwidlund approach to add audio and video info properties 👍
Recently, I started adding some of the properties which are available via telnet only to the HTTP interface too. It would be nice if the properties are available in both interfaces if it is possible. I was not able to finish this task, but I will continue. It is very hard to plan such things at the moment 😅

sound_mode represents the sound mode you can select via the remote control. sound_mode_raw is the sound mode value returned by the receiver. There are multiple sound_mode_raws per sound_mode (like here for DOLBY DIGITAL). It makes sense to expose the sound_mode_raw too because it provides much more details about the sound mode. The naming sound_mode_raw does not sound natural for this. Thus, I'm happy for better naming proposals 🙂

[henrikwidlund]

Congratulations! We also got a baby, almost two weeks old now.

Using http for more properties would be awesome. The only downsides is that they seem to update slower than telnet and requires polling. Maybe you can optimize it a bit by bundling more queries together, or maybe that will only make it worse.

The api calls sound mode raw audio signal.

[dmutsaers]

@dmutsaers that info should already be available in the raw sound mode, but it would work even better with the http api and telnet events.

sound_mode_raw shows the output signal, not the input signal. This is a log of sound_mode_raw on my Marantz (probably not complete):

AURO Surround, AURO-3D, AURO2DSURR, AURO3D, DIRECT, DOLBY ATMOS, DOLBY AUDIO-DD, DOLBY AUDIO-DD+ +DSUR, DOLBY AUDIO-DD+DSUR, DOLBY AUDIO-DD+NEURAL:X, DOLBY AUDIO-DSUR, DOLBY AUDIO-TRUEHD, DOLBY AUDIO-TRUEHD+DSUR, DOLBY AUDIO-TRUEHD+NEURAL:X, DTS HD, DTS HD+DSUR, DTS HD+NEURAL:X, DTS Neural:X, DTS SURROUND, DTS+DSUR, DTS+NEURAL:X, Dolby Atmos, Dolby Audio - TrueHD + Neural:X, M CH IN+DSUR, M CH IN+NEURAL:X, MCH STEREO, MULTI CH IN, MULTI CH IN 7.1, Multi Ch Stereo, NEURAL:X, PURE DIRECT, STEREO, Stereo

Modes like NEURAL:X don’t expose anything about the incoming signal — they only tell you which upmixer or DSP the AVR selected. So unless you make assumptions (e.g., “NEURAL:X probably means PCM 2.0”), you still don’t know the actual input format.

That’s why the HTTP API or telnet events are more reliable: they expose the true input signal details, not just the post‑processing mode.

[ol-iver]

Thank you and congratulations too 😄

If telnet is working the users should use it. The HTTP implementation could be used if telnet is not working because the receiver does not support it, or it is already in use by another application.

The HTTP queries are already bundled. There is a kind of global update which queries all properties at the same time and caches the result. When querying again using the same cache_id the cached result is used.
You have to add the tag to the global update like here and call the update with a cache_id and global_updateenabled (see here). Finally, you can add the update function to the global async_update method.
I did not enable the global update for audyssey because the interface is quite slow (see here), but others look faster.

I'm not at home at the moment, but I can push my work in progress on Sunday, that you can use these code changes as an example.

[ol-iver]

@dmutsaers that info should already be available in the raw sound mode, but it would work even better with the http api and telnet events.

sound_mode_raw shows the output signal, not the input signal. This is a log of sound_mode_raw on my Marantz (probably not complete):

AURO2DSURR, MCH STEREO, STEREO, DOLBY AUDIO-DSUR, NEURAL:X, AURO3D, DTS SURROUND, DTS+DSUR, AURO Surround, AURO-3D, Stereo, DTS Neural:X, Dolby Atmos, Dolby Audio - TrueHD + Neural:X, Multi Ch Stereo, DOLBY AUDIO-TRUEHD+DSUR, DOLBY ATMOS, MULTI CH IN 7.1, DTS HD, DTS HD+DSUR, DTS HD+NEURAL:X, MULTI CH IN, M CH IN+DSUR, M CH IN+NEURAL:X, DOLBY AUDIO-TRUEHD+NEURAL:X, DOLBY AUDIO-TRUEHD, DIRECT, PURE DIRECT, DOLBY AUDIO-DD+DSUR, DOLBY AUDIO-DD+NEURAL:X, DOLBY AUDIO-DD, DTS+NEURAL:X, DOLBY AUDIO-DD+ +DSUR

Modes like NEURAL:X don’t expose anything about the incoming signal — they only tell you which upmixer or DSP the AVR selected. So unless you make assumptions (e.g., “NEURAL:X probably means PCM 2.0”), you still don’t know the actual input format.

That’s why the HTTP API or telnet events are more reliable: they expose the true input signal details, not just the post‑processing mode.

I agree, the input modes should be exposed as own properties. However, we should not replace the existing sound mode but create new properties. This is not about reliable vs. unreliable, it is preprocessing vs. post-processing. They are just different properties.

[dmutsaers]

@ol-iver
That's exactly what I was trying to say 😉