CamillaDSP - Cross-platform IIR and FIR engine for crossovers, room correction etc.

HenrikEnquist · 2020-10-17 10:11 pm

v0.4.0-beta4 is up! Get it from here: Release v0.4.0 beta 4 * HEnquist/camilladsp * GitHub
Changes since beta3:
New features:

Added an option to generate arbitrary length filters for testing convolution cpu load.
Possible to use Reload command to restart from inactive state.
Handle quirks of the USB audio gadget when used as Alsa capture source.

Bugfixes:

Fix 100% cpu when Stdin doesn't provide any data.
Reduce cpu usage when using PulseAudio.

The readme here: GitHub - HEnquist/camilladsp at develop has also been updated to include a "Related projects" section. If you know of somehting else that could be useful to add there, please let me know!

torgeirs · 2020-10-18 8:45 pm

Thank you for your efforts, Henrik.
Ran windows compiled version of the 0.4.0

Code:

  adjust_period: 60
  enable_rate_adjust: true
  enable_resampling: true

The asus U7 works very well with resampling, really small adjustments. Need really good ears to hear that pitchshift :happy1:

torgeirs · 2020-10-18 9:19 pm

HenrikEnquist said:
Use the Stdout playback device on the first instance, and Stdin capture device on the second. Then in the terminal window you connect them with a pipe character, |.

Code:

camilladsp config1.yml | camilladsp config2.yml

Yes! Managed to start to instanses

C:\Users\Torgeir\cam\camilladsp -v configPart1.yml | C:\Users\Torgeir\cam\camilladsp -v configPart2.yml

But Stdout and Stdin not found.
Example:"ERROR Playback error: could not find device"
Don't have virtual sound card. Is it needed?

HenrikEnquist · 2020-10-18 9:23 pm

torgeirs said:
Yes! Managed to start to instanses
C:\Users\Torgeir\cam\camilladsp -v configPart1.yml | C:\Users\Torgeir\cam\camilladsp -v configPart2.yml

But Stdout and Stdin not found.
Example:"ERROR Playback error: could not find device"
Don't have virtual sound card. Is it needed?

You don't need a virtual sound card for this. Can you attach the two config files?

fluid · 2020-10-18 9:35 pm

torgeirs said:
But Stdout and Stdin not found.
Example:"ERROR Playback error: could not find device"

Did you use that Capitalisation? I think windows wants it all as lower case, just in case that makes a difference (no pun intended)

torgeirs · 2020-10-18 9:40 pm

See enclosed files.
(That was fast support!)

torgeirs · 2020-10-18 9:47 pm

Just running C:\Users\Torgeir\cam\camilladsp -v configPart2.yml after exchanging
stdin
with
Linje (Xonar U7)
works fine

HenrikEnquist · 2020-10-18 9:50 pm

torgeirs said:
See enclosed files.
(That was fast support!)

On part1, change to:

Code:

  enable_rate_adjust: false
  enable_resampling: false
  playback:
    type: Stdout
    channels: 2
    format: FLOAT32LE

and on part2, change to:

Code:

  capture:
    type: Stdin
    channels: 2
    format: FLOAT32LE

Should do it

The Stdout device can't send the commands for rate adjust, so you can just as well disable that on part1.

torgeirs · 2020-10-18 9:57 pm

fluid said:
Did you use that Capitalisation? I think windows wants it all as lower case, just in case that makes a difference (no pun intended)

Tried lower case also. Same Error.
(May still be the case that lower case is needed

)

torgeirs · 2020-10-19 12:12 pm

Yes, Henrik. Now it works. No WASAPI for Stdin/out

Enclose new files with downsampling to 1000Hz.
If I want to make superlong (in time) FIR filters for bass.
No filtering prior to downsampling. Works because of sharp filter in the resampler

soundcheck · 2020-10-19 5:23 pm

Henrik.

Is there a way to make cdsp quiet, for stdin/stdout cases?

HenrikEnquist · 2020-10-19 8:11 pm

soundcheck said:
Henrik.

Is there a way to make cdsp quiet, for stdin/stdout cases?

There are no log messages on stdout, all logging is printed to stderr. Would it be useful to be able to silence also stderr? A --quiet option would be easy to add.

pi r · 2020-10-19 8:29 pm

But there is this buffer message on stdout..?

Code:

Buffer frames 16384

Or was..? Did that disappear in beta 4..? (can't see it anymore)

HenrikEnquist · 2020-10-19 9:01 pm

pi r said:
But there is this buffer message on stdout..?

Code:

Buffer frames 16384

Or was..? Did that disappear in beta 4..? (can't see it anymore)

It was there until beta3 yes, but then I found it! It's a log message on debug level now.

pi r · 2020-10-20 8:00 am

Instead I do now get this on stdout from beta 4 (no -v option):

Code:

[2020-10-19T21:06:57Z INFO  camillalib::alsadevice] Starting playback from Prepared state
[2020-10-19T21:11:11Z INFO  camillalib::alsadevice] Starting playback from Prepared state
[2020-10-19T21:14:35Z INFO  camillalib::alsadevice] Starting playback from Prepared state
[2020-10-19T21:17:44Z INFO  camillalib::alsadevice] Starting playback from Prepared state
[2020-10-19T21:18:30Z INFO  camillalib::alsadevice] Starting playback from Prepared state

It's from every time a new track starts, and a I sends a new request to reload the config.
(Using stdout from squeezelite, and not a alsa loopback, there are no specific log messages to capture when sample rate changes. Only when a new track starts...)

By the way... The timestamps in camilladsp log is GMT?
It's -2 hours off for me. System time is adjusted for time zone and summertime, and shows correct time.
It's a little bit annoying... Easy fix..?

TNT · 2020-10-20 8:29 am

UTC is professional!

//

pi r · 2020-10-20 8:39 am

Yeah, yeah... GMT, UTC, whatever... its annoying when you actually have to read it.

Not a big issue at all, and quite doable. But in this application, there are no references to any global instance. So using UTC don't really have any benefits..?

It's just a little bit annoying...

HenrikEnquist · 2020-10-20 11:08 am

pi r said:
Instead I do now get this on stdout from beta 4 (no -v option):

Code:

[2020-10-19T21:06:57Z INFO camillalib::alsadevice] Starting playback from Prepared state [2020-10-19T21:11:11Z INFO camillalib::alsadevice] Starting playback from Prepared state [2020-10-19T21:14:35Z INFO camillalib::alsadevice] Starting playback from Prepared state [2020-10-19T21:17:44Z INFO camillalib::alsadevice] Starting playback from Prepared state [2020-10-19T21:18:30Z INFO camillalib::alsadevice] Starting playback from Prepared state

It's from every time a new track starts, and a I sends a new request to reload the config.
(Using stdout from squeezelite, and not a alsa loopback, there are no specific log messages to capture when sample rate changes. Only when a new track starts...)

By the way... The timestamps in camilladsp log is GMT?
It's -2 hours off for me. System time is adjusted for time zone and summertime, and shows correct time.
It's a little bit annoying... Easy fix..?

Do you really get that on stdout? Not on stderr?

The timestamps are UTC yes, and I agree it's a bit annoying. It comes from the logging library I use. It's meant to be slim and fast so has only limited options. At a glance it doesn't seem easy to fix but I'll take a proper look.

pi r · 2020-10-20 12:27 pm

If the timestamps isn't an easy fix - let it be... It works...

The logs came on my terminal, running without -v option. I'll check again...

HenrikEnquist · 2020-10-20 12:48 pm

pi r said:
The logs came on my terminal, running without -v option. I'll check again...

Ok! The terminal shows both stdout and stderr. If you would use the stdout playback device and do this:

Code:

camilladsp my_stdout_config.yml | /dev/null

you will send the audio to /dev/null, while logging still goes to the terminal via stderr.

CamillaDSP - Cross-platform IIR and FIR engine for crossovers, room correction etc.

Member

Member

Attachments

Member

Attachments

Member

Member

Member

Attachments

Member

Member

Member

Member

Attachments

Member

Member

Member

Member

Member

Member

Member

Member

Member

Member