0

I'm currently working on audio sessions. Let's say I have an audio session which was obtained by enumerating all sessions with GetSessionEnumerator and GetSession. It is possible to register notifications to know when the sessions had its volume changed, state changed, ... with RegisterAudioSessionNotification.

However, I didn't find how to know when the session has been removed. According to the doc, there is no session expiration mecanism provided by the API.

With that information in mind, there are two behaviours I do not understand:

  1. In windows' volume mixer (sndvol), when you terminate an application producing sound, the icon and volume slider associated with it disappears from the list. How does sndvol know this since there is no expiration mecanism?

  2. Here's a scenario:

a. you have n audio sessions active

b. you enumerate these sessions and listen for new ones

c. you launch an app producing sound, the session created notification fires up, you now have n+1 sessions in your list

d. you terminate the app. You still have n+1 notifications since there is no expiration mecanism

e. What I don't understand: If you re-enumerate audio sessions, you will get n sessions. How come the extra session of the terminated app is still working if it's not event in the list when you re-enumerate? Moreover, why did it disappear from the list?

Does anyone have any information? I've been searching for weeks, without results!

Thank you very much!

Edit: So I've studied sndvol a bit, and found an interesting interface: {604e2ae7-c4c5-4032-93ff-88b26cdd75b8} which sndvol queries to every session from IAudioSessionControl. Appaently this is a private interface without documentation. Interesting thing: if that query fails, the session is not shown in sndvol! This seems to be confirmed here

I couldn't find any more info on that interface.

jojolepirate
  • 51
  • 4
  • I can't comment on your exact scenario as I don't have an answer (and hence the comment) but I can give you one possible idea/avenue to explore. When you use a DLL the windows subsystem increments a reference count the more apps that use the exports in that DLL the higher this count is, when an app exits the OS decrements the count and when the last instance exits and the count hits 0 the OS physically unloads the DLL from memory. Meanwhile windows itself tries to re-use resource handles where ever it can, so a handle opened in a DLL may remain open for the lifetime of the DLL being loaded – shawty Jan 08 '15 at 23:20
  • Hence. Anything monitoring the reference count (such as sndvol) would notice an app invocation releasing the DLL, so will adjust accordingly, however anything looking at things from a resource point of view may falsely believe that a handle remaining in existence signify s that event/resource is still operational and so lists it when asked for a report. Don't know if that applies exactly to what your doing, but If I where looking at this problem I'd certainly use it as food for thought. – shawty Jan 08 '15 at 23:23

0 Answers0