eiz / SynchronousAudioRouter

Low latency application audio routing for Windows
http://sar.audio/
GNU General Public License v3.0
1.04k stars 138 forks source link

Is SAR still not workable with chromium audio sandbox :? #121

Open neKmaI opened 3 years ago

neKmaI commented 3 years ago

I know we can turn audio sanbox off, but as I know, turn that off mean put you in a vulnerable position ( the vulnerability called CVE-2019-13720 ) :((((

amurzeau commented 3 years ago

I didn't reproduced the problem, but I've retested it, I still cannot reproduce that issue with chrome 92. Maybe you can debug the problem so I can implement the required fix to help others ?

I use this:

I you play something else using a different player and while it is playing, try to:

neKmaI commented 3 years ago

I didn't reproduced the problem, but I've retested it, I still cannot reproduce that issue with chrome 92. Maybe you can debug the problem so I can implement the required fix to help others ?

I use this:

  • Latest build (https://github.com/eiz/SynchronousAudioRouter/releases/tag/v0.13.2)
  • Secure boot disabled
  • Test signing enabled
  • SAR is allowed for all users (check this in the installer, be sure to select Allow any user to access SAR. More user friendly, but somewhat less secure.)
  • SAR is started at boot and never stopped until shutdown (I use jackd which I never stop)

I you play something else using a different player and while it is playing, try to:

  • Start chrome
  • Play something in chrome Does it work fine ? or only the first player audio is there but not chrome's audio ?

I don't know how to debug the problem for you, can you show me how :? Thanks you <3

eiz commented 3 years ago

The way SAR is designed is largely obsolete. I can talk about this now: if you want to solve this problem, look in the 10.0.22000 Windows SDK headers um\audioclientactivationparams.h for VIRTUAL_AUDIO_DEVICE_PROCESS_LOOPBACK and knock yourself out =)

The likely proximate cause here is that the Chrome audio sandbox uses SetProcessMitigationPolicy to prevent arbitrary DLL loads in its process, which will break the SAR mmdevice wrapper functionality that overrides default audio endpoints.

amurzeau commented 3 years ago

The likely proximate cause here is that the Chrome audio sandbox uses SetProcessMitigationPolicy to prevent arbitrary DLL loads in its process, which will break the SAR mmdevice wrapper functionality that overrides default audio endpoints.

In that case, maybe this can help:

This disables the signature check for APOs, so that unsigned APOs will be loaded. This also means that applications requiring a secure audio path may change their behaviour or refuse to output audio altogether.

(source: https://sourceforge.net/p/equalizerapo/wiki/Developer%20documentation/)

amurzeau commented 3 years ago

Let's keep this issue focused; I've created a new issue about Windows 10.0.22000 and VIRTUAL_AUDIO_DEVICE_PROCESS_LOOPBACK here https://github.com/eiz/SynchronousAudioRouter/issues/122.