Stereo Tool

I think they just pipe the audio through the command line version, that shouldn't add more than 100 ms of latency. Anything above that must be coming from LiquidSoap.

BETA043 posted!

This one requires a bit more information. So, we found out that for MME, Wasapi, Kernel Streaming and DirectSound, the internal sound card buffer sizes (NOT the buffers that you see in Stereo Tool!) that Windows tells us to use are actually NOT always correct, and often much smaller bufffers are possible.

Here are the default buffer sizes that Windows gives us:

• MME: 90 ms for a system not running anything else, 180 ms to be safe on a system that runs more software.
• Wasapi: 3 ms for a system not running anything else, 10 ms to be safe on a system that runs more software.
• Kernel Streaming: (Sorry, I forgot the numbers)
• DirectSound: 120 ms for a system not running anything else, 240 ms to be safe on a system that runs more software.

Using the smaller numbers caused issues on some systems (that's what several people posted about in the last week). These numbers are used for both inputs and outputs, so in the safest mode, using DirectSound would give you AT LEAST 480 ms of latency.

Anyway, we've done tests on some systems and many systems can run with much smaller numbers. For example, my development system is perfectly happy with > 18 ms buffer sizes for MME. Using that, the MME latency is actually only marginally higher than that of Wasapi.

We have added sliders to control these latencies. You can find them under Audio I/O -> Miscellaneous. They are called "MME safety buffer", "Wasapi safety buffer" etc. Since theoretically Windows can give different numbers for different sound cards or Windows versions (none of the ones that we have tested so far deviates, but that doesn't mean that it can't happen), the sliders are actually multiplication values - you can multiply the safety value by these slider values. The default values if you enable them are for the "not running anything else" values, so there are at 50% (30% for Wasapi).

What I would like to know is which values for these sliders work. On my system for example, setting MME below 18 ms (10%; this value itself works on some sample rates but not on others) will completely break things. Sometimes the system recovers after a bit, but if that happens, the buffer filling is all wrong. At very low values there's almost no data at all anymore and everything comes to a halt. If this happens for other people as well, I can change the minimum value of that slider to 10 or 11%. Most others also seem to run down to about 10%, below that, there are often issues.

Please let me know how low you can go on your system, which Windows version you are using and if it's the same on all sound cards.

On my system, this setting allows me to reduce the MME latency by 170 ms compared to "safe" mode, 60 ms compared to the previous beta's. For Wasapi and Kernel Streaming, which have much smaller buffers to begin with, the difference is only a few milliseconds.

I was able to get 16.5ms via WASAPI 48khz on my M-Audio FW410 until I toggled Input 2 (ASIO) on and off. After that I had to adjust it to 16.6 for it to stabilize. This is down from 48ms.

This sound card has 2 wasapi outputs that I am able to use (line 1/2, and multichannel). The "Line 1/2" one goes down to 16.6, but the "multichannel" one only stabilizes at 20.1ms. Sometimes toggling an input or output on/off messes this up and I need to add a .1 ms or so.


Edition Windows 10 Pro
Version 22H2
OS build 19045.2486
Experience Windows Feature Experience Pack 120.2212.4190.0

edit: Ah I missed the safety buffer settings. Reassessing now

Win10 21H1

VAC, Buffersize 15ms:
MME i can go low as 10% on Safety buffer
Wasapi still does not work on output, safety buffer does not help (input is fine.)
KS i can set safety to 4%, all fine (0 is I/O crash) Might be good to not allow less then 1 on sliders.
DS none.

edit:
Managed to make wasapi to work and it's fine at 0.0%.

_________________
control point
control point2

Hello guys, the linux JACK builds with new GUI don't seem to work, it has got a new dependency on libxpm, after installing that it closes with a simple Segmentation fault, no usual errors like before.

Hmm. Does anybody with experience in spreadsheets want to create a table for easy plugging in and submitting the requested info? Sample Rate, API, safety buffer, diversity buffer, windows version, sound card, notes? What else?

I don't thinkt that that's necessary. We just want to get a general feel for which ranges are "safe" to offer. For example, so far no-one (we also received replies outside of this forum, via email and chat apps - which does make it harder to keep track of things by the way so please reply here if possible) has been able to run MME below 10%. So for MME, we will probably set 10% as the minimum value. For KS I've heard values of between 4 and 8%.

Hm,
I think it`s an error, but i don`t know.
I was selecting 9 bands instead of 5 in AutoEQ ... and this happens.
Operation cannot continue. Must close and reopen. Reopened was with 9 bands in operation.

Yeah this happens in Bass EQ as well.

Bass EQ also seems to make MB1 flip out and go nuts when adjusting the channel linking in Bass EQ. Should I send my ini and instructions to replicate?

Hi, yes, please send me a file + how to reproduce it. It doesn't appear to happen here. I tried changing the number of bands and playing with channel linking.