[adit]

Same behaviour here on Windows10, Jarvis 16.1, AudioDSP settings not available for external USB DAC, only for internal audio card. Here is debug log: http://pastebin.com/ftvXaA4z

[adit]

I made some debug logs for Krypton 17.0 Alpha 2, again internal card ADSP processing working, for external DAC not. Here are links:

INTERNAL CARD

http://pastebin.com/2NPFZJz2

EXTERNAL USB DAC

http://pastebin.com/VNFQY6x8

[arcam]

Hi wisler,

I'm having this issue as well since day one of ADSP. If I switch to any audio sink different from AE_DEVTYPE_IEC958 (like AE_DEVTYPE_PCM -> onboard analog output or AE_DEVTYPE_HDMI -> digital output via gfx-card to my TV) I am able to access Audio DSP and subsequent settings and modify sound with the "parametric eq". IEC958 is the old standard for S/PDIF (now renamed to IEC60958).

Maybe I already found the source of this culprit :

In (current git master) xbmc/cores/AudioEngine/Engines/ActiveAE/ActiveAE.cpp bool CActiveAE::IsSettingVisible() line 2755, 2763 and 2769 the DeviceType of the currently set SETTING_AUDIOOUTPUT_AUDIODEVICE is explicitly checked NOT to be AE_DEVTYPE_IEC958 to enable SETTING_AUDIOOUTPUT_DSPADDONSENABLED, SETTING_AUDIOOUTPUT_DSPSETTINGS and SETTING_AUDIOOUTPUT_DSPRESETDB. Is there any reason for these checks ? I'm currently compiling a version with these checks removed - hopeful that this is the last barrier to elevated high end music reproduction

Edit: Disabling the checks works for me - here is the patch I whipped up :

Code:

diff --git a/xbmc/cores/AudioEngine/Engines/ActiveAE/ActiveAE.cpp b/xbmc/cores/AudioEngine/Engines/ActiveAE/ActiveAE.cpp
index 5bb87b2..3221051 100644
--- a/xbmc/cores/AudioEngine/Engines/ActiveAE/ActiveAE.cpp
+++ b/xbmc/cores/AudioEngine/Engines/ActiveAE/ActiveAE.cpp
@@ -2752,21 +2752,16 @@ bool CActiveAE::IsSettingVisible(const std::string &settingId)
   }
   else if (settingId == CSettings::SETTING_AUDIOOUTPUT_DSPADDONSENABLED)
   {
-    if (m_sink.GetDeviceType(CSettings::GetInstance().GetString(CSettings::SETTING_AUDIOOUTPUT_AUDIODEVICE)) != AE_DEVTYPE_IEC958)
-    {
       return true;
-    }
   }
   else if (settingId == CSettings::SETTING_AUDIOOUTPUT_DSPSETTINGS)
   {
-    if (CSettings::GetInstance().GetBool(CSettings::SETTING_AUDIOOUTPUT_DSPADDONSENABLED) &&
-        m_sink.GetDeviceType(CSettings::GetInstance().GetString(CSettings::SETTING_AUDIOOUTPUT_AUDIODEVICE)) != AE_DEVTYPE_IEC958)
+    if (CSettings::GetInstance().GetBool(CSettings::SETTING_AUDIOOUTPUT_DSPADDONSENABLED))
       return true;
   }
   else if (settingId == CSettings::SETTING_AUDIOOUTPUT_DSPRESETDB)
   {
-    if (CSettings::GetInstance().GetBool(CSettings::SETTING_AUDIOOUTPUT_DSPADDONSENABLED) &&
-        m_sink.GetDeviceType(CSettings::GetInstance().GetString(CSettings::SETTING_AUDIOOUTPUT_AUDIODEVICE)) != AE_DEVTYPE_IEC958)
+    if (CSettings::GetInstance().GetBool(CSettings::SETTING_AUDIOOUTPUT_DSPADDONSENABLED))
       return true;
   }
   return false;

[AchimTuran]

@arcam,

great that you created a patch that works for you. Awesome, because I can't test it in my own hardware and I wasn't shure from what the issue was created.

But so far I don't know if it breaks something on other platforms or sound cards. I will talk to our developers and I hope we can integrate a patch that solves your issue and doesn't break other setups or platforms.

[arcam]

Thanks for your positive response, wisler

I share your concerns regarding breaking other platforms or hardware setups. Hopefully someone of the other developers can shed some light on these IEC958 checks. I more than happily volunteer in testing other approaches / patches on Linux.

[Senthil]

Maybe I already found the source of this culprit :

In (current git master) xbmc/cores/AudioEngine/Engines/ActiveAE/ActiveAE.cpp bool CActiveAE::IsSettingVisible() line 2755, 2763 and 2769 the DeviceType of the currently set SETTING_AUDIOOUTPUT_AUDIODEVICE is explicitly checked NOT to be AE_DEVTYPE_IEC958 to enable SETTING_AUDIOOUTPUT_DSPADDONSENABLED, SETTING_AUDIOOUTPUT_DSPSETTINGS and SETTING_AUDIOOUTPUT_DSPRESETDB. Is there any reason for these checks ? I'm currently compiling a version with these checks removed - hopeful that this is the last barrier to elevated high end music reproduction

Edit: Disabling the checks works for me - here is the patch I whipped up :

Could you please share your build? i'm in the same situation SPDIF and DSP is not working. Thanks

[adit]

@arcam,

Thank you for patch, you nailed it! I compiled Krypton image for Wetek Play using your patch, now Audio DSP Settings are available. Would be great if devs will correct this issue in Kodi git master.

[Senthil]

Is possible for someone to build a test windows build with this patch applied? i can test this out and i really need this working. help anyone?

[AchimTuran]

I'm working on this. I will roll out a new testbuild when I finished the buffer implementation in ActiveAE. But I guess you have to wait some days.

[Senthil]

I'm working on this. I will roll out a new testbuild when I finished the buffer implementation in ActiveAE. But I guess you have to wait some days.

Thanks mate, appreciated.