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

Jump to Latest
#1,461
Can confirm that the "silence_threshold / silence_timeout" works well to cure/fix my increasing delay I experienced by restting it in a non intrusive manner. Set it to -80/20sec and one can forget about this problem which is caused by diverging clocks.

Re: the naming of channels. OK about user defined names but I would think it is a bit of a problem that 2 different objects are named the same thing. I suppose you can differentiate between them in code so it should be possible to give them distinct different names in the GUI - right? Something like c:ch2 and p:ch2 for capture resp. playback and m1:ch1 and m2:ch2 for a system with 2 mixers... if not for being able to talk about and to describe a config in a stringent manner. Helps the kind of discussion above for example.

//
 
Last edited:
#1,462
Hi forum.

I am still playing with my proto-remote and using the CDSP volume function in pipeline.
The value must be between -100dB (or so) and +20dB...
@Henrik will set volume to say +12dB do the opposite as setting the gain to -12dB... So to say, will or could some +dB volume cause clipping.

Jesper.
 
#1,463
TNT said:
Can confirm that the "silence_threshold / silence_timeout" works well to cure/fix my increasing delay I experienced by restting it in a non intrusive manner. Set it to -80/20sec and one can forget about this problem which is caused by diverging clocks.

Re: the naming of channels. OK about user defined names but I would think it is a bit of a problem that 2 different objects are named the same thing. I suppose you can differentiate between them in code so it should be possible to give them distinct different names in the GUI - right? Something like c:ch2 and p:ch2 for capture resp. playback and m1:ch1 and m2:ch2 for a system with 2 mixers... if not for being able to talk about and to describe a config in a stringent manner. Helps the kind of discussion above for example.
//
Click to expand...
I didn't consider adding some kind of naming of the channels in the gui. That might actually be a good way forward, I'll look into it!



lykkedk said:
Hi forum.

I am still playing with my proto-remote and using the CDSP volume function in pipeline.
The value must be between -100dB (or so) and +20dB...
@Henrik will set volume to say +12dB do the opposite as setting the gain to -12dB... So to say, will or could some +dB volume cause clipping.

Jesper.
Click to expand...
Yes +12dB will give a gain in 12 dB. You can easily make it clip if you go positive. I put limits on the gain mainly to avoid anything really crazy, but the values of -100 and +20 aren't special in any way and can be changed if someone has a good argument for other values 🙂
 
#1,464
TNT said:
Re: the naming of channels. OK about user defined names but I would think it is a bit of a problem that 2 different objects are named the same thing. I suppose you can differentiate between them in code so it should be possible to give them distinct different names in the GUI - right? Something like c:ch2 and p:ch2 for capture resp. playback and m1:ch1 and m2:ch2 for a system with 2 mixers... if not for being able to talk about and to describe a config in a stringent manner. Helps the kind of discussion above for example.//
Click to expand...

@ Henrik:
May I suggest a naming scheme where the mixer channels inherit their names from its source. So TNT's example would be like:
Code: 
 ch 0 > ch 0.0
        ch 0.1

 ch 1 > ch 1.0
        ch 1.1
One alternative to reduce confusion would be to start the mixer channel numbering at [input channels +1], ie: ch 3.


/ πr
 
#1,465
cdsp-samplerate-control - Alsa plugin beta test

Hi Jesper, Henrik and user seashell,

I am one of these guys who is mostly only reading threads without giving much input. But because of the great job you do here I would like to express my gratitude and I feel I should maybe also give a little feedback.

Camilladsp brought me in first contact to picorePlayer and since than I love the small fast booting solution. In my first scenario I installed superplayer together with camillaGUI but this slows down the boot process a lot. So I prefer the absolute minimum solution with only camillaDsp and Alsa_plugin on RPI. (Maybe the GUI can be installed on a different machine using websocket connection to camilladsp? A test websocket connection from Nodered to camilladsp works pretty well.)

So I tried to be a brave one (as Jesper stated on his site😀) and did a test installation of the ALSA Plugin package. I used the most recent piCorePlayer version 7.00 with the 64bit kernel. But this leads to the following issues:

- Version 7.00 is using python3.8 instead of 3.6. So the dependencies for py_six and py_websocket errored out.​
- I changed the dependencies files and could than install alsa_plugin and camilladsp. (Not sure but are the py_modules really needed for the minimum solution? In alsa plugin source I could not find any reference and camilladsp seems to be a plain executable.)​
- When trying to redirect squeezelite to the alsa plugin I got the error message [15:24:48.018274] ALSA snd_dlobj_cache_get0:345 Cannot open shared library libasound_module_pcm_cdsp.so (/usr/local/lib/alsa-lib/libasound_module_pcm_cdsp.so: /usr/local/lib/alsa-lib/libasound_module_pcm_cdsp.so: wrong ELF class: ELFCLASS32)
I assume this is because the alsa-plugin-lib is compiled for 32BIT Kernel​
- After installing camilladsp the symbolic link in /usr/local/bin has a wrong path to ‘/tmp/tcloop/camilladsp/usr/local/bin/camilladsp’. I assume it should be ‘/tmp/tcloop/camilladsp/usr/local/bin’.​
- Packaged camilladsp is also a 32Bit executable (but I could easily replace with Hendrik’s 64Bit version)​

@Jesper: Do you have plans to also provide a 64Bit version? (Or maybe you can just compile the lib for 64Bit and populate on your git?)

Hope my feedback can help a little bit...
Regards Georg
 
#1,466
@Henrik
Yes +12dB will give a gain in 12 dB. You can easily make it clip if you go positive. I put limits on the gain mainly to avoid anything really crazy, but the values of -100 and +20 aren't special in any way and can be changed if someone has a good argument for other values
Click to expand...

Nice... what i expected...
I just let my remote only allowing gain between -100 & 0, so NP here 🙂

Jesper.
 
#1,467
Thank's a lot.... 🙂 Georg

Hi Jesper, Henrik and user seashell,

I am one of these guys who is mostly only reading threads without giving much input. But because of the great job you do here I would like to express my gratitude and I feel I should maybe also give a little feedback.
Click to expand...

Soo, regarding this ::
@Jesper: Do you have plans to also provide a 64Bit version? (Or maybe you can just compile the lib for 64Bit and populate on your git?)
Click to expand...
I must say, i didn't even look at it yet, but i will eventually ofcause 😱

It's not very easy to help, when i did not try anything myself with @64bit! but you could try installing the Alsa plugin manually by using Seashell's instructions on his github.

I'am sure the websocket + six lib's are not needed when using this plugin and when not using CamillaGUI. -A thing you could try (also nice to know) is to install them with
Code: 
sudo -H pip3 install

Good luck, and thanks again for the kind word's...

Jesper.
 
#1,468
Time for a little update. I'm working on speeding up the asynchronous resampler. I got inspired by the AVX support of RustFFT, and realized that the asynchronous resampler is perfect for some SIMD.
I have it working now for SSE and AVX on x86_64, and Neon on aarch64. The Neon support in Rust is experimental, but does seem to work well.



Some preliminary numbers, this is the time it takes to resample a chunk of audio at the best quality setting:
Code: 
----------------     64-bit float    ----------------
          Ryzen 2700u   Intel i7-8550u     RPi 4
Normal:    2.2961 ms      3.2167 ms      10.662 ms
SSE:       1.1697 ms      1.4097 ms        n/a
AVX:       1.2306 ms      910.29 us        n/a
Neon:         n/a             n/a        6.2467 ms


----------------     32-bit float    ----------------
          Ryzen 2700u   Intel i7-8550u     RPi 4
Normal:    2.1431 ms      3.2309 ms      9.4775 ms
SSE:       682.09 us      828.98 us        n/a
AVX:       852.09 us      645.24 us        n/a
Neon:         n/a            n/a         4.0366 ms
 
#1,471
#1,474
phofman said:
Thanks. That's 23ms of data. Resampling on RPi at 10ms does not give much of a margin, your improvement to 6ms looks quite an important upgrade.
Click to expand...
Yes the Pi was really struggling at 192kHz. I have continued working on this and have managed to get the compiler to properly auto-vectorize the non-SIMD code. That means I get a large part of the benefit even without hand-coding simd instructions. For the Pi, it means it can now run the same test on 64-bit data in 6.6 ms without Neon, and 6.0 with.

It seems the most effective on 64-bit data. For 32-bit there is still a much larger difference.
 
#1,476
Bug in 0.4.1

Config:

Code: 
devices:
  samplerate: 88200
  chunksize: 4096
  enable_resampling: true
  resampler_type: Synchronous
  queuelimit: 128
  capture_samplerate: 44100
  capture:
    type: Stdin
    channels: 2
    format: S24LE3
  playback:
    type: Stdout
    channels: 2
    format: S24LE3

filters:
  fir:
    type: Conv
    parameters:
      type: File
      filename: C:\Users\Simone\Desktop\RHA-CL2-BASS\impulse88200.dbl
      format: FLOAT64LE
  gain:
    type: Gain
    parameters:
      gain: -4
      inverted: false

pipeline:
  - type: Filter
    channel: 0
    names:
      - gain
  - type: Filter
    channel: 1
    names:
      - gain
  - type: Filter
    channel: 0
    names:
      - fir
  - type: Filter
    channel: 1
    names:
      - fir

The resulting output has interval of sound and intervals of noise at 0dB.
Same config, same command with a previous version of camilladsp -> no problems
 
#1,478
HenrikEnquist said:
I'll investigate!
Does it go away if you remove the fir and gain filters? How long are the intervals? Which was the previous version you tried?
Click to expand...

Sorry for the late reply.

1- No it does not
2- See the attachment
3- It was from the branch develop, just after you fixed the bug of the synchronous resampling, so 3rd november in theory

uwtQSbj.png
 
#1,479
Ok I can reproduce it. There seems to be a bug in the Stdout playback device, but using File and /dev/stdout seems ok. Can you try this in your config and see if it helps?
Code: 
   capture:
     type: Stdin
     channels: 2
     format: S24LE3
   playback:
     type: File
     filename: /dev/stdout
     channels: 2
     format: S24LE3
This seems to have happened between 0.4.0-beta6 and 0.4.0. It's there in every version from 0.4.0.
 
Last edited:
You must log in or register to reply here.
Top Bottom