Gary,
The idea that Windows audio problems are somehow intractable or insurmountable is far from true.
I have no less than three very well behaved, totally stable, audio app's on my machine right now: Voicemeeter, Studio One, and Reaper. All three will run many days at a time with not so much as a burp, no magic or Windows restarts required. They even happily run right through my aforementioned Voicemeeter registration issue (now fixed). Historically, the same is true (for me, anyways), with Ardour, Audiomulch, Pro Tools, Stereotool, and probably a few other audio app's I've since forgotten.
This in spite of pushing things to a high level of complexity. My Presonus audio interface driver is attached to Voicemeeter. Reaper, Thetis and other app's attach to Voicemeeter. Admittedly I have gone to some trouble to ensure everything is running 48KHz throughout, and have also carefully tested and validated the smallest Presonus buffer size that will work under these conditions (which happens to be 256), but that is not hard to do.
Now I am admittedly pushing things to the limit in terms of latency. The Presonus, Voicemeeter, Reaper and Thetis are all using ASIO. In Thetis I currently have all buffer settings at 0 except for the main VAC buffer size which is set to 256 in order to match up with the Presonus. If I was not using Reaper in the configuration, only Voicemeeter, I'm confident I could get that down to 128. Reaper seems to be the buffer hog!
So with all that stuff working, it is not out of the realm of possibility to achieve the same level of performance in other app's, including Thetis.
Now that I've got that big distraction of Voicemeeter periodic restarts out of the way, looking at finer grain stability of the resampler has been a lot easier. Once you get it running it seems to be pretty good. At my current "extreme" settings, after two hours the worst case under/overflow counter has a 9 in it, which is, for all intents and purposes, an inaudible and undetectable error rate.
The issues seem to be, pending further research:
- A sensitivity to certain combinations of buffer sizes and sample rate.
- No ability to handle disruptions in the state of the attached audio devices.
- Occasional problems achieving stability at startup. Even with relatively conservative Ring and PortAudio buffer settings (for me) of 10ms across the board, I can cause the resampler to run away by cycling the PortAudio manual checkbox and fix it by cycling the RingBuffer manual checkbox.
That said, once running in a stable fashion, if nothing disturbs it it works fabulously well.
The original intent of having the resampler was to solve the problem of buffer under and overruns that were audible to those using VAC for phone and CW. Warren extended this to achieving a high level of frequency accuracy for digi modes as well. And when the resampler is behaving, as I wrote it works fabulously well. There are other threads on the forum discussing this for both FT8 and FME work and the like. I have
personally measured it's performance. Those measurements were subject to ionospheric effects but were still measured in tenths of Hertz. With a good signal generator accuracy is probably below what we can measure. Bryan can tell us what theoretical performance is, probably measured in milliHertz.
As it turns out, the resampler can safely be disabled for digi modes as long as under and overrun rates are not excessive. There will be a small frequency offset, but that's just relative, and most digi modes will not notice the occasional glitch even if is audible to our ears. So for those who are having problems with it, or just don't care to be bothered with it, just don't use it. But for those who want buttery smooth audio, it's a must have.
73,
Scott