Filter driver for surround support

[DirkoAudio]

Hey Etienne.
Do you think support for mono/stereo/quadraphonic/5.1/7.1 could be added to any sound device by developing some filter driver ?
This is actually an idea for development.
I've seen something quite similar, like, if you manually force install (the .inf files) from Logitech Gaming Software audio drivers (the old LGS) or even the current iCue audio drivers on most USB audio devices - it works and add 7.1 support - so you can change between stereo or 7.1 on the "Configure" button in windows sound control panel.
Why this is interesting? Because it would be extremely useful for the Hesuvi project.
Instead of using virtual audio devices, you would only have to install some filter driver on top of your current sound device.
Feel free to correct me on anything I said.

[dechamps]

Hello,

I'm assuming that by "support for mono/stereo/quadraphonic/5.1/7.1" you are referring to custom signal processing for downmixing/upmixing.

I think it should be theoretically possible to do this using a filter driver placed on top of the usual audio driver. I'm not sure about the specifics though because I'm not familiar with the details of how actual audio streaming works at the KS level.

I really don't think it would be easy, though. You'll likely need to do complex stateful interception of KS calls which, again, is technically feasible, but quite challenging. KS graphs can look very different depending on the underlying driver, as can easily be seen by using KsStudio on various devices.

Then you'd need to intercept the audio buffers themselves, which I suspect is also not easy. And the interfaces involved are not very well-documented because developers are not really supposed to be dealing with KS IOCTLs directly - they're supposed to use friendlier "glue layer code" such as PortCls, but (AFAIK) these can only be used in device drivers, not filter drivers.

To add insult to injury, my (limited) understanding is that audio drivers can implement any of 3 audio buffer management modes that the Windows audio engine supports (WaveCyclic, WavePci and WaveRT). An audio-buffer-intercepting filter driver that wants to support any underlying audio driver will need to support all 3 of them to achieve wide compatibility. This potentially means complex buffer-wrangling code will have to be written in 3 different ways - that's a lot of work. That also comes with challenges related to testing - unless you have many different kinds of audio drivers at your disposal, it will be difficult to ensure things don't break randomly on your user's hardware.

So I guess my conclusion is: yes it's feasible, but I suspect writing such a filter driver would be extremely challenging and time-consuming, especially if you want it to work reliably across many hardware configurations. Don't quote me on this though - again, I have not looked at the specifics closely.