Analog audio crackling filter project.

[atomant]

The rate adjust must be handled somehow if the two soundcards are not synchronous. Either the device can have its rate adjusted, or async resampler must be deployed.

AFAIK CDSP can control rate of usb gadget and alsa loopback on linux and Blackhole on OSX, no direct rate control on Wasapi https://github.com/HEnquist/camilladsp/blob/master/src/wasapidevice.rs. IMO the rate adjust must be enabled and async resampler configured in your chain to work properly. Other issues may arise (as always), but this is the basic requirement.

I would very well trust you on that. However the logs seem to say otherwise. Maybe I'm misinterpreting

2024-10-14 10:22:55.447955 WARN  [src/alsadevice.rs:138] PB: Prepare playback after buffer underrun
2024-10-14 10:25:26.702532 WARN  [src/alsadevice.rs:138] PB: Prepare playback after buffer underrun
2024-10-14 10:26:36.037895 WARN  [src/alsadevice.rs:138] PB: Prepare playback after buffer underrun
2024-10-14 10:27:56.631091 WARN  [src/alsadevice.rs:138] PB: Prepare playback after buffer underrun
2024-10-14 10:28:39.993942 INFO  [src/alsadevice.rs:648] Capture device supports rate adjust
2024-10-14 10:28:39.993998 WARN  [src/alsadevice.rs:650] Needless 1:1 sample rate conversion active. Not needed since capture device supports rate adjust
2024-10-14 10:28:40.041889 INFO  [src/alsadevice.rs:142] PB: Starting playback from Prepared state

 

[phofman]

However the logs seem to say otherwise. Maybe I'm misinterpreting

Well, I see a major difference:

2024-10-14 10:28:39.993942 INFO  [src/alsadevice.rs:648] Capture device supports rate adjust
2024-10-14 10:28:39.993998 WARN  [src/alsadevice.rs:650] Needless 1:1 sample rate conversion active. Not needed since capture device supports rate adjust

vs.

2024-10-13 11:40:24.633582 INFO [src/bin.rs:683] CamillaDSP version 2.0.3
2024-10-13 11:40:24.636582 INFO [src/bin.rs:684] Running on windows, x86_64
2024-10-13 11:40:32.790618 WARN [src\wasapidevice.rs:398] Playback interrupted, no data available
2024-10-13 11:40:32.840624 INFO [src\wasapidevice.rs:382] Restarting playback after buffer underrun
2024-10-13 11:41:25.520814 WARN [src\wasapidevice.rs:398] Playback interrupted, no data available
2024-10-13 11:42:20.379280 WARN [src\wasapidevice.rs:361] Missing event! Resetting stream. Interval 0.019145833333325868 s, expected 0.01 s
2024-10-13 11:42:41.189922 WARN [src\wasapidevice.rs:361] Missing event! Resetting stream. Interval 0.02008333333333212 s, expected 0.01 s
2024-10-13 11:42:44.354824 WARN [src\wasapidevice.rs:361] Missing event! Resetting stream. Interval 0.035208333333333286 s, expected 0.02 s

While that Windows WASAPI config:

devices:
  adjust_period: 30
  capture:
    channels: 6
    device: Line 1 (Virtual Audio Cable)
    exclusive: true
    format: S16LE
    type: Wasapi
  capture_samplerate: null
  chunksize: 2048
  enable_rate_adjust: null
  playback:
    channels: 6
    device: Speakers (C-Media PCI Audio Device)
    format: FLOAT32LE
    type: Wasapi
  queuelimit: 16
  rate_measure_interval: null
  samplerate: 48000
  silence_threshold: -80
  silence_timeout: 60
  stop_on_rate_change: null
  target_level: 4095
  volume_ramp_time: null

 

[atomant]

Well, I see a major difference:

2024-10-14 10:28:39.993942 INFO  [src/alsadevice.rs:648] Capture device supports rate adjust
2024-10-14 10:28:39.993998 WARN  [src/alsadevice.rs:650] Needless 1:1 sample rate conversion active. Not needed since capture device supports rate adjust

vs.

2024-10-13 11:40:24.633582 INFO [src/bin.rs:683] CamillaDSP version 2.0.3
2024-10-13 11:40:24.636582 INFO [src/bin.rs:684] Running on windows, x86_64
2024-10-13 11:40:32.790618 WARN [src\wasapidevice.rs:398] Playback interrupted, no data available
2024-10-13 11:40:32.840624 INFO [src\wasapidevice.rs:382] Restarting playback after buffer underrun
2024-10-13 11:41:25.520814 WARN [src\wasapidevice.rs:398] Playback interrupted, no data available
2024-10-13 11:42:20.379280 WARN [src\wasapidevice.rs:361] Missing event! Resetting stream. Interval 0.019145833333325868 s, expected 0.01 s
2024-10-13 11:42:41.189922 WARN [src\wasapidevice.rs:361] Missing event! Resetting stream. Interval 0.02008333333333212 s, expected 0.01 s
2024-10-13 11:42:44.354824 WARN [src\wasapidevice.rs:361] Missing event! Resetting stream. Interval 0.035208333333333286 s, expected 0.02 s

While that Windows WASAPI config:

devices:
  adjust_period: 30
  capture:
    channels: 6
    device: Line 1 (Virtual Audio Cable)
    exclusive: true
    format: S16LE
    type: Wasapi
  capture_samplerate: null
  chunksize: 2048
  enable_rate_adjust: null
  playback:
    channels: 6
    device: Speakers (C-Media PCI Audio Device)
    format: FLOAT32LE
    type: Wasapi
  queuelimit: 16
  rate_measure_interval: null
  samplerate: 48000
  silence_threshold: -80
  silence_timeout: 60
  stop_on_rate_change: null
  target_level: 4095
  volume_ramp_time: null

It's because I'm running linux at the moment, I modified the settings after reading your message with the idea in mind to show you what I meant by

I got a message from CDSP when it starts saying the rate adjust could be handled by the VAC or audio card if memory serves so I removed it from CDSP since.

. Can't modify windows config. Dual boot...

I still have no idea what I'm doing.

 

[phofman]

It's because I'm running linux at the moment, I modified the settings after reading your message with the idea in mind to show you what I meant by

Well, but you sent logs with issues from windows, and then argue with a linux version which is very different, sorry.

While the linux capture device (either loopback or usb gadget) does support the rate adjustment, the windows one does not and requires a different configuration. You windows setup is configured incorrectly. Maybe fixing the config will fix your timeout issues in the log (in fact quite likely, IMO).

 

[atomant]

Thanks for confirming my linux setup was correct.

Well, the problem with this card exists regardless of the OS.

Besides, applying the tweaks suggested in https://www.cantabilesoftware.com/glitchfree/ resulted in a broken Windows. It boots only in safe mode. I'm restoring from backup, which via USB 3 will take 40 minutes assuming the transfer rate does not drop to USB 2 speeds. Will then correct the CDSP config and we'll start again from that.

Best!

UPDATE

Darn! You were right. Thanks a lot!

 

[AnalogSteph]

Allright, for less than $50, I purchased the one from the Cyprus seller. I'll report in 2 weeks or so.

You're willing to have an old soundcard shipped all the way from an island in the middle of the Mediterranean Sea? 'kay, whatever...

It appeared you were in Canada, was that incorrect?

On a side note, old hardware hunting on the 'bay was a fun hobby for a poor student in the mid-2000s. Got a bunch of good/interesting PC keyboards like that for a pittance, including a 1996 Cherry G80 with Windows keys that's still gracing my desk at the office. I once got a Terratec DMX for the princely sum of 1€ plus shipping... mind you, that exact card was notorious for its driver situation, as ESS never supplied full-featured reference drivers for Windows 2000 and Terratec didn't have the manpower to address this, so some major features of the card never worked in 2000 and XP... a lot of angry customers were the foreseeable result. Wasn't the only case like that at the time either. A Guillemot Maxi Studio ISIS (a semi-pro 4in/8out affair of pretty wild architecture, ESS + DREAM SAM9707, 20-bit converters of some description, I suspect AC97 codecs) just didn't get any drivers beyond 98/ME, period.

 

[atomant]

You're willing to have an old soundcard shipped all the way from an island in the middle of the Mediterranean Sea? 'kay, whatever...

Shipping fees were acceptable. They're been excessive from the USA for 15 years or so. I would call that piracy.

It appeared you were in Canada, was that incorrect?

That is correct.

On a side note, old hardware hunting on the 'bay was a fun hobby for a poor student in the mid-2000s. Got a bunch of good/interesting PC keyboards like that for a pittance, including a 1996 Cherry G80 with Windows keys that's still gracing my desk at the office. I once got a Terratec DMX for the princely sum of 1€ plus shipping... mind you, that exact card was notorious for its driver situation, as ESS never supplied full-featured reference drivers for Windows 2000 and Terratec didn't have the manpower to address this, so some major features of the card never worked in 2000 and XP... a lot of angry customers were the foreseeable result. Wasn't the only case like that at the time either. A Guillemot Maxi Studio ISIS (a semi-pro 4in/8out affair of pretty wild architecture, ESS + DREAM SAM9707, 20-bit converters of some description, I suspect AC97 codecs) just didn't get any drivers beyond 98/ME, period.

Was very active on Ebay as well in that period. It's over I'm afraid.

Moved to Amazon after nothing affordable to find on Ebay anymore. Alas Amazon too is now full of chinese garbage. You never know what you're gonna get and not in a manner like the proverbial box of chocolates (Forrest Gump).

 

[phofman]

Darn! You were right. Thanks a lot!

Very good. Now you can try using wasapi exclusive instead of going through the windows mixer many times in your chain. You will have to configure CDSP to use correct sample formats supported by the devices. Also, since you have multichannel output, I would recommend to use CDSP v.3 right away which has fixed handling wasapi exclusive formats.

 

[atomant]

Very good. Now you can try using wasapi exclusive instead of going through the windows mixer many times in your chain. You will have to configure CDSP to use correct sample formats supported by the devices.

What do you mean, I see only 'playback: format:' and 'capture: format:' each one accepting one parameter, right?

Also, since you have multichannel output, I would recommend to use CDSP v.3 right away which has fixed handling wasapi exclusive formats.

I had a look yesterday and found the beta version but no release v3 for Win.

My bad, found it right there - https://github.com/HEnquist/camilladsp/releases/download/v3.0.0-beta.1/camilladsp-windows-amd64.zip

 

[phofman]

What do you mean, I see only 'playback: format:' and 'capture: format:' each one accepting one parameter, right?

The wasapi shared mode goes through windows mixer which accepts almost any format/samplerate from the outside, doing all necessary conversions internally (basically the same to what the alsa plug plugin in linux does). The wasapi exclusive mode goes (almost) directly to the driver and accepts only formats accepted by the driver/soundcard itself. E.g. your float32 is rather unlikely to be accepted by a HW soundcard.

 

[atomant]

The wasapi shared mode goes through windows mixer which accepts almost any format/samplerate from the outside, doing all necessary conversions internally (basically the same to what the alsa plug plugin in linux does). The wasapi exclusive mode goes (almost) directly to the driver and accepts only formats accepted by the driver/soundcard itself. E.g. your float32 is rather unlikely to be accepted by a HW soundcard.

Understood. Clear enough, thanks!

Unfortunately, CDSP 3 crashes on Win 7.

Hopefully it's not compiled with a rust version > 1.75

How to make RustDesk builds work on Windows 7 (and probably Windows 8) · rustdesk rustdesk · Discussion #7503

This isn't a request for support, I've been struggling with this for a couple of days and finally found the culprit. I'm thus writing this merely to share my findings with others. Rust has in their...

github.com

In such a case, it ends right there. And impossible to build it, VS 2019, if you don't already have it, is impossible to get/install.

 

[phofman]

Unfortunately, CDSP 3 crashes on Win 7.

Where does it crash? What do the logs say?

Hopefully it's not compiled with a rust version > 1.75

Easy to check - https://github.com/HEnquist/camilladsp/blob/v3.0.0-beta.1/Cargo.toml#L7
EDIT: that settings actually just defines the minimum rust version. CDSP github builds use lastest stable for the windows builds https://github.com/HEnquist/camilla...fba6e22cc1/.github/workflows/publish.yml#L155 . That would mean 1.81 - confirmed by the build log https://github.com/HEnquist/camilladsp/actions/runs/11317552801/job/31471126426

 

[atomant]

Where does it crash? What do the logs say?


Easy to check - https://github.com/HEnquist/camilladsp/blob/v3.0.0-beta.1/Cargo.toml#L7
EDIT: that settings actually just defines the minimum rust version. CDSP github builds use lastest stable for the windows builds https://github.com/HEnquist/camilla...fba6e22cc1/.github/workflows/publish.yml#L155 . That would mean 1.81 - confirmed by the build log https://github.com/HEnquist/camilladsp/actions/runs/11317552801/job/31471126426
View attachment 399451

No log produced. It crashes at start.

That's what I was afraid of.

Then Win 7 is no longer supported.

Rust has in their infinite wisdom (and with good help from Microsoft I'm sure) decided to stop supporting all Windows versions before Windows 10 (for a programming language that is quite serious, and this is a good reason to stay way clear of Rust) after version 1.75.

Rust 1.75 will be the last to officially support Windows 7, 8 and 8.1. Support for Windows versions before 10 will end in February 2024 with Rust 1.76.

Support for Windows 7 and 8 may continue beyond these dates through the creation of new "legacy" targets for older Windows versions. Individuals or organisation(s) who can commit to providing some level of legacy testing and support should go through the normal process for creating new targets.

 

[atomant]

As you probably aware of, CDSP 3 for windows now requires Windows 10.

I tried cross compiling on a Fedora 40 and it gave me a Win 8 executable. Cannot run because of missing api-ms-win-core-winrt-l1-1-0.dll.

9998  sudo dnf install rustup
10001  rustup-init
10003  source $HOME/.cargo/env
10005  rustup default 1.75
10008  sudo dnf install mingw64-gcc mingw64-binutils
10009  rustup target add x86_64-pc-windows-gnu
10018  unzip ~/Downloads/camilladsp-3.0.0-beta.1.zip
10020  cd camilladsp-3.0.0-beta.1/
10029  cargo build --target x86_64-pc-windows-gnu --manifest-path Cargo.toml
10035  cp -v target/x86_64-pc-windows-gnu/debug/camilladsp.exe /mnt/linux486/tmp/

Then I tried cross compiling for a Win 7 target and it complained about missing link.exe

10005  rustup target add x86_64-pc-windows-msvc
10006  cargo build --target x86_64-pc-windows-msvc --release

(...)
   Compiling rawsample v0.2.0
   Compiling wasapi v0.15.0
error: linker `link.exe` not found
  |
  = note: No such file or directory (os error 2)

note: the msvc targets depend on the msvc linker but `link.exe` was not found

note: please ensure that Visual Studio 2017 or later, or Build Tools for Visual Studio were installed with the Visual C++ option.

note: VS Code is a different product, and is not sufficient.

error: could not compile `CamillaDSP` (bin "camilladsp") due to previous error

 

[phofman]

Did you talk to Henrik about the Win7 issue? He may not even know about it.

 

[atomant]

Did you talk to Henrik about the Win7 issue? He may not even know about it.

Nope, not yet, didn't want to bother him with details. He has fully automated builds. I registered (just did) on https://www.diyaudio.com/ but cannot post yet.

 

[phofman]

You can file an issue to his github repo (after registration). This is an important issue, IMO. It's simple to specify a rust version in the builds setup, e.g. by adding a dedicated win7 build. But he may not do it due to becoming stuck with old rust version. Certainly worth asking him about options, IMO.

Cc @HenrikEnquist

 

[HenrikEnquist]

I was not aware that the latest versions don't work on Windows 7, but to be honest I'm more surprised that it has worked until now.

It would be easy to add a build using rust 1.75, and that should work for cdsp 3.x. And maybe a bit more, until I update some dependency to a newer version that requires a later compiler. When that happens it's over, I won't keep using old versions of libraries to keep support for obsolete systems.

 

[atomant]

I was not aware that the latest versions don't work on Windows 7, but to be honest I'm more surprised that it has worked until now.

Agreed

It would be easy to add a build using rust 1.75, and that should work for cdsp 3.x. And maybe a bit more, until I update some dependency to a newer version that requires a later compiler.

Thanks so much

When that happens it's over, I won't keep using old versions of libraries to keep support for obsolete systems.

Totally understandable

Best regards, and thank you for that wonderful software.

 

[atomant]

Very good. Now you can try using wasapi exclusive instead of going through the windows mixer many times in your chain. You will have to configure CDSP to use correct sample formats supported by the devices. Also, since you have multichannel output, I would recommend to use CDSP v.3 right away which has fixed handling wasapi exclusive formats.

It was worth the wait. Thanks again for your kind guidance.

2024-10-20 14:25:43.425759 INFO  [src/bin.rs:781] CamillaDSP version 3.0.0
2024-10-20 14:25:43.427259 INFO  [src/bin.rs:782] Running on windows, x86_64
2024-10-20 14:25:43.583779 INFO  [C:\Users\runneradmin/.cargo\registry\src\index.crates.io-6f17d22bba15001f\audio_thread_priority-0.32.0\src\rt_win.rs:42] task 7 bumped to real time priority.

description: FL, FR, FC, LFE, RL, RR
devices:
  adjust_period: 30
  capture:
    channels: 6
    device: Line 1 (Virtual Audio Cable)
    exclusive: true
    format: S16LE
    labels:
    - FL
    - FR
    - FC
    - LFE
    - RL
    - RR
    #link_mute_control: null
    #link_volume_control: null
    #stop_on_inactive: null
    type: Wasapi
  capture_samplerate: null
  chunksize: 2048
  enable_rate_adjust: true
  multithreaded: null
  playback:
    channels: 6
    device: Speakers (C-Media PCI Audio Device)
    exclusive: true
    format: S16LE
    type: Wasapi
  queuelimit: 16
  rate_measure_interval: null
  resampler:
    profile: VeryFast
    type: AsyncSinc
  samplerate: 48000
  silence_threshold: -80
  silence_timeout: 3
  stop_on_rate_change: null
  target_level: 1024
  volume_limit: null
  volume_ramp_time: null
  worker_threads: null

Sincere thanks @HenrikEnquist !