SuperCollider on Windows: ASIO Buffer Size Mismatch with Audio Interface

Questions
1

Hey everyone,
I’m using SuperCollider on Windows and I want to set it to use my audio interface instead of the default MME driver. I was able to do this with the following code:

(
s.options.sampleRate = 48000;
s.options.blockSize = 256;
s.options.inDevice_("Audient USB Audio ASIO Driver");
s.options.outDevice_("Audient USB Audio ASIO Driver");
)

It seems to work, and the post window shows:

SC_AudioDriver: sample rate = 48000.000000, driver's block size = 256

However, the issue is that my interface actually switches to a buffer size of 512.
If I stop the server and set the block size to 512 in SuperCollider, then my interface switches to 1024.

So, there seems to be a mismatch between the buffer size set in SuperCollider and what my interface ends up using. Any ideas on how to properly sync them?

2

I tried switching from my Audient interface to ASIO4ALL to see if the behavior was different, but I’m experiencing the same issue. Here’s what I discovered:

  • If I don’t specify a sample rate at all, SuperCollider defaults to 44100 (as mentioned in the help files), and the buffer size in my audio interface/ASIO4ALL does not change.

  • However, if I explicitly set the sample rate to 48000, the buffer size in the interface/ASIO4ALL does change, but it still doubles (e.g., SC blockSize 256 → interface uses 512).

This suggests the sample rate setting somehow triggers the interface to adjust its buffer size, but the scaling mismatch persists. Still unsure why the blockSize is being doubled. Could this be a driver-level latency adjustment or a SuperCollider quirk with certain ASIO devices?

3

Ah, I missed it at first.

blockSize is not the hardware buffer size. It’s the SC internal control rate divider. Normally you don’t want this any larger than 64 because you’ll lose time resolution on any kr signals.

The hardware buffer size is hardwareBufferSize.

hjh

1 Like
4

I totally missed this! James is right. The option you are looking for is hardwareBufferSize.

1 Like
5

Oh i see! Well i was not aware of that since on my linux machine it’s s just a matter of starting jack with my default 48k sample rate and 512 buffersize and when i boot the server in SC it syncs. As you better know, on windows you need to specify ASIO otherwise it will default to MME. Whats interesting though is: why does SC changes the hardware buffer size of my interface (in this case Audient) when i set the sample rate (in SC) to 48k and not when i dont specify it?

6

I don’t have a precise answer as I’m not a Windows user and have less experience with the peculiarities of Windows audio, but – a quick look at the source code shows a block that reads, basically, “if either an input or an output device has been specified, then – if the user specified a hardware buffer size, try to use that; otherwise, ask the in and out devices for their ‘default low in/out latency’ and use those values for the in/out devices respectively.” I think this applies because you would have specified the Audient as your device.

So there are a couple of possibilities: 1/ maybe the PortAudio layer is returning a latency value for this device that you didn’t expect; or 2/ maybe it is what you expected but somehow it applies incorrectly when opening the driver.

I think, though, that if it gives you the desired result when you specify all the properties up front, then that may be the best practice going forward.

hjh

1 Like
7

Yes, and thats what i will use. thnks for clearing it up!