HEnquist
Dropouts on Windows
Running CamillaDSP on Windows, with VAC as the 2ch Loopback, and outputting to a Merging Audio Device (actually a Merging NADAC), the following error presents with associated glitches in the audio stream.
2025-03-24 16:37:19.702576 WARN [src\wasapidevice.rs:380] Missing event! Resetting stream. Interval 0.0199 s, expected 0.0100 s
Brief look at the code - maybe an issue with the way the buffer is calculated?
Attaching log file (debug) and config file.
Maybe related to last comment on #346 (buffer counting), on Windows in general not specifically to Asio?
There are quite a few messages like this: "Device time counted up by 0.0000 s". This looks like VAC may have some timing issues (that can probably be worked around). I have not tried VAC yet but it's on the to-do list. I usually use VB-Audio Cable, does it behave better for you? https://vb-audio.com/Cable/
Maybe related to last comment on #346 (buffer counting), on Windows in general not specifically to Asio?
No these issues are completely unrelated.
I have been listening to music now for over an hour with CamillaDSP and VAC without any dropouts. What system are you running on? Are there any other heavy processes running, virtual machines or whatnot? On my system the device time counts up by 0.0099 to 0.0101 s, I don't see the much larger variations you have.
The system is an i9, and it is running MediaCentre/JRiver. No VM's. There are quite a few audio plugins (inc VB Cable, RME ASIO etc). But I don't think any involve significant CPU or memory intensive.
The playback device is a Ravenna network model - that thankfully has a 8ch WDM mode.
I am pretty sure I observed similar errors when using RME TotalMix for loopback, so kind of points to a localhost issue.
We'll keep looking, and try VB Cable as well, thanks for investigating.
Ah sorry I mixed up what happens where. The device time messages are from the playback side, so VAC vs VB-Audio doesn't have anything to do with it. But at least it makes more sense, I would expect much larger variations from a network device. The check that cause the trouble is looking for missed events. It may happen that the playback device misses to fire an event when it needs new data. This happens very rarely, but when it does, then the playback device somehow ends up in a non-working state and the stream must be reset. Looking at the device position is the only way I have found so far to catch this, but it has turned out to be really tricky to avoid false positives. Do you want to try compiling a custom version without the check? Then just comment out lines 385, 386 and 387 here: https://github.com/HEnquist/camilladsp/blob/master/src/wasapidevice.rs#L385
Thanks, I'm working on this now.
I ran into a snag whilst starting to run a setup involving Capture from one VAC cable to another, eg:
capture: type: Wasapi device: "Line 1 (Virtual Audio Cable)" channels: 2 format: FLOAT32LE exclusive: false loopback: false
playback: type: Wasapi device: "Line 2 (Virtual Audio Cable)" channels: 32 format: FLOAT32LE exclusive: false
2025-03-28 00:53:49.205747 ERROR [src\bin.rs:293] Playback error: Playback error: Not enough memory resources are available to complete this operation. (0x8007000E) 2025-03-28 00:53:49.205927 DEBUG [src\bin.rs:298] Error while starting, release barrier
Is this an issue that can be addressed in CamillaDSP or is it a Windows thing?
Quick googling found this article, which suggests that the issue may be on the application side.
I dropped samplerate to 96000 to continue testing (was on 192k previously).
The not enough memory error doesn't present with 96000 samplerate (hence using 1/2 size FIR filters) - so I assume below some threshold.
This host has lots of memory (64gb).
In any case - on VAC Capture & Playback I can't reproduce the "Missing event! Resetting stream" issue.
I'll have access to the DAC where the issue was found, so will try there in a couple of days (incl. commenting out the lines suggested in wasapidevice.rs).
Playback error: Playback error: Not enough memory resources are available to complete this operation. (0x8007000E)
Do you get the error if you leave the sample rate at 192k and remove the fir filters from the pipeline?
I'll have access to the DAC where the issue was found, so will try there in a couple of days (incl. commenting out the lines suggested in wasapidevice.rs).
Ok sounds good. I think I have found a way to make it more robust, so if this test works out I'll ask you to test with some other changes later on.