Disable obsolete audio APIs on Windows
Purpose and Motivation
WASAPI should be the default non-ASIO option on Windows. This PR removes MME, DirectSound, and WDM-KS APIs from the Windows build.
Are we ready to do this? Is there any benefit for using the obsolete APIs on Windows?
I also updated the docs, including a note on WASAPI resampling that reflects the change in #6899.
Types of changes
- Documentation
- Bug fix (if counting using MME as the default device as a bug...)
- New feature (as in - less superfluous posting when booting the server)
- Breaking change (if someone was explicitly using a MME/DS/WDM-KS device)
To-do list
- [x] Code is tested
- [ ] All tests are passing
- [x] Updated documentation
- [ ] This PR is ready for review
@Spacechild1 should we do this?
@prko @sternsc @jrsurge would you be able to test the build from this PR (server booting, making sound) on your Windows systems?
On Windows 11 arm64 (on virtual machine 1 via Parallels Desktop on macOS 14.6.7 m1max): an unsuccesful case
This virtual machine is my main Windows machine.
Booting server 'localhost' on address 127.0.0.1:57110.
Device options:
- ASIO : Magix Low Latency 2016 (device #0 with 2 ins 8 outs)
- ASIO : ReaRoute ASIO (x64) (device #1 with 16 ins 16 outs)
- Windows WASAPI : Speakers (High Definition Audio Device) (device #2 with 0 ins 2 outs)
- Windows WASAPI : Microphone (High Definition Audio Device) (device #3 with 2 ins 0 outs)
Requested devices:
In:
- (default)
Out:
- (default)
Selecting default system input/output devices
Booting with:
In: ASIO : Magix Low Latency 2016
Out: ASIO : Magix Low Latency 2016
Server 'localhost' exited with exit code -1073741819.
On Windows 11 arm64 (on virtual machine 2 via Parallels Desktop on macOS 14.6.7 m1max): a successful case
This virtual machine is my test machine, and only SC3.8.1, 3.9.3, 3.10.4, 3.11.2, 3.12.2, and 3.13.0. are installed
Booting server 'localhost' on address 127.0.0.1:57110.
Server: possible boot delay.
On some Windows-based machines, Windows Defender sometimes delays server boot by one minute.
You can add scsynth.exe and/or supernova.exe *processes* to Windows Defender exclusion list to avoid this delay. It's safe.
Device options:
- Windows WASAPI : Speakers(High Definition Audio Device) (device #0 with 0 ins 2 outs)
- Windows WASAPI : Microphone(High Definition Audio Device) (device #1 with 2 ins 0 outs)
Requested devices:
In:
- (default)
Out:
- (default)
Selecting default system input/output devices
Booting with:
In: Windows WASAPI : Microphone(High Definition Audio Device)
Out: Windows WASAPI : Speakers(High Definition Audio Device)
Sample rate: 48000.000
Latency (in/out): 0.022 / 0.024 sec
SC_AudioDriver: sample rate = 48000.000000, driver's block size = 64
SuperCollider 3 server ready.
Requested notification messages from server 'localhost'
localhost: server process's maxLogins (1) matches with my options.
localhost: keeping clientID (0) as confirmed by server process.
Shared memory server interface initialized
On Windows 10 arm64 (on virtual machine 2 via Parallels Desktop on macOS 14.6.7 m1max): a successful case
This virtual machine is my test machine, and I launch developer versions of SC.
Booting server 'localhost' on address 127.0.0.1:57110.
Device options:
- Windows WASAPI : Speakers(High Definition Audio Device) (device #0 with 0 ins 2 outs)
- Windows WASAPI : Microphone(High Definition Audio Device) (device #1 with 2 ins 0 outs)
Requested devices:
In:
- (default)
Out:
- (default)
Selecting default system input/output devices
Booting with:
In: Windows WASAPI : Microphone(High Definition Audio Device)
Out: Windows WASAPI : Speakers(High Definition Audio Device)
Sample rate: 48000.000
Latency (in/out): 0.022 / 0.024 sec
SC_AudioDriver: sample rate = 48000.000000, driver's block size = 64
SuperCollider 3 server ready.
Requested notification messages from server 'localhost'
localhost: server process's maxLogins (1) matches with my options.
localhost: keeping clientID (0) as confirmed by server process.
Shared memory server interface initialized
Here is a test on a real machine:
Unsuccessful with default device option value:
Booting server 'localhost' on address 127.0.0.1:57110.
Device options:
- ASIO : Steinberg built-in ASIO Driver (device #0 with 4 ins 2 outs)
- Windows WASAPI : Speakers(Realtek(R) Audio) (device #1 with 0 ins 2 outs)
- Windows WASAPI : LG HDR 4K(HD Audio Driver for Display Audio) (device #2 with 0 ins 2 outs)
- Windows WASAPI : Microphone Array(디지털 마이크용 인텔® 스마트 사운드 기술) (device #3 with 4 ins 0 outs)
Requested devices:
In:
- (default)
Out:
- (default)
Selecting default system input/output devices
Booting with:
In: ASIO : Steinberg built-in ASIO Driver
Out: ASIO : Steinberg built-in ASIO Driver
Server 'localhost' exited with exit code -1073741819.
Successful with device option value change:
(
s.options.outDevice= "Windows WASAPI : Speakers(Realtek(R) Audio)";
s.options.inDevice= "Windows WASAPI : Microphone Array(디지털 마이크용 인텔® 스마트 사운드 기술)";
s.boot
)
returns
-> localhost
Booting server 'localhost' on address 127.0.0.1:57110.
Device options:
- ASIO : Steinberg built-in ASIO Driver (device #0 with 4 ins 2 outs)
- Windows WASAPI : Speakers(Realtek(R) Audio) (device #1 with 0 ins 2 outs)
- Windows WASAPI : LG HDR 4K(HD Audio Driver for Display Audio) (device #2 with 0 ins 2 outs)
- Windows WASAPI : Microphone Array(디지털 마이크용 인텔® 스마트 사운드 기술) (device #3 with 4 ins 0 outs)
Requested devices:
In (matching device found):
- Windows WASAPI : Microphone Array(디지털 마이크용 인텔® 스마트 사운드 기술)
Out (matching device found):
- Windows WASAPI : Speakers(Realtek(R) Audio)
Booting with:
In: Windows WASAPI : Microphone Array(디지털 마이크용 인텔® 스마트 사운드 기술)
Out: Windows WASAPI : Speakers(Realtek(R) Audio)
Sample rate: 48000.000
Latency (in/out): 0.022 / 0.023 sec
SC_AudioDriver: sample rate = 48000.000000, driver's block size = 64
SuperCollider 3 server ready.
Requested notification messages from server 'localhost'
localhost: server process's maxLogins (1) matches with my options.
localhost: keeping clientID (0) as confirmed by server process.
Shared memory server interface initialized
server 'localhost' disconnected shared memory interface
Shared memory server interface initialized
If a software ASIO driver is installed and it is the first driver, the SC server does not successfully boot. Tomorrow, I can do one more test on a real Windows machine (no input device, but there is an output device; Windows 10. I do not know whether a software ASIO driver is installed on that machine,)
Thanks @prko for testing! This is very informative. No need for further tests for now.
It seems that PortAudio does not treat WASAPI as the default API, unfortunately. We'd need to rework the default selection to make this work. I'll mark this PR as a draft for now.
Could such a code be used in a class definition which can be called when the server boots?
(
aMethod { Platform.case(
\osx, {
var devices = ServerOptions.devices;
s/*should be changed*/.options.inDevice = devices.select { |item| item.contains("Windows WASAPI") && item.contains("Microphone") };
s/*should be changed*/.options.outDevice = devices.select { |item| item.contains("Windows WASAPI") && item.contains("Speaker") }
}
)
}
)
That's a possible workaround, but not a proper solution. The backend code (inside the server) should choose the default device starting with WASAPI. We depend on PortAudio for that, but PortAudio doesn't seem to treat WASAPI as the default API. Thanks for sending the suggestion!
This PR removes MME, DirectSound, and WDM-KS APIs
I would agree with this. Actually, we did the same for Pd just recently.
If a software ASIO driver is installed and it is the first driver, the SC server does not successfully boot.
We have a similar issue in Pd: https://github.com/pure-data/pure-data/issues/2578
In both cases we need to explicitly tell portaudio that we want WASAPI as the default backend.
In both cases we need to explicitly tell portaudio that we want WASAPI as the default backend.
But is it possible? Aside from manually enumerating devices?
For those using old or unusual devices, losing MME support could be disabling. For instance, I have an input-only electroglottograph for which the drivers support only MME and WDM. Admittedly, it's very niche, and at some point one must move on. But maybe we could keep only MME as a fallback? If not, I'll see if I can get the device in question to work via ASIO4ALL.
For instance, I have an input-only electroglottograph for which the drivers support only MME and WDM.
If it works with MME or WDM, then it should also work with WASAPI. Have you actually tried?
Ah, I didn’t know that. Thanks, I will check on Monday and get back.
From: Christof Ressi @.> Sent: Thursday, 5 June 2025 22:53 To: supercollider/supercollider @.> Cc: sternsc @.>; Mention @.> Subject: Re: [supercollider/supercollider] Disable obsolete audio APIs on Windows (PR #6900)
[Image removed by sender.]Spacechild1 left a comment (supercollider/supercollider#6900)https://github.com/supercollider/supercollider/pull/6900#issuecomment-2946198439
For instance, I have an input-only electroglottograph for which the drivers support only MME and WDM.
If it works with MME or WDM, then it should also work with WASAPI. Have you actually tried?
— Reply to this email directly, view it on GitHubhttps://github.com/supercollider/supercollider/pull/6900#issuecomment-2946198439, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AAXQZNEYZ4HBNOZP6ZRH4IL3CCU4NAVCNFSM6AAAAAB57G5VUWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDSNBWGE4TQNBTHE. You are receiving this because you were mentioned.Message ID: @.***>
Now I have tried. You’re right, it works also with WASAPI. Thanks.
From: Christof Ressi @.> Sent: Thursday, 5 June 2025 22:53 To: supercollider/supercollider @.> Cc: sternsc @.>; Mention @.> Subject: Re: [supercollider/supercollider] Disable obsolete audio APIs on Windows (PR #6900)
[Image removed by sender.]Spacechild1 left a comment (supercollider/supercollider#6900)https://github.com/supercollider/supercollider/pull/6900#issuecomment-2946198439
For instance, I have an input-only electroglottograph for which the drivers support only MME and WDM.
If it works with MME or WDM, then it should also work with WASAPI. Have you actually tried?
— Reply to this email directly, view it on GitHubhttps://github.com/supercollider/supercollider/pull/6900#issuecomment-2946198439, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AAXQZNEYZ4HBNOZP6ZRH4IL3CCU4NAVCNFSM6AAAAAB57G5VUWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDSNBWGE4TQNBTHE. You are receiving this because you were mentioned.Message ID: @.***>
@sternsc Thanks for confirming!
Together with https://github.com/supercollider/supercollider/pull/6994, this looks good to me. We get rid of all these legacy backends and also have a decent default (= WASAPI).
Now that we have switched to choosing WASAPI devices by default, this PR can proceed.
However, I would like wait a little after releasing 3.14, which should give us heads up in case people have any major problems with WASAPI. If not, let's consider this PR sometime in August 2025.
A few weeks have passed since SC 3.14 was released, using WASAPI devices by default, and I don't believe we have had reports of major issues because of that.
To double check, @sternsc would you be able to try a build from this PR again with your system/devices to make sure there are no issues?
@prko can you also test on actual Windows machine (not VM)?
Thanks!
Of course! Here’s a test result on a real Windows 11 machine.
compiling class library...
Found 874 primitives.
Compiling directory 'C:\Users\prahm\Dropbox\prahms\Downloads\SuperCollider\SCClassLibrary'
Compiling directory 'C:\ProgramData\SuperCollider\Extensions'
Compiling directory 'C:\Users\prahm\AppData\Local\SuperCollider\Extensions'
numentries = 854521 / 12809698 = 0.067
5653 method selectors, 2266 classes
method table size 13660944 bytes, big table size 102477584
Number of Symbols 12660
Byte Code Size 389090
compiled 332 files in 0.41 seconds
Info: 2 methods are currently overwritten by extensions. To see which, execute:
MethodOverride.printAll
compile done
localhost : setting clientID to 0.
internal : setting clientID to 0.
Class tree inited in 0.41 seconds
*** Welcome to SuperCollider 3.15.0-dev. *** For help press Ctrl-D.
file "C:\Users\prahm\AppData\Local\SuperCollider\Help\scdoc_version" does not exist.
SCDoc: refresh static files
SCDoc: Indexing help-files...
SCDoc: Indexed 1382 documents in 1.46 seconds
SCDoc: Indexing help-files...
SCDoc: Indexed 1382 documents in 0.92 seconds
Booting server 'localhost' on address 127.0.0.1:57110.
Device options:
- ASIO : Steinberg built-in ASIO Driver
(4 ins, 2 outs)
- Windows WASAPI : Speakers(Realtek(R) Audio)
(0 ins, 2 outs)
- Windows WASAPI : LG HDR 4K(HD Audio Driver for Display Audio)
(0 ins, 2 outs)
- Windows WASAPI : Microphone Array(디지털 마이크용 인텔® 스마트 사운드 기술)
(4 ins, 0 outs)
Requested devices:
In:
- (default)
Out:
- (default)
Selecting default system input/output devices
Booting with:
In: Windows WASAPI : Microphone Array(디지털 마이크용 인텔® 스마트 사운드 기술)
Out: Windows WASAPI : LG HDR 4K(HD Audio Driver for Display Audio)
Sample rate: 48000.000
Latency (in/out): 0.022 / 0.023 sec
SC_AudioDriver: sample rate = 48000.000000, driver's block size = 64
SuperCollider 3 server ready.
Requested notification messages from server 'localhost'
localhost: server process's maxLogins (1) matches with my options.
localhost: keeping clientID (0) as confirmed by server process.
Shared memory server interface initialized
"To double check, @sternsc would you be able to try a build from this PR again with your system/devices to make sure there are no issues?"
Tested this SC 3.15.0-dev on Windows 11 Pro version 24H2, with a USB WASAPI inDevice and a separate USB WASAPI outDevice, all seems to be working. Only ASIO and WASAPI devices are listed in the Post window upon booting the server.
Thank you for testing @prko and @sternsc !
@Spacechild1 should we go ahead and merge this?
Everything good from my side!
I'll merge this. If any issues with the WASAPI backend arise, we can address them as they come.