Operating System Hide Windows volume OSD (5 Viewers)

[Marcus Venturi]

There is something wrong with the audio code itself.

In VolumeHandler.cs the CreateInstance() medhod has the following statement:

if (GUIGraphicsContext.DeviceAudioConnected > 0)
{
...
}

The if-case is not entered, because GUIGraphicsContext.DeviceAudioConnected is 0 at that time.

It is initialized later (at least on my PC).

Therefore always the VolumeHandlerCustom is created, which is wrong, because I have selected the Vista/Win7 volume handler.

In the base constructor of VolumeHandler there is the same comparision that prevents the

VolumeOSD.HideOSD();

from being called. If I jump there manually, the Volume OSD is hidden on my PC.

@Sebastiii : Can you reproduce this behavior? Does this happen only on my PC?

Looks like the Scale setting in the configuration is irrelevant, always the custom volume handler is taken.

 

[Sebastiii]

Hi Marcus,

I will try to reproduce it. We work on this change with @mm1352000 (more him about the idea to change the code )

 

[mm1352000]

Argh, the code seems to be very messy. I don't like code like this.

@Sebastiii
Why do we have the "if (GUIGraphicsContext.DeviceAudioConnected > 0)" checks?
Is it to avoid initialising/using the "_mixer" object, or...?

Why is the code sometimes checking whether the volume is 19660500 instead of checking DeviceAudioConnected?
https://github.com/MediaPortal/Medi...l/Core/DShowNET/Helper/DirectShowUtil.cs#L945

In general it seems like the Mixer and MasterVolumeHandler classes were designed to handle the situation when no audio end-point is available, so I don't understand why the "wrapping checks" - "if (...)" - are needed.

<sigh>

 

[Sebastiii]

That's why i try to put review in Jira lol but not so much dev look into it (i know that it's not easy) and my coding style is not really nice
About the 19660500, it's a workaround and i remember needed it but i can't remember why exactly. But if you can help us on this, it could be really nice.
Thanks in advance.

 

[Sebastiii]

I have find the review but maybe no explicite
https://issues.team-mediaportal.com/fisheye/cru/MP1CR-663
https://issues.team-mediaportal.com/fisheye/cru/MP1CR-664

 

[Marcus Venturi]

OK, I debugged the code and found the reason for the error.

If fails, because at the the begin of MediaPortal.OnStartup() the ProcessPlugins are loaded and started.

In my case the start code of the UPnP renderer plugin has an access to the VolumeHandler to get the current volume.
Therefore an instance of the VolumeHandler is created long before the audio devices are registered in the OnStartup().

This leads to an incorrect initialization of the VolumeHandler as DeviceAudioConnected is zero at that time..

A quick solution could be to load the plugins after init of the audio devices.

@mm1352000 , @Sebastiii : What do you think?

 

[Sebastiii]

I think it could be ok but i'm not sure, i'm just trying to debug it and DeviceAudioConnected was '24' on my side, so i didn't trigger the value of '0' but i didn't test a lot too lol

 

[Marcus Venturi]

Just install the UPnP renderer plugin, then you should be able to reproduce the problem...[DOUBLEPOST=1452706493][/DOUBLEPOST]To be able to go on I disabled the UPnP renderer for the moment.

@regeszter : I have built the code from your branch and the volume OSD is hidden. For me your code works on Windows 10 Pro. Can you explain me in detail what goes wrong?

 

[Sebastiii]

So just need to move those 2 lines later in OnStartup()

    PluginManager.LoadProcessPlugins();
    PluginManager.StartProcessPlugins();

 

[Marcus Venturi]

I would say yes (assuming that this has no side effect)..