TAudioVolume Komponente incl. System Mixer

[TiGü]

Gern!

Kann es sein, dass das Aufrufen der Callback von IAudioSessionNotification abhängig ist vom Treiber?
Der Treiber kann, muss das aber nicht implementieren.
Zumindest sieht das auf den ersten Blick so aus, wenn man sich die Wine-Quelltexte anschaut.

[TiGü]

Siehe Zeile 605:
https://github.com/wine-mirror/wine/...vapi/devenum.c

verweist auf Zeile 55:
https://github.com/wine-mirror/wine/...api/mmdevapi.h

[EWeiss]

Zitat von TiGü:

Siehe Zeile 605:
https://github.com/wine-mirror/wine/...vapi/devenum.c

verweist auf Zeile 55:
https://github.com/wine-mirror/wine/...api/mmdevapi.h

Sorry ich verstehe nicht auf was du hinaus willst.

Wenn ich CoInitializeEx in einem Thread aufrufe dann bekomme ich das Event, ob es jetzt mit deiner Änderung funktioniert muss ich erste noch testen.
Was ich aber weis dass das Event unter Win10 unterschiedlich ist dort soll es funktionieren während es in Win7 nicht gehen soll.

Aber nur vom Hörensagen bestätigt hat mir das noch niemand.
Zumindest hast du mir letztens gesagt das die Events bei dir funktionieren ob es nun am Konsolen Programm lag oder an der Windows Version kann ich nicht mit Bestimmtheit sagen.

Zur zeit verwende ich CoInitializeEx nicht weil Delphi es automatisch aufruft "COINIT_APARTMENTTHREADED"
Delphi pfuscht mir irgendwie dazwischen was das soll keine Ahnung! Ist mir unverständlich.
Kein Sprache Framework soll bestimmen ob ich und wie ich CoInitialize aufrufe das sollte die Anwendung entscheiden nicht das Sprache Framework.

gruss

[TiGü]

Nicht die Sprache, das Framework! Nicht verwechseln!

[EWeiss]

Zitat von TiGü:

Nicht die Sprache, das Framework! Nicht verwechseln!

Korrekt mir ist jetzt nicht der richtige Namen eingefallen
Habe es korrigiert.

gruss

[TiGü]

Zitat von TiGü:

Nicht die Sprache, das Framework! Nicht verwechseln!

Und um genau zu sein in den ersten Zeilen von TApplication.Create.
Da wird OleInitialize aufgerufen, was laut MSDN (https://msdn.microsoft.com/de-de/lib...(v=vs.85).aspx) CoinitializeEx aufruft.

Das ist auch so richtig und wichtig, weil sonst ClipBoard und Drag'n'Drop nicht funktionieren würden.

[EWeiss]

Zitat von TiGü:

Zitat von TiGü:

Nicht die Sprache, das Framework! Nicht verwechseln!

Und um genau zu sein in den ersten Zeilen von TApplication.Create.
Da wird OleInitialize aufgerufen, was laut MSDN (https://msdn.microsoft.com/de-de/lib...(v=vs.85).aspx) CoinitializeEx aufruft.

Das ist auch so richtig und wichtig, weil sonst ClipBoard und Drag'n'Drop nicht funktionieren würden.

OK dann habe ich nichts gesagt.
Das Problem ist nur das ich dann CoUninitialize aufrufen muss damit mein CoInitializeEx überhaupt funktioniert.

Seltsam.. aber OK.

gruss

[TiGü]

Zitat von EWeiss:

Zitat von TiGü:

Siehe Zeile 605:
https://github.com/wine-mirror/wine/...vapi/devenum.c

verweist auf Zeile 55:
https://github.com/wine-mirror/wine/...api/mmdevapi.h

Sorry ich verstehe nicht auf was du hinaus willst.

Ich verstehe das so, dass der Soundtreiber entscheiden kann, ob er diese Funktionalität unterstützt.
Wenn das nicht implementiert ist, dann wird das von der Anwendung implementierte OnSessionCreated nicht aufgerufen.
Zwar wird bei der Anmeldung per RegisterSessionNotification ein S_OK zurückgeliefert, aber der Zeiger auf die Methode nirgends abgespeichert und verwendet.

Werden denn die Methoden von IAudioSessionEvents aufgerufen?

[EWeiss]

Zitat:

Werden denn die Methoden von IAudioSessionEvents aufgerufen?

Ja diese..
SessionStateEvent
SessionVolumeEvent

niemals..
OnAudioSessionDisconnected
OnAudioSessionCreated

OnAudioSessionCreated mit Thread aber Fehler mit PostMessage die neue Version damit noch nicht getestet.

gruss

[TiGü]

Boah, meine Fresse! Darauf muss man erstmal kommen.
Man muss nach Anmeldung der Notifizierung definitiv GetSessionEnumerator aufrufen, dann geht das erst.
Siehe Beispielprojekt im Anhang!

Drauf gekommen bin ich deswegen:

Zitat von Larry Osterman:

The first is that his application hasn't retrieved the current list of sessions. This is one of the really subtle things about the session enumeration APIs. In order to prevent a race condition that can occur when a session notification arrives while the application using the session APIs is starting up, the session enumeration API discards new session notifications until the application has first retrieved the list of existing sessions.

The expected usage pattern is:

Application activates a session manager2. Application registers for session notifications. Application retrieves the current list of sessions for the endpoint and stores the session control objects into a list (don't forget to addref the session).

When a new session is created, the application takes a reference to the newly created session control object and inserts it into the list if it's not already present. Note that the session control object passed into the notification will be destroyed when the session notification returns - if you call GetSessionEnumerator at this point it will probably NOT hold the newly created session (it might, it all depends on timing).

https://stackoverflow.com/a/740241