Library: AudioEndpointControl

[Sem;colon]

I'm no specialist either
The Hardware IDs - yes, they are, but the endpoints seem to be generated by the driver. They just get some kind of GUID that can change if you update the driver.

[jonib]

The Hardware IDs - yes, they are, but the endpoints seem to be generated by the driver. They just get some kind of GUID that can change if you update the driver.

Are you sure it gets changed when updating/changing driver? I assume its connected to the hardware detection, I have been meaning to check that, but like anything I do it will take forever.

jonib

[Sem;colon]

I did, kinda. I updated my Windows 10 to RS1 some months ago and Windows replaced my Realtek audio driver with one from Microsoft (without asking, of course). I found that out because my EG macros, to switch the default device, stopped working after the update, so yes, the IDs have been changed (maybe the name as well, didn't check that). I then installed the Realtek driver again and the IDs changed again.

[jonib]

I did, kinda. I updated my Windows 10 to RS1 some months ago and Windows replaced my Realtek audio driver with one from Microsoft (without asking, of course). I found that out because my EG macros, to switch the default device, stopped working after the update, so yes, the IDs have been changed

OK, I read that others had driver related problems after the anniversary update.

(maybe the name as well, didn't check that).

The device name might be more stable (or less ha ha)

I then installed the Realtek driver again and the IDs changed again.

To the old ID or something new again?

My ambition in the library is to have an ID of the audio device that is stable as long as the hardware hasn't changed (If at all possible), but that is after I get the basic functionality implemented.
There are hardware info in windows that is not changed with a driver so I should be able to use that, but that's for later, ETA about 2030

jonib

[Sem;colon]

If you do, great! But I guess we don't want to wait that long
Are you happy with how the (unreleased 0.2 version) of the AudioEndpointControl lib currently is?
If yes, I'd create a PR at EG github and see what happens

[jonib]

If you do, great! But I guess we don't want to wait that long

Well quality takes time.

Are you happy with how the (unreleased 0.2 version) of the AudioEndpointControl lib currently is?

Happy no (I'm a perfectionist so I will never be truly happy), but it seems usable enough for what it's used for in EventGhost, so should be fine. And if there are bugs those can always be fixed.

Basically I'm redoing some stuff to make it more Pytonic by changing the data types to more useful objects, not a big change to the functionality. Just don't know when, there is usually months between me working an a specific project. Right now I'm working on the XBMC2 plugin, basically rebuilding it from scratch.

jonib

[Sem;colon]

OK, in that case I'll go on with what we have now.

BTW. I like the XBMC plugin, I'm excited about what you will change!

[jonib]

OK, in that case I'll go on with what we have now.

OK.
And as I never got to comment on your code, here is some:

You register to get events from all devices then in the event you discard all but the default, seems unnecessary, so register all devices get all events or register only the default.

Code: Select all

            for AudioDevice in AudioDevices:
                AudioDevice.RegisterControlChangeNotify(AudioEndpointVolumeCallback(OnEvent))

You have some ".GetMute()==1" that should work like this ".GetMute()" as it returns a Boolean anyway.

This code:

Code: Select all

                    if targetDevice.GetMute()==1:
                        targetDevice.SetMute(False)
                    else:
                        targetDevice.SetMute(True)

can be reduced to:

Code: Select all

                    targetDevice.SetMute(not targetDevice.GetMute())

There are some small formatting issues also like no spaces around "=" (equal) signs and after "," (comma), that makes it consistent with the rest of the code.

If you want I can make a diff.

These comments are based on a short check I did when you first posted the code, I haven't had a chance to test the code as I don't have 0.5 beta on my development computer.

BTW. I like the XBMC plugin, I'm excited about what you will change!

Thanks, and damn I wasn't supposed to talk about it until it was almost finished, as it will take between 0-100 years the way I code.

jonib

[Sem;colon]

Thank you jonib!

You register to get events from all devices then in the event you discard all but the default, seems unnecessary, so register all devices get all events or register only the default.

You're right, I have just done some cleanup on this.

You have some ".GetMute()==1" that should work like this ".GetMute()" as it returns a Boolean anyway.

.GetMute() returns an integer, not a boolean while .SetMute() needs Boolean. Otherwise I would have never done the "==1" stuff in the first place. But I changed it to this now:

Code: Select all

targetDevice.SetMute(targetDevice.GetMute() == 0)

There are some small formatting issues also like no spaces around "=" (equal) signs and after "," (comma), that makes it consistent with the rest of the code.

If you want I can make a diff.

As you may have noticed, I don't care much about the formatting, it's only cosmetics. ^^ Also the file isn't 100% consistent with this anyway.
I have just done some improvements on my code though.

[jonib]

.GetMute() returns an integer, not a boolean while .SetMute() needs Boolean. Otherwise I would have never done the "==1" stuff in the first place. But I changed it to this now:

Hmm, I think they should both use Boolean so I'll have to look into it, not a big deal anyway.

Edit: The Microsoft documentation shows both uses bool, I'll have to check my code to see whats going on.

As you may have noticed, I don't care much about the formatting, it's only cosmetics. ^^ Also the file isn't 100% consistent with this anyway.

I find it makes the code easier to read, but it's not a high priority.

I have just done some improvements on my code though.

I'll check it when I can.

jonib

[topix]

I did, kinda. I updated my Windows 10 to RS1 some months ago and Windows replaced my Realtek audio driver with one from Microsoft (without asking, of course). I found that out because my EG macros, to switch the default device, stopped working after the update, so yes, the IDs have been changed (maybe the name as well, didn't check that). I then installed the Realtek driver again and the IDs changed again.

Do this problem still exists with the current version of the library? If not, i would like to integrate the plugin into the default setup and completly remove the audio part from the core system plugin. Of course that would break a lot of configurations, but we are moving to a new major EG version, so i personaly think that is something i can live with.

[jonib]

Do this problem still exists with the current version of the library?

The library handles it the same as "vistaVolumeDll" that is used in EventGhost right now, so if a driver changes the device id there is trouble. I will look into if there is a way to identify a device other then the id that is returned by the Windows API, but that is a future(No idea when) project.

If not, i would like to integrate the plugin into the default setup and completly remove the audio part from the core system plugin.

Anything supported by "vistaVolumeDll" can be moved to the AudioEndpointControl library.

Of course that would break a lot of configurations, but we are moving to a new major EG version, so i personaly think that is something i can live with.

The library change don't need to break any configs, only if the implementation is changed.

jonib

[topix]

The library handles it the same as "vistaVolumeDll" that is used in EventGhost right now, so if a driver changes the device id there is trouble.

Ah, didn't know that the problem already existed in the standard audio routines.

The library change don't need to break any configs, only if the implementation is changed.

That's what i meant - remove System/Audio and instead ship EG with AudioEndpoint. So everyone needs to change ther config (for example: System/Audio/Change Master Volume => AudioEndpoint/Set Volume).

[jonib]

Ah, didn't know that the problem already existed in the standard audio routines.

Yup, my library is basically using the same WinAPI functions as the .DLL just directly from python (using comtypes). I'm planning more functionality but right now it's mostly the same features as the .DLL.

That's what i meant - remove System/Audio and instead ship EG with AudioEndpoint. So everyone needs to change ther config (for example: System/Audio/Change Master Volume => AudioEndpoint/Set Volume).

I don't understand, why change the user interface when the underlying code can easily be changed to use my library instead of the .DLL. I believe that's what Sem;colon has been working on, I haven't had a chance to look exactly what modifications hes done.

jonib

[Sem;colon]

I don't understand, why change the user interface when the underlying code can easily be changed to use my library instead of the .DLL. I believe that's what Sem;colon has been working on, I haven't had a chance to look exactly what modifications hes done.

Yes, with my modification of the system plugin, the old commands (in existing configs) will still work. All names and so on are still the same, the events look the same. The only thing that changed, is that settings for specific audio endpoints will be applied to the default audio endpoint instead. So >90% of the EG users will not care/notice any difference.
Only if the user set an action in his/her old config, that changes the volume or mutes/unmutes an audio endpoint, that was not the default playback device, will result in setting the volume or mute/unmute the default playback device instead.
I removed that functionally because of the current stability issues with using it and some other points mentioned in this topic.
People that do need that functionally could use the AudioEndpoint plugin, which is able to do that (but with the known instabilities).
I know that removing a feature is not the best way to solve a problem, but it's the fastest, as it seems to be quite a nut to crack solving it properly... It's not too bad though, as we have a proper workaround for it

I think it's a good approach to switch to the AudioEndpointControl lib, it's already more powerful then vistaVolumeDll and it's python
Functionally can be extended in the future.