Skip to content
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

Session enumeration/meter support #31

Open
millardjn opened this issue May 21, 2024 · 1 comment
Open

Session enumeration/meter support #31

millardjn opened this issue May 21, 2024 · 1 comment

Comments

@millardjn
Copy link
Contributor

Hi Henrik,

I'd like to be able to list out all processes currently outputting audio. It looks like the best way to do this is to access the IAudioSessionManager2 and IAudioSessionEnumerator for each device. I'd also like to check session activity so IAudioSessionControl2 and IAudioMeterInformation would be of interest as well. Taking pseduo code from Matthew van Eerde:

CoCreate(IMMDeviceEnumerator);
IMMDeviceEnumerator::GetDefaultAudioEndpoint;
IMMDevice::Activate(IAudioSessionManager2);
IAudioSessionManager2::GetSessionEnumerator;
for (each session) {
    IAudioSessionEnumerator::GetSession
    IAudioSessionControl::GetState
    #if the state is anything but "active", skip to the next session
    QI IAudioSessionControl to IAudioSessionControl2
    IAudioSessionControl2::GetSessionIdentifier
    QI IAudioSessionControl to IAudioMeterInformation
    IAudioMeterInformation::GetPeakValue
    #Log the session identifier and the peak value
}

I think keeping related interfaces (e.g. IAudioSessionManager and IAudioSessionManager2) separate helps from the point of view of sticking to the existing API, and cleaner handling cases where only one can instantiated (don't quite understand when/if that can happen). If that can be reliably combined though it would be quite nice. Do you know why so many of them are separated?

I'm happy to try implementing this in a few stages, but I wanted to check in first.

@HEnquist
Copy link
Owner

I don't know why the windows api is divided into so many little bits, but I would guess it's to keep backward compatibility since the apis have been expanded many times over the years.

I would be happy to accept a PR for this. I prefer to stay close to the windows apis and keep the separate things separate, this keeps things simple and it's easy to refer to the Microsoft docs for each separate IAudioSessionControlX etc.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants