On Wed Sep 27 20:15:02 2023 +0000, Rémi Bernon wrote:
I believe Init is a lower-level operation mode, and they added the audio paths later to abstract some details and avoid having to manually manage ports. This means that the newer method doesn't provide more flexibility here, but instead, less. When audio paths are used, it is still possible to use PChannelInfo to query performance channels / port association. Hence, my understanding is that InitAudio still uses the performance the old way (and like it is implemented), but it handles the port allocation for the audio paths, and forbid the caller from messing with them. With this in mind, I believe that InitAudio should call Init, and then adds some logic on top, not the other way around. I'll have a look at the comments, see what you mean, and hopefully clarify them.
Yes and no. It isn't just an abstraction layer on top of the ports.\ They have extended IDirectMusicSynth to support the AudioPaths. So that could do more than what the old performance could achieve.\ Only issue is that the information is actively erased from the public documentation.\ https://learn.microsoft.com/en-us/windows/win32/api/dmusics/nn-dmusics-idire... \ I remember to have seen AudioPath explicitly mentioned on the Synth8 methods.
Interesting would be to test if one has to pass DMUS_PORT_FEATURE_AUDIOPATH to IDirectMusic_CreatePort() for the port to support AudioPaths.
Anyway all that shouldn't block InitAudio() using Init(). The differences can be then handled by the presence of audio_paths_enabled boolean.