Это на тонну больше работы, чем нужно.
Вам просто нужно написать класс, производный от IAudioSessionNotifications - вам не нужно фактически писать целый COM-объект и регистрировать его.
Вы также должны использовать роль eConsole вместо роли eMultimedia. Это не имеет значения (если у вас есть только одно аудиоустройство), но это более правильно.
Деструктор для класса CustomAudioNotification должен быть закрытым - таким образом вы предотвратите случайное уничтожение. Поэтому я бы написал:
CustomAudioNotification
*customNotification = new CustomAudioNotification();
SESSION->RegisterSessionNotification(customNotification);
Я также предполагаю, что вы инициализировали COM перед своим фрагментом кода.
ОБНОВЛЕНО: Кевин прислал мне свое приложение, и есть несколько других проблем с его приложением, которые являются более фундаментальными (я работаю над улучшением документации для API, чтобы избежать путаницы в будущем)
Во-первых, его приложение не получило текущий список сеансов. Это одна из самых тонких вещей в API перечисления сеансов. Чтобы предотвратить состояние гонки, которое может возникнуть при получении уведомления о сеансе, когда приложение, использующее API сеанса, запускается, API перечисления сеанса отбрасывает уведомления о новых сеансах, пока приложение сначала не получит список существующих сеансов.
Ожидаемая схема использования:
Приложение активирует менеджер сессий2.
Приложение регистрируется для сеансовых уведомлений.
Приложение извлекает текущий список сеансов для конечной точки и сохраняет объекты управления сеансами в список (не забудьте добавить сеанс заново).
Когда создается новый сеанс, приложение берет ссылку на вновь созданный объект управления сеансом и вставляет его в список, если он еще не существует. Обратите внимание, что объект управления сеансом, переданный в уведомление, будет уничтожен при возврате уведомления сеанса - если вы вызовете GetSessionEnumerator в этот момент, он, вероятно, НЕ будет содержать вновь созданный сеанс (возможно, все зависит от времени).
Приложение управляет временем жизни сеанса на основе своих собственных критериев - пока приложение имеет ссылку на управление сеансом, объект управления сеансом будет действительным. Для объектов управления аудиосеансом не существует механизма истечения срока действия.
Кроме того, API сеанса требуют инициализации MTA - это прискорбно, но поскольку мы создаем COM-объекты (которые реализуют IAudioSessionControl) в рабочем потоке, API требует, чтобы MTA был создан до получения уведомления.