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

Jump to Latest
#3,081
I wanted to tell you if this is a BUG, or if it is the expected behavior.

When I start CamillaDSP for the first time, the configuration file is not loaded in the GUI, if I try to apply or modify any changes in the interface, it returns the error message.

1651092332912.png


To fix it I don't have to follow these steps.

Go to FILE and press the LOAD icon.

1651092378167.png


Then press Fetch from DSP, and finally Apply to DSP.

From that moment on, the GUI is correctly applying the changes that I am making.
 
#3,083
TNT said:
Imagine there was a bas note at 0dB in both channels - clipping - urrrk 🙂

Maybe you need it also in accurate but you havent heard it - hard to hear distorsion in bass 😉

//
Click to expand...
I understand your explanation!

But what happens if the recording has the bass track only on the left channel for example? It would be -6db below the rest of the track. You would have a serious lack of importance.

It is something that has always raised doubts in me, but what if I can assure you that when you measure a Logsweep that is carried out for each separate channel, the response is flat from 20 to 20khz, if I apply those -6db it could not be.
 
#3,084
Well, in my mind, a good repoduction system reproduces what is recorded / produced and then that particular reproduction will be 6 dB lower in the bass and bass coming from one side. Nothing strange with that - we can build stereo systems that can smartly compensate for misstakes in recordings.

You last sentence is true for a 2.1 system. I always build with two subs so I don't get into that kind of "problem". What you have is a measurement problem, not a "music" reproduction problem.

//
 
  • Like
Reactions: isabido
#3,086
It is evident that I should go to a 2.2 system, but my humble system (setup attached) does not give much more!

Uli's recommendation (Acourate), is if I want to avoid clipping.

The only solution is to apply a factor of 0.5 = -6 dB gain to ALL filters (left_main, right_main, left_sub and right_sub). Thus you loose 1 bit (out of 24 bits today). Finally you can adjust the playback level by the amplifier in analog domain.
Click to expand...

But as you can see, it would apply to all channels, not just the SUB channel.
 

Attachments

  • setup.jpg
    setup.jpg
    214 KB · Views: 98
#3,087
Is simple, clipping or no clipping - your choice - its physics which is hard to argue with. Clipping being one of the absolute worst kind of distorsion there is 🙂

And even Acourate cant bend physics so don't think they can do it and other don't... nope.

Its in your head.... get over it. I promise you, "losing" one bit out of even 16 is nothing your will hear. But clipping you will hear.

//
 
#3,088
Totally agree TNT, it is evident that the most important and audible is an unpleasant clipping. I will be aware of the MOTU DISPLAY.

I don't know if the value of CamillaDSP Clipped sample is a value taken at the input or the final output before delivering to the MOTU M4.

Excuse my bad English, I don't know if you understand me sometimes, greetings from Spain.


1651135465102.png
 
#3,089
Henrik... when does Camilla indicate clipping of these cases:

a) incoming sample is clipped (=all ones)
b) becomes clipped inside the pipeline (e.g. first a gain of say 10 dB = clipped, followed by an attenuation by 15 dB = below max level.. (not all ones but distorted for sure)
c) clip on the last stage on the output
d) ?

//
 
#3,090
TNT said:
Henrik... when does Camilla indicate clipping of these cases:

a) incoming sample is clipped (=all ones)
b) becomes clipped inside the pipeline (e.g. first a gain of say 10 dB = clipped, followed by an attenuation by 15 dB = below max level.. (not all ones but distorted for sure)
c) clip on the last stage on the output
d) ?

//
Click to expand...
a) This isn't actually clipped, since one is an allowed value. Any clipping here will have already happened upstream where camilladsp doesn't have any insight, and therefore can't report it.
b) There will never* be clipping inside the pipeline!
c) This is the number of clipped samples as seen in the GUI. A few, up to a couple per second or so during loud passages, is usually inaudible.
d) -

*) The pipeline uses float numbers. Technically there is an upper limit where is will clip, it's just so large that it will never be a problem. With the default 64-bit precision that limit is about +6000 dB..
 
#3,091
Cool!

a) I think I would like to know if somehow I managed to inject, what is most absolutely probable, a clipped sample. I would have liked this to be indicated - ideally as an r-clip (received clipped) counter for an event of 10 or more consecutive samples with all ones..

b) 6000dB is a big number - I feel comfortable here 😉

c) How does this work... all ones or do you keep a bigger integer storage and track of the incoming bit-depth so that you will know? (probably the latter I suppose...)

//
 
#3,092
TNT said:
Cool!

a) I think I would like to know if somehow I managed to inject, what is most absolutely probable, a clipped sample. I would have liked this to be indicated - ideally as an r-clip (received clipped) counter for an event of 10 or more consecutive samples with all ones..

b) 6000dB is a big number - I feel comfortable here 😉

c) How does this work... all ones or do you keep a bigger integer storage and track of the incoming bit-depth so that you will know? (probably the latter I suppose...)

//
Click to expand...
a) I'll think about it. Considering how mistreated many modern productions are, I think there is a high risk of lots of false positives. But could be worth just trying.

c) All input is converted to float as the first step. I'll use 8-bit data, S8LE (which camilladsp doesn't support but the numbers get easy) to explain.
The range of signed 8-bit data is from -2^7 to +2^7-1, which becomes -128 to +127.
When converting to float the input values are divided by 2^7 = 128. That means the float values end up ranging from -128/128 = -1.0 to +127/128 ≈ 0.992.
At the output side it does the same conversion in reverse, but before that it clamps the values to the -1.0 to 0.992 range. Each sample value outside the range will be set to either extreme value, and the clipped samples counter is incremented. It also keeps track of how far outside the worst value was, and puts that info in a log message.
 
  • Like
Reactions: TNT
#3,095
@isabido
You should not have to load the config from file, it should be enough to load from DSP. But you are running the GUI meant for 0.6.3 on 1.0.0-rc3 which isn't really tested, might be the reason it's a bit quirky. (Actually if that's the only quirk you get it's working far better than I had expected!)
Have you set the "active_config" and "default_config" properties of the backend correctly?
https://github.com/HEnquist/camillagui-backend#configuration
 
#3,096
Thank you Henrik!

I have now applied these changes and it seems to work better.

But when I refresh the web browser, I have to hit Fetch from dsp again before Apply to DSP, otherwise it returns the error "Message:
Command returned an error"

By the way, what version of GUI should I install for 1.0.0-rc3?




Start Camilladsp like this:
[Unit]
Description=CamillaDSP Daemon
After=multi-user.target
StartLimitIntervalSec=10
StartLimitBurst=10

[Service]
Type=simple
ExecStart=/root/camilladsp/camilladsp -g-40 -p 1234 /root/camilladsp/default_config.yml
Restart=always
RestartSec=1
User=root
Group=root
CPUSchedulingPolicy=fifo
CPUSchedulingPriority=10

[Install]
WantedBy=multi-user.target
Click to expand...

Start Camilladsp GUI like this:
[Unit]
Description=CamillaDSP Backend and GUI
After=multi-user.target

[Service]
User=root
Type=idle
ExecStart=python3 /root/camilladsp/camillagui/main.py

[Install]
WantedBy=multi-user.target
Click to expand...

This is my camillagui.yml
camilla_host: "0.0.0.0"
camilla_port: 1234
port: 5000
config_dir: "~/camilladsp/configs"
coeff_dir: "~/camilladsp/coeffs"
default_config: "~/camilladsp/default_config.yml"
active_config: "~/camilladsp/active_config.yml"
update_symlink: true
on_set_active_config: null
on_get_active_config: null
supported_capture_types: null
supported_playback_types: null
Click to expand...
 
#3,099
I see that the there was a final V1.0.0 release yesterday! I updated my CamillaDSP installs and everything went smoothly. For the RC1 GUI I really like the option for compact view, dB graduations on level meters and ability to view a log directly from the GUI. I know it is still a RC but I do have a few very minor nits to pick with the RC1 GUI.

1) The level meters are no longer smooth and appear choppy. All prior versions had a very smooth action which looked much better.
2) When switching to compact view and then back to normal view the CamillaDSP logo in the upper left disappears until the browser is refreshed.

Michael
 
#3,100
Yes version 1.0.0 is finally released!
I also bumped the versions of the python libraries and the gui to 1.0.0, so it's easy to know what versions to run 🙂

The gui is currently in v1.0.0-rc2. Its likely ready, just needs a little more testing.

@mdsimon2 : Yes the smooth transitions were nice. Unfortunately that level meter component couldn't be customized so it wasn't possible to add the scale etc. It was actually just a simple progress bar. The new one is completely custom. It should be possible to make it do smooth transitions, I'll look at it at some point.
I can't reproduce the second issue. What browser are you using?
 
You must log in or register to reply here.
Top Bottom