-
Notifications
You must be signed in to change notification settings - Fork 67
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
AudioSessionEvents is receiving multiple events for a single real event after refreshing the audio sessions list. #99
Comments
Thanks for the detailed bug report @TJ-59 |
It seems it is linked to the sub-components of the session object getting their own reference to the session. On a similar note, please have a look at this bit of code : Test
I don't know why it does that, but it looks like it is clearly the "amount" multiplied by itself. |
I'm using pycaw to watch sound volume changes, I have a
AudioSessionCallback
class that inherit pycaw'sAudioSessionEvents
, and is given to the session viaregister_notification()
.The callback instance has a few attributes added, like the ID of the corresponding UI, the session instance identifier, AND a pseudo unique ID (generated at
__init__
) just to be able to differentiate "who" is receiving the events.This was done after seeing multiple instances of the prints happening for a single event (like, "one single click in the windows audio mixer to change that session's volume" single event).
The sessions are obtained with
AudioUtilities.GetAllSessions()
, each is given to a custom UI panel instance, and depending on the process the session is from, may or may not have a callback created and registered to it.The registration is done (in the UI panel code) with :
This
register_notification()
, defined in picaw/utils.py 'sAudioSession
class, internally uses :Same for the
unregister_notification()
, done with this code :which is defined just after in utils.py :
For various reasons, the user may need to refresh the sessions, when that happens, the callbacks are all removed using the code above, the ui panels are removed and destroyed, and then, the same process, used initially to get the sessions and give each of them a panel, is used again to obtain one panel per session.
But when an event happens, like a volume change, there are now multiple prints happening, all from events very close to each other temporally, but ALL are printed by the NEW callback for that session, proof being the pseudo unique ID it generated during its
__init__
being the same for all events.I'd have understood, if the pseudo unique IDs were different, that the event is still getting picked up by old callbacks that would somehow not be correctly unregistered, but those are all received by the current callback, like "something above it" was counting "how many copies of the single event they're supposed to send out", not caring who's concerned or receiving it.
Any idea how to avoid being spammed by duplicate events ?
The text was updated successfully, but these errors were encountered: