Stereo Tool

I would say it's ok now, MME and KS. Wasapi is still not good, with or without block size. Buffer goes full and stays there and after some time input buffer is overfull.
Is it possible to add Jitter readings?

edit: KS is better then ever. MME input is ok, but output rises jitter a bit, it works but on KS that does not happen.

_________________
control point
control point2

problem with 64 ...after installation the screen comes and after 30 seconds stereotool disappears windows 10 any body has the same???....i went back to previous....

agreed.
i am finally able to use KS for output, WASPI for input now (beta 4).
prior to the beta, i could only use WASPI for both.
i agree that there should be advanced settings for more "experienced" users.

I found a bug that can cause ST to crash, it's solved and will be fixed in the next build.

For those who are responding: Are you using specific settings for block size, or do the defaults work? If you're using specific values, please post them here, so we can see if there's a trend in which values are good or bad.

Before i check any real soundcard, i expect to all works fine with VAC. With Leif's tool i found block size in my case for VAC at 48kHz is 240, 480 and 960 (wich is first safe choice).
At 44.1kHz it's 882.

_________________
control point
control point2

i strongly believe that the sample block sizes will vary greatly upon the users PC configuration, type of PCI/PCB hardware, CPU type and speed, their configuration of ST and the type of sound cards being used as well as the configuration of them, if applicable.
in my case, for my specific configuration, the block settings work the best at their lowest levels (160) for WASPI input and KS output @ 50mS, 48Khz sample rate matched all around, this is allowing windows to "take exclusive control of this device" for the input and output sound cards, internal to the laptop and HDMI external.
yes, there is an improvement since block sizes have been added, WASPI and KS usability and stability, and a decrease of latency by a marginal but noticeable amount.
im able to do an 8 hour test on ST monday to friday.

Hello .....found a bug that can cause ST to crash, it's solved and will be fixed in the next build........how long it's taken this HANS?? maybe tomorrow???

Something is wrong in last beta's with compressor on old AGC compared to v9.70. Does not react same at all or it's this bar acting different.

_________________
control point
control point2

For feedback only

Crash in BETA004 is fixed. Also, my new build pc now seems to work properly, which means that releasing beta's will be a lot easier (faster) from now on.

https://www.stereotool.com/download/ste ... 71-006.exe - 32 bit stand alone, new PortAudio, configurable block sizes
https://www.stereotool.com/download/ste ... 71-006.exe - 64 bit stand alone, new PortAudio, configurable block sizes

Same explanation as before:
For the main input, Normal output and FM Output, I have added a setting to overrule the standard (suggested by PortAudio) block sizes. You can change them in multiples of 16. Note that the block sizes are calculated based on 44.1/48 kHz sample rate, so if you're running at 192 kHz for example (eg. FM output), they are internally multiplied by 4.

For most devices, it looks like it doesn't matter which block size you choose - they all work, and they only (slightly) affect latency.

However, there are some devices that only work properly at very specific block sizes. My webcam microphone input for example only sounds good if it's running at a multiple of 320 samples. ANY other number causes glitches in both Wasapi and Kernel Streaming (PortAudio suggests 320 samples for Wasapi, so the default behavior was ok for Wasapi, but not for KS, where it suggested the very weird number of 2730 samples.)

So, so far I have seen devices that work well with any number, and some that require a multiple of 320. What I want to know now is if there are other devices that require a specific value.

So, I want to ask you to enable the new "Override block size" setting (for both input and outputs, not all at the same time) and try for which values your sound cards work, and report back (also if it doesn't matter and any value works). I hope that this will result in a limited number of values that we need to support - the current slider is very hard to use for cards where 95% of the possible values don't work.

Ok, we'll look into this next week.