Henrik, I was looking at building a filter for the Harman loudspeaker target curve (https://www.audiosciencereview.com/...ker-target-responses-in-csv-txt-format.16401/) and as digitalfrost says in post#23 of the mentioned thread, It's a biquad shelving filter around 100hz for the bass level and then a linear drop from 400-500hz towards 20khz.
Now I thought I could use a BiquadCombo filter and the FivePointPeq looked perfect, however, FivePointPeq doesn't appear in the dropdown list, only the Butterworth and LR are there. What am I doing wrong ?
Now I thought I could use a BiquadCombo filter and the FivePointPeq looked perfect, however, FivePointPeq doesn't appear in the dropdown list, only the Butterworth and LR are there. What am I doing wrong ?
Hi,
I have question regarding resampling and rate adjust. From the log in CamillaGUI i can see the following message when I am resampling from 44100 to 88200
2023-01-09 16:17:36.564013 INFO [src/alsadevice.rs:592] Capture device supports rate adjust
2023-01-09 16:17:36.564301 WARN [src/alsadevice.rs:596] Async resampler not needed since capture device supports rate adjust. Switch to Sync type to save CPU time.
This message does not correlate with the information from the documentation, which says that rate adjust is ignored using synchronised resampling:
When using the rate adjust feature to match capture and playback devices, one of the "Async" variants must be used. These asynchronous presets do not rely on a fixed resampling ratio. When rate adjust is enabled the resampling ratio is dynamically adjusted in order to compensate for drifts and mismatches between the input and output sample clocks. Using the "Synchronous" variant with rate adjust enabled will print warnings, and any rate adjust request will be ignored.
Which of them are correct? Or have i misunderstood something?
At last, thank you for the great work on CamillaDSP, it has replaced my MiniDSP 2x4HD and I am very pleased with the result!
I have question regarding resampling and rate adjust. From the log in CamillaGUI i can see the following message when I am resampling from 44100 to 88200
2023-01-09 16:17:36.564013 INFO [src/alsadevice.rs:592] Capture device supports rate adjust
2023-01-09 16:17:36.564301 WARN [src/alsadevice.rs:596] Async resampler not needed since capture device supports rate adjust. Switch to Sync type to save CPU time.
This message does not correlate with the information from the documentation, which says that rate adjust is ignored using synchronised resampling:
When using the rate adjust feature to match capture and playback devices, one of the "Async" variants must be used. These asynchronous presets do not rely on a fixed resampling ratio. When rate adjust is enabled the resampling ratio is dynamically adjusted in order to compensate for drifts and mismatches between the input and output sample clocks. Using the "Synchronous" variant with rate adjust enabled will print warnings, and any rate adjust request will be ignored.
Which of them are correct? Or have i misunderstood something?
At last, thank you for the great work on CamillaDSP, it has replaced my MiniDSP 2x4HD and I am very pleased with the result!
Rate adjust can be used in two ways, here is the excerpt from the documentation.
enable_rate_adjust (optional, defaults to false)
This enables the playback device to control the rate of the capture device, in order to avoid buffer underruns of a slowly increasing latency. This is currently supported when using an Alsa, Wasapi or CoreAudio playback device. Setting the rate can be done in two ways.
- If the capture device is an Alsa Loopback device, the adjustment is done by tuning the virtual sample clock of the Loopback device. This avoids any need for resampling.
- If resampling is enabled, the adjustment is done by tuning the resampling ratio. The resampler_type must then be one of the "Async" variants.
Michael
The FivePointPeq isn't implemented in the gui (yet). It's meant for https://t-5.eu/hp/Software/Pulseaudio Crossover NG/
Maybe I'll add it in the gui at some point. For now, just add a lowshelf, highshelf and three peaking filters. The result is the same.
Henrik, by adding that it is specific behaviour on Alsa Loopback and USB Audio gadgets definitely made it clearer. Thank you!
Hi all
First of all thank you Henrik for this amazing piece of software! DIY community is blessed (and spoiled) with so talented people, creating software like this and sharing.
I have two questions I hope somebody can help me with:
1.
If I follow https://github.com/HEnquist/camilladsp-config (Alsa loopback method, not Scripples I/O plugin), step 3 mentions the Alsa Plug device and also that if using this, Alsa will handle samplerate and format adjustments. Is my understanding correct:
When doing so, Alsa will take care of "everything", regarding samplerate, and match whatever arrives on the input of plug "CamillaDSP" with the fixed samplerate and format of the alsa loopback device? (hence zero reason to use rate adjust and sample rate conversion in camilladsp and Scripples I/O plugin is not needed either).
2.
Step 6 mentions that you can redirect all system audio to the alsa plug device, in the example via -either- Pulseaudio or Pipewire.
In the Pulseaudio section of that step, it redirects audio to the just created alsa plug "CamillaDSP", which makes sense.
In the Pipewire section of step 6, it seems that the target is the loopback device, and not the alsa plug "CamillaDSP", which in my head, does not make sense and skips the alsa plug "Camilladsp" entirely, and therefor there will not be any samplerate or format adjustments either.
Is the entire step 6 for Pipewire, so that we still need to make adjustments for Pulseaudio as well as mentioned, or should the subsection of step 6 for pipewire be changed, so that it targets alsa plug "CamillaDSP" instead of the current "hw:Loopback,1,0" ?
My goal is to run a linux box, with all system audio redirected to camilladsp, and have it resampled and reformatted to the fixed settings on the input side of camilladsp. Basically making it as easy as possible, to have sound from "whereever", reaching the speakers, without buffer underruns, cracks/pops and what not
I hope somebody have the time to briefly clarify.
First of all thank you Henrik for this amazing piece of software! DIY community is blessed (and spoiled) with so talented people, creating software like this and sharing.
I have two questions I hope somebody can help me with:
1.
If I follow https://github.com/HEnquist/camilladsp-config (Alsa loopback method, not Scripples I/O plugin), step 3 mentions the Alsa Plug device and also that if using this, Alsa will handle samplerate and format adjustments. Is my understanding correct:
When doing so, Alsa will take care of "everything", regarding samplerate, and match whatever arrives on the input of plug "CamillaDSP" with the fixed samplerate and format of the alsa loopback device? (hence zero reason to use rate adjust and sample rate conversion in camilladsp and Scripples I/O plugin is not needed either).
2.
Step 6 mentions that you can redirect all system audio to the alsa plug device, in the example via -either- Pulseaudio or Pipewire.
In the Pulseaudio section of that step, it redirects audio to the just created alsa plug "CamillaDSP", which makes sense.
In the Pipewire section of step 6, it seems that the target is the loopback device, and not the alsa plug "CamillaDSP", which in my head, does not make sense and skips the alsa plug "Camilladsp" entirely, and therefor there will not be any samplerate or format adjustments either.
Is the entire step 6 for Pipewire, so that we still need to make adjustments for Pulseaudio as well as mentioned, or should the subsection of step 6 for pipewire be changed, so that it targets alsa plug "CamillaDSP" instead of the current "hw:Loopback,1,0" ?
My goal is to run a linux box, with all system audio redirected to camilladsp, and have it resampled and reformatted to the fixed settings on the input side of camilladsp. Basically making it as easy as possible, to have sound from "whereever", reaching the speakers, without buffer underruns, cracks/pops and what not
I hope somebody have the time to briefly clarify.
Last edited:
On my system, if I follow the guide, I guess its about the order of the "cards" in alsa (I have no idea), I have to use "hw:Loopback,0,0" and not "hw:Loopback,1,0" in the pipewire config. If I do, it seems everything is working and that resampling and format are adjusted via the alsa "camilladsp" plug. (I assume, this alsa plug "Camilladsp" is no where to be seen, I output directly to "alsa loopback").Hi all
First of all thank you Henrik for this amazing piece of software! DIY community is blessed (and spoiled) with so talented people, creating software like this and sharing.
I have two questions I hope somebody can help me with:
1.
If I follow https://github.com/HEnquist/camilladsp-config (Alsa loopback method, not Scripples I/O plugin), step 3 mentions the Alsa Plug device and also that if using this, Alsa will handle samplerate and format adjustments. Is my understanding correct:
When doing so, Alsa will take care of "everything", regarding samplerate, and match whatever arrives on the input of plug "CamillaDSP" with the fixed samplerate and format of the alsa loopback device? (hence zero reason to use rate adjust and sample rate conversion in camilladsp and Scripples I/O plugin is not needed either).
2.
Step 6 mentions that you can redirect all system audio to the alsa plug device, in the example via -either- Pulseaudio or Pipewire.
In the Pulseaudio section of that step, it redirects audio to the just created alsa plug "CamillaDSP", which makes sense.
In the Pipewire section of step 6, it seems that the target is the loopback device, and not the alsa plug "CamillaDSP", which in my head, does not make sense and skips the alsa plug "Camilladsp" entirely, and therefor there will not be any samplerate or format adjustments either.
Is the entire step 6 for Pipewire, so that we still need to make adjustments for Pulseaudio as well as mentioned, or should the subsection of step 6 for pipewire be changed, so that it targets alsa plug "CamillaDSP" instead of the current "hw:Loopback,1,0" ?
My goal is to run a linux box, with all system audio redirected to camilladsp, and have it resampled and reformatted to the fixed settings on the input side of camilladsp. Basically making it as easy as possible, to have sound from "whereever", reaching the speakers, without buffer underruns, cracks/pops and what not
I hope somebody have the time to briefly clarify.
I am using Moode Audio and keep getting MPD error in some circumstances due to CamillaDSP. I posted on Moode forums but I think its best to post on here. I think the issue may be related to CamillaDSP as no MPD error occurs when not using CamillaDSP. So it may be CamillaDSP related?
Issue is reproduced by playing a track for about 10-15sec and then going to another track. Instead of playing the next track an error pops up. The error is 'MPD error Failed to open audio output". Pressing play straight after the error results in playback resuming.
Changing MPD buffer size changes the time period when the track change causes an error i.e. 10-15sec before forward for 16MB buffer size, around 20sec for 4MB buffer size.
The hardware is:
RP4 with USB DAC/audio interface, 4 channel output Motu M4.
CamillaDSP is setup to have:
2 channel input to 4 channel output mixer and a couple of filters. The pipeline is 2 input channels to 3 output channels with a filter on each of the 3 channels.
CamillaDSP config:
Here is an example of log entries in CamillaDSP
Original Moode Audio post describing the issue
Issue is reproduced by playing a track for about 10-15sec and then going to another track. Instead of playing the next track an error pops up. The error is 'MPD error Failed to open audio output". Pressing play straight after the error results in playback resuming.
Changing MPD buffer size changes the time period when the track change causes an error i.e. 10-15sec before forward for 16MB buffer size, around 20sec for 4MB buffer size.
The hardware is:
RP4 with USB DAC/audio interface, 4 channel output Motu M4.
CamillaDSP is setup to have:
2 channel input to 4 channel output mixer and a couple of filters. The pipeline is 2 input channels to 3 output channels with a filter on each of the 3 channels.
CamillaDSP config:
Code:
devices:
adjust_period: 10
capture:
channels: 2
extra_samples: 0
filename: /dev/stdin
format: S32LE
read_bytes: 0
skip_bytes: 0
type: File
capture_samplerate: 96000
chunksize: 2048
enable_rate_adjust: false
enable_resampling: false
playback:
channels: 4
device: hw:CARD=M4
format: S32LE
type: Alsa
queuelimit: 1
rate_measure_interval: 1
resampler_type: BalancedAsync
samplerate: 96000
silence_threshold: 0
silence_timeout: 0
stop_on_rate_change: false
target_level: 0
filters:
Speakers:
parameters:
freq: 100
order: 4
type: ButterworthHighpass
type: BiquadCombo
Subwoofer:
parameters:
freq: 100
order: 4
type: ButterworthLowpass
type: BiquadCombo
mixers:
ToM4:
channels:
in: 2
out: 4
mapping:
- dest: 0
mute: false
sources:
- channel: 0
gain: 0
inverted: false
mute: false
- dest: 1
mute: false
sources:
- channel: 1
gain: 0
inverted: false
mute: false
- dest: 2
mute: false
sources:
- channel: 0
gain: -6
inverted: false
mute: false
- channel: 1
gain: -6
inverted: false
mute: false
pipeline:
- name: ToM4
type: Mixer
- channel: 0
names:
- Speakers
type: Filter
- channel: 1
names:
- Speakers
type: Filter
- channel: 2
names:
- Subwoofer
type: FilterHere is an example of log entries in CamillaDSP
Code:
2023-01-15 02:32:52.280360 INFO [src/bin.rs:420] Capture finished
2023-01-15 02:32:52.344207 INFO [src/bin.rs:410] Playback finished
2023-01-15 02:32:52.522939 INFO [src/bin.rs:711] CamillaDSP version 1.0.3
2023-01-15 02:32:52.523046 INFO [src/bin.rs:712] Running on linux, aarch64
2023-01-15 02:32:52.555524 INFO [src/alsadevice.rs:161] Starting playback from Prepared state
2023-01-15 02:33:02.760712 [38;5;208mWARN[0m [src/alsadevice.rs:157] Prepare playback after buffer underrun
2023-01-15 02:33:02.867833 [38;5;208mWARN[0m [src/alsadevice.rs:192] Wait timed out, playback device takes too long to drain buffer
2023-01-15 02:33:02.867957 [38;5;208mWARN[0m [src/alsadevice.rs:213] Retrying playback, error: ALSA function 'snd_pcm_writei' failed with error 'EAGAIN: Try again'
2023-01-15 02:33:02.889353 [38;5;196mERROR[0m [src/bin.rs:344] Playback error: ALSA function 'snd_pcm_writei' failed with error 'EAGAIN: Try again'
2023-01-15 02:33:02.973876 [38;5;208mWARN[0m [src/alsadevice.rs:192] Wait timed out, playback device takes too long to drain buffer
2023-01-15 02:33:02.974003 [38;5;208mWARN[0m [src/alsadevice.rs:213] Retrying playback, error: ALSA function 'snd_pcm_writei' failed with error 'EAGAIN: Try again'
Jan 15 13:33 : output: Failed to play on "ALSA Default" (alsa): snd_pcm_poll_descriptors_revents() failed: No such device
Jan 15 13:33 : exception: Failed to open audio output
2023-01-15 02:33:15.488663 INFO [src/bin.rs:711] CamillaDSP version 1.0.3
2023-01-15 02:33:15.488845 INFO [src/bin.rs:712] Running on linux, aarch64
2023-01-15 02:33:15.517145 INFO [src/alsadevice.rs:161] Starting playback from Prepared stateOriginal Moode Audio post describing the issue
Last edited:
@gwurb:
Your MPD log:
while your camilladsp:
Where does MPD output to? Does it really output to the stdin?
It would almost suggest mpd and camilla wrestle for the same device...
It's rather unfortunate that MPD and camilladsp logs are mixed into one stream or not prefixed with their source.
Your MPD log:
Code:
Jan 16 11:43 : output: Failed to play on "ALSA Default" (alsa): snd_pcm_poll_descriptors_revents() failed: No such device
Jan 16 11:43 : exception: Failed to open audio outputwhile your camilladsp:
Code:
capture:
channels: 2
extra_samples: 0
filename: /dev/stdinWhere does MPD output to? Does it really output to the stdin?
Code:
2023-01-15 02:33:02.867957 [38;5;208mWARN[0m [src/alsadevice.rs:213] Retrying playback, error: ALSA function 'snd_pcm_writei' failed with error 'EAGAIN: Try again'
2023-01-15 02:33:02.889353 [38;5;196mERROR[0m [src/bin.rs:344] Playback error: ALSA function 'snd_pcm_writei' failed with error 'EAGAIN: Try again'
2023-01-15 02:33:02.973876 [38;5;208mWARN[0m [src/alsadevice.rs:192] Wait timed out, playback device takes too long to drain buffer
2023-01-15 02:33:02.974003 [38;5;208mWARN[0m [src/alsadevice.rs:213] Retrying playback, error: ALSA function 'snd_pcm_writei' failed with error 'EAGAIN: Try again'It would almost suggest mpd and camilla wrestle for the same device...
It's rather unfortunate that MPD and camilladsp logs are mixed into one stream or not prefixed with their source.
/dev/stdin was the default, or at least its not something I remember changing.
As far as logs go, I don't know where Moode Audio MPD log is.
@TimCurtis would you be able to shed light on the stdin question? Also, where do I find the MPD log to cross reference events? Thanks.
@gwurb: This log does look like from MPD and does suggest MPD outputs to alsa:
https://github.com/MusicPlayerDaemo...e560dd45564ec/src/output/Thread.cxx#L275-L277
Code:
Jan 16 11:43 : output: Failed to play on "ALSA Default" (alsa): snd_pcm_poll_descriptors_revents() failed: No such device
Jan 16 11:43 : exception: Failed to open audio outputhttps://github.com/MusicPlayerDaemo...e560dd45564ec/src/output/Thread.cxx#L275-L277
I see what you mean.
The CamillaDSP log I pasted above was obtained from CamillaDSP GUI 'Show log file'. Another example:
Code:
2023-01-16 09:18:28.912372 INFO [src/bin.rs:711] CamillaDSP version 1.0.3
2023-01-16 09:18:28.912481 INFO [src/bin.rs:712] Running on linux, aarch64
2023-01-16 09:18:28.938540 INFO [src/alsadevice.rs:161] Starting playback from Prepared state
Jan 16 20:21 : player: played "NAS/Music/Various/Track1.m4a"
2023-01-16 09:21:12.601944 INFO [src/bin.rs:420] Capture finished
2023-01-16 09:21:12.665720 INFO [src/bin.rs:410] Playback finished
2023-01-16 09:21:13.133497 INFO [src/bin.rs:711] CamillaDSP version 1.0.3
2023-01-16 09:21:13.133598 INFO [src/bin.rs:712] Running on linux, aarch64
2023-01-16 09:21:13.178757 INFO [src/alsadevice.rs:161] Starting playback from Prepared state
2023-01-16 09:21:34.825056 [38;5;208mWARN[0m [src/alsadevice.rs:157] Prepare playback after buffer underrun
2023-01-16 09:21:56.742210 [38;5;208mWARN[0m [src/alsadevice.rs:157] Prepare playback after buffer underrun
2023-01-16 09:21:56.848964 [38;5;208mWARN[0m [src/alsadevice.rs:192] Wait timed out, playback device takes too long to drain buffer
2023-01-16 09:21:56.849086 [38;5;208mWARN[0m [src/alsadevice.rs:213] Retrying playback, error: ALSA function 'snd_pcm_writei' failed with error 'EAGAIN: Try again'
2023-01-16 09:21:56.870415 [38;5;196mERROR[0m [src/bin.rs:344] Playback error: ALSA function 'snd_pcm_writei' failed with error 'EAGAIN: Try again'
2023-01-16 09:21:56.954860 [38;5;208mWARN[0m [src/alsadevice.rs:192] Wait timed out, playback device takes too long to drain buffer
2023-01-16 09:21:56.954967 [38;5;208mWARN[0m [src/alsadevice.rs:213] Retrying playback, error: ALSA function 'snd_pcm_writei' failed with error 'EAGAIN: Try again'
Jan 16 20:21 : output: Failed to play on "ALSA Default" (alsa): snd_pcm_poll_descriptors_revents() failed: No such device
Jan 16 20:21 : exception: Failed to open audio outputI setup CamillaDSP on a mac and plugged in M4 into the mac and there are buffer underruns but no issues with draining buffer or no devices. But, there is also no MPD in the chain. It's sound output to BlackHole, and CamillaDSP from BlackHole to M4.
CamillaDSP log from mac:
Code:
2023-01-16 09:25:51.556361 INFO [src/bin.rs:711] CamillaDSP version 1.0.3
2023-01-16 09:25:51.556986 INFO [src/bin.rs:712] Running on macos, aarch64
2023-01-16 09:25:52.051356 WARN [src/coreaudiodevice.rs:766] Samples were dropped, missing 85 buffers
2023-01-16 09:27:08.550003 WARN [src/coreaudiodevice.rs:377] Playback interrupted, no data available
2023-01-16 09:27:08.552679 INFO [src/coreaudiodevice.rs:366] Restarting playback after buffer underrun
2023-01-16 09:27:45.233193 WARN [src/coreaudiodevice.rs:377] Playback interrupted, no data available
2023-01-16 09:27:45.235782 INFO [src/coreaudiodevice.rs:366] Restarting playback after buffer underrun
Last edited:
Really like the new gui. I especially like the more comprehensive "Config" section, quick config switch, "apply automatically" and the convolution filter graphs now with phase based impulse peak. Started to use the gui to make changes to my config files but ran into a minor issue with the python library.
I am using the python library to upload new configurations from object using set_config(). Works fine when the config file uses absolute path for convolution coefficients files for example /home/pi/camilladsp/coeffs/cor1.dbl. If I modify and save the config using the gui, it saves the coefficient file path as ../coeffs/cor1.dbl. I then get an error trying to upload from object using set_config() if the object contains the ../coeffs/cor1.dbl path and not an absolute path. The current working directory is /home/pi/camilladsp/camillaremote when set_config() is used which I thought should work with ../coeffs/cor1.dbl path.
the error I get is:
Traceback (most recent call last):
File "/home/pi/camilladsp/camillaremote/camillaremote.py", line 396, in <module>
cdsp.set_config(configs[config_name])
File "/home/pi/.local/lib/python3.9/site-packages/camilladsp/camilladsp.py", line 433, in set_config
self.set_config_raw(config_raw)
File "/home/pi/.local/lib/python3.9/site-packages/camilladsp/camilladsp.py", line 393, in set_config_raw
self._query("SetConfig", arg=config_string)
File "/home/pi/.local/lib/python3.9/site-packages/camilladsp/camilladsp.py", line 132, in _query
return self._handle_reply(command, rawrepl)
File "/home/pi/.local/lib/python3.9/site-packages/camilladsp/camilladsp.py", line 147, in _handle_reply
raise CamillaError("Command returned an error")
camilladsp.camilladsp.CamillaError: Command returned an error
The backend is configured with:
config_dir: "/home/pi/camilladsp/configs"
coeff_dir: "/home/pi/camilladsp/coeffs"
default_config: "/home/camilladsp/default_config.yml"
active_config: "/home/pi/camilladsp/active_config.yml"
active_config_txt: "/home/pi/camilladsp/active_config.txt"
log_file: "/home/pi/camilladsp/camilladsp.log"
update_config_symlink: true
update_config_txt: false
I am using the python library to upload new configurations from object using set_config(). Works fine when the config file uses absolute path for convolution coefficients files for example /home/pi/camilladsp/coeffs/cor1.dbl. If I modify and save the config using the gui, it saves the coefficient file path as ../coeffs/cor1.dbl. I then get an error trying to upload from object using set_config() if the object contains the ../coeffs/cor1.dbl path and not an absolute path. The current working directory is /home/pi/camilladsp/camillaremote when set_config() is used which I thought should work with ../coeffs/cor1.dbl path.
the error I get is:
Traceback (most recent call last):
File "/home/pi/camilladsp/camillaremote/camillaremote.py", line 396, in <module>
cdsp.set_config(configs[config_name])
File "/home/pi/.local/lib/python3.9/site-packages/camilladsp/camilladsp.py", line 433, in set_config
self.set_config_raw(config_raw)
File "/home/pi/.local/lib/python3.9/site-packages/camilladsp/camilladsp.py", line 393, in set_config_raw
self._query("SetConfig", arg=config_string)
File "/home/pi/.local/lib/python3.9/site-packages/camilladsp/camilladsp.py", line 132, in _query
return self._handle_reply(command, rawrepl)
File "/home/pi/.local/lib/python3.9/site-packages/camilladsp/camilladsp.py", line 147, in _handle_reply
raise CamillaError("Command returned an error")
camilladsp.camilladsp.CamillaError: Command returned an error
The backend is configured with:
config_dir: "/home/pi/camilladsp/configs"
coeff_dir: "/home/pi/camilladsp/coeffs"
default_config: "/home/camilladsp/default_config.yml"
active_config: "/home/pi/camilladsp/active_config.yml"
active_config_txt: "/home/pi/camilladsp/active_config.txt"
log_file: "/home/pi/camilladsp/camilladsp.log"
update_config_symlink: true
update_config_txt: false
Actually both ways work with both Pulse and Pipewire.
If you use the plug device, Alsa will handle all samplerate and format conversion. If you use the loopback directly, then instead PulseAudio or Pipewire handles conversions. They are perfectly capable of doing that, it's more a question of preference where you want the conversions done. Not a very clear answer, but I hope it helps anyway
Relative paths are always a bit tricky. The gui backend actually translates all relative paths to absolute before sending a config to camilladsp. When camilladsp gets sent a configuration file over the websocket, it doesn't know from what path it came. The only place it can look then is in its own working directory, and that isn't likely the right place.
If you instead do set_config_name(path_to_yml_file) followed by a reload(), then it knows where the file came from and then relative paths should be ok. The alternative is to do as the gui does, and expand the relative paths to absolute before sending the config.
I have a few questions if I may.
I’m using a subwoofer so have summed the left and the right signal into a mono signal for the subwoofer. Is this ok to do? Do I need to reduce the gain? The reason I’ve asked is I’ve noticed I’m getting clipped samples even with a -3db gain filter on all channels.
And secondly what would be the best crossover filter type to use for main speakers and subwoofer? I heard elsewhere a linkwitz transform might be good for a sub but I’m unsure about the mains. Could someone please clarify?
The setup is as follows:
Optical input
(https://www.tindie.com/products/beni_skate/tinytoslink-raspberry-pi-optical-audio/) - this feeds into a PI
Then output to an OKTO DAC 8 Pro.
I’m using a subwoofer so have summed the left and the right signal into a mono signal for the subwoofer. Is this ok to do? Do I need to reduce the gain? The reason I’ve asked is I’ve noticed I’m getting clipped samples even with a -3db gain filter on all channels.
And secondly what would be the best crossover filter type to use for main speakers and subwoofer? I heard elsewhere a linkwitz transform might be good for a sub but I’m unsure about the mains. Could someone please clarify?
The setup is as follows:
Optical input
(https://www.tindie.com/products/beni_skate/tinytoslink-raspberry-pi-optical-audio/) - this feeds into a PI
Then output to an OKTO DAC 8 Pro.
Whe summing you can get up to +6dB, so you want at least -6dB on the summed. Then filtering may produce a few samples with even higher amplitude. To be sure, attenuate 2-3 dB on the mains, and 8-9 dB on the sub.
Link with transform is a special equalizer for sealed speakers, it's not useful as a crossover. You probably mean Linkwitz-Riley. There is no clear answer on which is the best filter, everyone has their favorite. But if you start with 4:th order LR for both high- and lowpass you should have something acceptable to start experimenting from.
Thank you for the help Henrik much appreciated.
Is there a way to donate some money to you as a thank you for the software?
Thanks for the explanation and suggestions, easy enough to just to expand the relative path. I assume the path is relative to the config file directory or maybe the back end working directory ?
On a different topic, the convolution filters take about 20 sec to plot for my setup running both camillacdsp and the backend on a rpi4 with raspberry pi OS 64 bit. The full size graph, which is really nice feature btw, takes about 30 sec to display. Numpy is installed so I think it is being used, is this what can be expected with an rpi4 running the backend ?