Library: AudioEndpointControl

[jonib]

This is not an EventGhost plugin, it's not even specific to EventGhost but can be used in plugins. I'm developing a plugin that needed this functionality thats why it's here.

AudioEndpointControl: A library to access and control audio devices (Soundcard speakers/mics) written in Python, no DLLs are needed (at the moment at least) it communicates directly with Windows Core Audio Interfaces.

I'll expand this post with more details later. look at "EndpointExample.py" for example use of the library API, keep the library in its "AudioEndpointControl" directory.
The "EndpointExample.py" example is run outside of EventGhost (You need a Python installation for it to work) for some example uses.

The "EndpointExample.py" is basically the documentation at the moment, I'll try to improve it while I add more functionality.

It should be usable, but there are mostly no error checking and there are probably bugsa galore.

History:
2016-09-01: Second alpha released on GitHub. If used with EventGhost 0.4.* you need 2 extra files MMDeviceAPILib.py and stdole.py from the first alpha.
2016-03-01: Initial alpha release 0.1a1.

[Sem;colon]

Hi Jonib,

thank you very much for sharing!
I just played around with it a bit and it's awesome, I only checked out very little of it's possibilities yet, but it seems to work very well.
I'll change the AudioEndpoint plugin to use that lib instead of the console tools I use right now.

One thing I noticed:
The CMMNotificationClient doesn't raise errors if there are errors in the On..Changed functions. It continues without notifying, that makes debugging more difficult.

[jonib]

thank you very much for sharing!

Well I had nothig better to do with it.

I just played around with it a bit and it's awesome,

Glad you liked it, as I added the event stuff thinking of your plugin, as I will probably not need that in my plugin.

I only checked out very little of it's possibilities yet, but it seems to work very well.
I'll change the AudioEndpoint plugin to use that lib instead of the console tools I use right now.

Now that I know someones going to use it I'll try to make it bullet (hmm bug) proof.

The CMMNotificationClient doesn't raise errors if there are errors in the On..Changed functions. It continues without notifying, that makes debugging more difficult.

I think your choice is using eg.PrintError or Pythons logging to see whats happening. Windows does the events via COM and I don't know if you can get any error reporting from it, but I'll keep it in mind when working on the library.

I'm working on adding some volume related stuff at the moment (I think there is partial code for it in the alpha), unfortunately the functionality I actually wanted I wasn't able to get to work in Python, but I usually get it working after I implement it in a .dll.

jonib

[Sem;colon]

Hi Jonib,
your library has been choosen to replace the basic volume control features in EventGhost!
did you create a new version in the mean time?

[jonib]

your library has been choosen to replace the basic volume control features in EventGhost!

Cool, but the volume functionality is not finished (don't remember exactly whats missing/not finished) or I would have made a new release.

did you create a new version in the mean time?

No new version, haven't worked on it since the last release.

jonib

[jonib]

did you create a new version in the mean time?

So I have created a GitHub repository for this, and I'll try to work on it and hopefully finish the volume control and what else is needed by EventGhost 0.5.

jonib

[blackwind]

Thanks, Joni!

[jonib]

I have moved the development of this library to GitHub and releases will be only there as well.

In v0.1a2 I fixed a problem with Python 3 and added support for volume related events.

jonib

[Sem;colon]

Here is a first version, where VistaVolEvents has been replaced with the AudioEndpointControl library!

At the moment it has the same functionality as before with one exception: You can only change settings for the primary audio device!
I intentionally removed the support to change the volume of other audio devices for these reasons:
- It's difficult to be backwards compatible with the old method of specifying an audio device as parts of the audio device name were used to identify it, nothing that can be reliably or good matched to the new method (but possible, I guess)
- Controlling other audio devices but the default one is not portable and not really stable, with a driver update the Hardware ID and device name may change, resulting in a non-working action. We already have this case that people say "volume control is not working with Windows 10" but that's not true, Microsoft just installs a different driver during the upgrade without asking and since Windows 10 will upgrade itself very frequently, we will see this issue more and more often.

Of cause there should be an option somewhere to control this anyway, but I guess it makes more sense to have this in the AudioEndpoint plugin. Everything related to the default device would then be in the default of EG and everything for other audio devices would be in the AudioEndpoint pugin.

The alternative would be to move the complete functionality of the AudioEndpoint plugin to the System plugin of EG, but the AudioEndpoint plugin creates a lot of events that not every user needs that's why I prefer to separate it (along with the reasons I mentioned above). Also System plugin has actions and configuration dialogues that should be compatible with Windows XP, which uses yet another method to set volume etc. and since AudioEndpointControl is not compatible with Windows XP we would have different features, different actions and so on on Windows XP (don't know how long we should support this system anyway, but currently some people still use it)

What do you mean? What's you opinion on this?

You need to add the AudioEndpointControl library from jonib to the site packages of EG in order for this modification to work.

[jonib]

Here is a first version, where VistaVolEvents has been replaced with the AudioEndpointControl library!

Hi, I was going to look at this, but I'm having big problems with my PC since Sunday, so It will have to wait.

jonib

[Sem;colon]

Hi Jonib,

no problem!
I created a new version (attached)
The old one didn't unregister...

btw. Something I didn't mention last time: You need to use the latest files for the AudioEndpointControl Lib (not the released ones) and EG 0.5 beta 4!

EDIT: I noticed the version I uploaded was buggy, so I just replaced it... Sorry for this

[Sem;colon]

At the moment it has the same functionality as before with one exception: You can only change settings for the primary audio device!
I intentionally removed the support to change the volume of other audio devices for these reasons:
- It's difficult to be backwards compatible with the old method of specifying an audio device as parts of the audio device name were used to identify it, nothing that can be reliably or good matched to the new method (but possible, I guess)
- Controlling other audio devices but the default one is not portable and not really stable, with a driver update the Hardware ID and device name may change, resulting in a non-working action. We already have this case that people say "volume control is not working with Windows 10" but that's not true, Microsoft just installs a different driver during the upgrade without asking and since Windows 10 will upgrade itself very frequently, we will see this issue more and more often.

So, everyone is happy with this??

[jonib]

Sem;colon I think you need to link or create a new thread about this so other interested people can give feedback, most wont look in this thread about a audio lib that they are not interested in.

I haven't used the audio functionality in EventGhost so my opinion might not be useful.

At the moment it has the same functionality as before with one exception: You can only change settings for the primary audio device!
I intentionally removed the support to change the volume of other audio devices for these reasons:

I don't like this it should have at least the same functionality as the old code.

- It's difficult to be backwards compatible with the old method of specifying an audio device as parts of the audio device name were used to identify it, nothing that can be reliably or good matched to the new method (but possible, I guess)

Is there some information missing in the audio library? I think all info that the old method should be availible.

- Controlling other audio devices but the default one is not portable and not really stable, with a driver update the Hardware ID and device name may change, resulting in a non-working action. We already have this case that people say "volume control is not working with Windows 10" but that's not true, Microsoft just installs a different driver during the upgrade without asking and since Windows 10 will upgrade itself very frequently, we will see this issue more and more often.

If the driver changes the device name just print an error that tells the user to check the settings.
You can't just remove functionality because it might not work all the time without adjustment.

Of cause there should be an option somewhere to control this anyway, but I guess it makes more sense to have this in the AudioEndpoint plugin. Everything related to the default device would then be in the default of EG and everything for other audio devices would be in the AudioEndpoint pugin.

More advanced functions/control could be in AudioEndpoint plugin, to keep the system one simpler.

The alternative would be to move the complete functionality of the AudioEndpoint plugin to the System plugin of EG, but the AudioEndpoint plugin creates a lot of events that not every user needs that's why I prefer to separate it (along with the reasons I mentioned above).

A redesign could be relevant at some point maybe when XP is not supported anymore. If extra events is a problem there could always be options to disable them.

jonib

[Sem;colon]

Sem;colon I think you need to link or create a new thread about this so other interested people can give feedback, most wont look in this thread about a audio lib that they are not interested in.

hmm, yes, I guess that's a good idea, I'll do that.

I don't like this it should have at least the same functionality as the old code.

I usually agree, that's why I'm asking. Anyway, it would improve the stability to leave it out, that's why I would kinda prefer it in this case.

Is there some information missing in the audio library? I think all info that the old method should be available.

No, it wouldn't say something is missing. You need to know that the design how it at the moment saves the name (not an ID or anything) of the audio device as string and uses this name to identify the audio adapter. If the name changes (via driver update) or if you have two adapter with the same name, your configuration stops working or doesn't work as intended. I could create a function that does some mapping of names to IDs but it's all very dirty. The cleanest way would be, in my opinion, to start all over using IDs, but this brakes backwards compatibility. Using the dirty helper function I mentioned could preserve compatibility, but we end up with some actions in the EG tree use the ID, some use the name - the name changes, one method brakes, the ID changes the other brakes, it's not reliable and leading to frustration for the user.

If the driver changes the device name just print an error that tells the user to check the settings.
You can't just remove functionality because it might not work all the time without adjustment.

I don't want to remove any functionality, but I would prefer to shift it from the core into a plugin, that's all. I'd prefer that from a support perspective. The user would blame the plugin for the error and not EventGhost in total. I'd like to see the core of EG rock solid.

A redesign could be relevant at some point maybe when XP is not supported anymore. If extra events is a problem there could always be options to disable them.

True, but that's a bigger design change, where should the option be to deactivate events from the EG core features? We don't have a place for this in the GUI right now.

Thank you for the feedback!!

[topix]

You need to know that the design how it at the moment saves the name (not an ID or anything) of the audio device as string and uses this name to identify the audio adapter. If the name changes (via driver update) or if you have two adapter with the same name, your configuration stops working or doesn't work as intended. I could create a function that does some mapping of names to IDs but it's all very dirty. The cleanest way would be, in my opinion, to start all over using IDs, but this brakes backwards compatibility. Using the dirty helper function I mentioned could preserve compatibility, but we end up with some actions in the EG tree use the ID, some use the name - the name changes, one method brakes, the ID changes the other brakes, it's not reliable and leading to frustration for the user.

I have no knowledge of programming audio hardware, but won't they have some hardware ids that could be used to detect them.(Just something that came to my mind.)

For me it would be ok to have braking functions in EG 0.5.0.