Apache Labs Community Forum

Not sure why, but out of the blue I am seeing very large under/overflows occurring although I haven't changed anything?

Running Thetis v.2.9.06 x64 (Protocol 2, v.2.1.18). PC: Windows 10 (not Pro), CPU: multi-core i7, 32GB RAM, 512 GB SSD NvMe.

See a couple of screen-shots immediately below. I can send shots from other forms if that helps.

Update: Several thousands now for both Under/Overflows (after about 10 minutes).

Juha
NI2M

Update 2:
About 2 hours later, I don't these really large under/overflows any more
Did shut down both PC and ANAN hardware in the mean-time.
Update3:
Very large numbers (hundreds, approaching 1,000) are back again, guesstimating based on the speed this will happen in perhaps 5-10 minutes

Occasionally the same thing will happen to me, I've always been able to stop the runaway by clicking on/off one or another of the "Manual" checkboxes in the RingBuffer or PortAudio section of the VAC settings.

Mark

Edit: I've observed that the potential for Underflow/Overflow runaway is reduced if I increase the RingBuffer size but that will also increase audio latency so I just stop the runaways manually when they happen (which is typically only at startup).

Roger that Mark.
I was aware of what you suggested but thought that there would be a more "permanent" fix for it.

Are you using Voicemeeter software?

Tony,
No, I am not.

Ok. Perhaps then check the sound control settings in windows . Sometimes windows can change these during updates.

The M-Audio Air is one of those unfortunate interfaces that provides no ASIO driver control panel. The interface relies wholly on the application software to tell it what to do. AFAIK, Thetis does not send buffer size information ASIO interfaces. Therefore it is quite possible that the M-Audio buffer size and the Thetis VAC buffer size are mismatched.

You may want to do an experiment, in this case to use Voicemeeter to tie the M-Audio together with Thetis, i.e. use Voicemeeter as a glorified patch panel and diagnostic aid. Voicemeeter will reliably show what buffer size and sample rate the M-Audio is set to, and will allow you to control that manually if necessary, all without leaving the ASIO driver domain.

Scott,

Appreciate your suggestions, but M Audio does have a control panel (see below) that shows a 128 buffer size and 48k sampling frequency just like it is on the VAC1 form.
I have used M Audio for many months straight. After upgrading to Protocol 2 I am starting to see this phenomenon and I have been on Protocol 2 now for a few weeks if my memory serves. Come to think of it, I am not sure that I have really checked what is happening on the VAC1 form, but only I have seen a few "flickers" of little red squares (and some green) just under "VAC1" on the main GUI.

Juha

You are not alone. I have the same issue with my set up. Just started out of the blue a few weeks ago.

73 Graeme G4NVH

A wild guess, is the "Network Throttle index tweak" checked on H/W select tab?

Juha--very good on that control panel! I had looked at the user manual for your interface and saw no mention of it, hence my assertion that there was none, but I'm glad that there is!

There's an older thread of discussion that some of you might have missed that may be helpful in solving some of these issues. Start on Page 2 for your reading pleasure:

https://apache-labs.com/community/viewt ... 1&start=30

The bottom line is that there still exists some problem in the resampler code that will cause it to go wildly unstable from time to time. If you don't care about latency you can just make the buffer sizes big. But if you really want to shave them down to get the lowest latency then it becomes susceptible to this instability issue. As you can tell be reading through the above referenced topic, adjusting the Feedback Gain and FF Alpha in the advanced settings can help with this at the expense of a longer initial settling time.

There are detailed results of my experiments with Feedback Gain and FF Alpha on Page 4 of that topic.

Page 5 goes off into the obscure world of Frequency Measurement Testing and can be safely ignored by regular hams

Scott,

Thanks for flagging thread from past.

I look forward to feeling pleased !

Juha
NI2M

Same problem here on Windows 11.

Not just crazy under/overflows, but also my buffers are more unstable than usual...

Windows update related?

w-u-2-o wrote: AFAIK, Thetis does not send buffer size information ASIO interfaces. Therefore it is quite possible that the M-Audio buffer size and the Thetis VAC buffer size are mismatched.

Purely for the benefit of someone searching this topic in the future: I recently did a deep-dive in the PortAudio source on this very question. PA tries to negotiate a buffer size from the loaded ASIO driver that matches the buffer size selected in Thetis' VAC1(2) drop box. If that fails, it uses whatever buffer size the ASIO device is already set for, and then inserts an extra ring-buffer between Thetis and the ASIO device to adapt between the two buffer sizes (Thetis' and ASIO's). A good example of this is the VoiceMeeter virtual ASIO driver, which will not negotiate through the usual ASIO API, and will only use the buffer size its user has set.
73!

That makes sense, Bryan, and it indicative of why best performance is obtained by matching the VAC buffer size to the ASIO buffer size. All other ASIO compatible software I've used automatically follows the ASIO device buffer size. Thetis VAC ought to do that, too, but it is not programmed that way.

The good news is that Juha is matching his buffer sizes, so that is not the issue.

W4WMT wrote:Purely for the benefit of someone searching this topic in the future: I recently did a deep-dive in the PortAudio source on this very question. PA tries to negotiate a buffer size from the loaded ASIO driver that matches the buffer size selected in Thetis' VAC1(2) drop box. If that fails, it uses whatever buffer size the ASIO device is already set for, and then inserts an extra ring-buffer between Thetis and the ASIO device to adapt between the two buffer sizes (Thetis' and ASIO's). A good example of this is the VoiceMeeter virtual ASIO driver, which will not negotiate through the usual ASIO API, and will only use the buffer size its user has set.
73!

That's not what I'm seeing...here are some snapshots of VM correctly picking up and syncing with my ASIO settings:
Mark

I was talking about the buffer size shared between Thetis and VM.

W4WMT wrote:I was talking about the buffer size shared between Thetis and VM.

Oh, thanks, I misunderstood.

Mark