Variable log file name in camilladsp.service daemon - answer
Answering my own question here ... but in case anyone else wants to do the same thing and make substitutions of this nature in the ExecStart command, here's an example of what to do to make it work:
Obviously "if shell command lines are to be used, they need to be passed explicitly to a shell implementation of some kind" and something to do with needing to use double escape characters in unit files ...
Yipee!
Answering my own question here ... but in case anyone else wants to do the same thing and make substitutions of this nature in the ExecStart command, here's an example of what to do to make it work:
Code:
ExecStart=[B]/bin/bash -c '[/B]/usr/local/bin/camilladsp -a0.0.0.0 -p5000 -g-30 --logfile /usr/local/etc/camilladsp/log[B]$$[/B](date +[B]%%[/B]FT[B]%%[/B]H[B]%%[/B]M).txt -ldebug /usr/local/etc/camilladsp/config192.yml[B]'[/B]- Double up any $ or % characters
- Enclose the entire instruction in single quotes
- Preface the entire instruction with /bin/bash -c
Obviously "if shell command lines are to be used, they need to be passed explicitly to a shell implementation of some kind" and something to do with needing to use double escape characters in unit files ...
Yipee!
I just tried onboard ALC892 and volume with camilladsp is much lower than direct. I do not understand why.
Long story: Normally I use AV receiver via HDMI. But because there is cracking in the sound, I decided to connect 3x TPA3255 to onboard sound card. Thanks to advise from phofman I used hdajackretask to switch it to 7.1 in linux.
If there is no camilla, i.e. sound is routed normally via PA, it is very loud. If I route it via camilladsp, even just direct mixing source to all 8 channels, gain 0, no filters used (cat config.yml devices: adjust_period: 10 capture: avoid_blocking_r - Pastebin.com), the volume is low.
And unfortunately for me, if there are filters, there is cracking also, so the problem of cracking is in Ryzen (ryzen sound crackling - Google Search) or camilladsp, not the graphic card or the AV receiver.
Anyway I do not understand, what lowers the volume?
Long story: Normally I use AV receiver via HDMI. But because there is cracking in the sound, I decided to connect 3x TPA3255 to onboard sound card. Thanks to advise from phofman I used hdajackretask to switch it to 7.1 in linux.
If there is no camilla, i.e. sound is routed normally via PA, it is very loud. If I route it via camilladsp, even just direct mixing source to all 8 channels, gain 0, no filters used (cat config.yml devices: adjust_period: 10 capture: avoid_blocking_r - Pastebin.com), the volume is low.
And unfortunately for me, if there are filters, there is cracking also, so the problem of cracking is in Ryzen (ryzen sound crackling - Google Search) or camilladsp, not the graphic card or the AV receiver.
Anyway I do not understand, what lowers the volume?
You are using PulseAudio with an alsa-sink outputting to the loopback right?
PulseAudio has a bunch of volume settings, I would guess one of those is attenuating. Open "pavucontrol" and look around!
About the crackling sound I have no idea. I'm normally using a Ryzen laptop (2700u) which has no issues at all.
PulseAudio has a bunch of volume settings, I would guess one of those is attenuating. Open "pavucontrol" and look around!
About the crackling sound I have no idea. I'm normally using a Ryzen laptop (2700u) which has no issues at all.
Yes, I try to be as "stock" as possible. Modified are:
/etc/asound.conf
[root@dtk /]# cat /etc/asound.conf## Place your global alsa-lib configuratio - Pastebin.com
/etc/pulse/default.pa for DSP
[root@dtk /]# cat /etc/pulse/default.pa.dsp #!/usr/bin/pulseaudio -nF## Th - Pastebin.com
Current config of CamillaDSP for:
HDMI
[root@dtk configs]# cat config_real48.yml devices: adjust_period: 10 cap - Pastebin.com
ALC - just mixing inputs-outputs
oot@dtk configs]# cat config_real48_alc.yml devices: adjust_period: 10 c - Pastebin.com
I hoped the problem would be ALC stereo vs 7.1, I tried changing in Sound GUI in the Cinamon, but sound level was the same.
/etc/asound.conf
[root@dtk /]# cat /etc/asound.conf## Place your global alsa-lib configuratio - Pastebin.com
/etc/pulse/default.pa for DSP
[root@dtk /]# cat /etc/pulse/default.pa.dsp #!/usr/bin/pulseaudio -nF## Th - Pastebin.com
Current config of CamillaDSP for:
HDMI
[root@dtk configs]# cat config_real48.yml devices: adjust_period: 10 cap - Pastebin.com
ALC - just mixing inputs-outputs
oot@dtk configs]# cat config_real48_alc.yml devices: adjust_period: 10 c - Pastebin.com
I hoped the problem would be ALC stereo vs 7.1, I tried changing in Sound GUI in the Cinamon, but sound level was the same.
I don't know Cinnamon, a google image search shows a sound control panel that looks quite similar to pavucontrol, but I dont know if it shows all settings.
Can you try using "alsaloop" instead of camilladsp?
Ubuntu Manpage:
alsaloop - command-line PCM loopback
Give it a plughw as output device so it converts to the right number of channels.
Can you try using "alsaloop" instead of camilladsp?
Ubuntu Manpage:
alsaloop - command-line PCM loopback
Give it a plughw as output device so it converts to the right number of channels.
Hi tried a chunksize of 8192 and just got this in the logs when it crashed:
Code:
Oct 02 16:37:50.805 DEBG Playback buffer level: 15354.974468085107, signal rms: [-67.455795, -68.78941, -1000.0, -1000.0, -1000.0, -1000.0, -1000.0, -1000.0, -1000.0, -1000.0], module: camillalib::alsadevice
Oct 02 16:37:58.990 WARN Capture failed, error: ALSA function 'snd_pcm_readi' failed with error 'EPIPE: Broken pipe', module: camillalib::alsadevice
Oct 02 16:37:58.991 ERRO Capture error: ALSA function 'snd_pcm_readi' failed with error 'EPIPE: Broken pipe', module: camilladsp
Oct 02 16:37:58.991 DEBG Wait for playback thread to exit.., module: camilladsp
Oct 02 16:37:59.428 DEBG Restarting with new config, module: camilladsp
Oct 02 16:37:59.428 DEBG Wait for config, module: camilladsp
Oct 02 16:37:59.429 DEBG No config and not in wait mode, exiting!, module: camilladspIs there anything obvious here?
Here's the device section of the config file:
Code:
devices:
samplerate: 192000
chunksize: 8192
silence_threshold: -75
silence_timeout: 60.0
capture:
type: Alsa
channels: 2
device: "hw:CARD=Loopback,DEV=0"
format: S32LE
playback:
type: Alsa
channels: 10
device: "hw:CARD=UltraLitemk5,DEV=0"
format: S24LE3I went to try and amend the config file for "retry_on_error" but since I could find no information about this in the documentation, I'm not sure what to do. Sorry you're having to do so much hand holding!
Good catch phofman! I didn't notice that rate adjust was missing, and yes that should help.
BTW has anyone tried the v1.0.0 preview on a mac yet?
I'm quite late to the party on this, but CamillaDSP looks great and I love the Rust implementation.
Has the ASIO support been developed yet?
I would like to use this on my HTPC running Windows 10 and my old Focusrite Saffire Pro 24 through a Thunderbolt 4 card. Unfortunately it looks like only ASIO drivers are available.
Has the ASIO support been developed yet?
I would like to use this on my HTPC running Windows 10 and my old Focusrite Saffire Pro 24 through a Thunderbolt 4 card. Unfortunately it looks like only ASIO drivers are available.
From what I could tell (didn't spent a lot of time investigating so could be wrong) you can only open a single ASIO device from an application. So is using ASIO for both playback and capture then both must use the same device. This also doesn't play nice with the way CamillaDSP opens the capture and playback devices from independently from separate threads.
There are workarounds like ASIO4ALL, but it gets quite ugly.
Another problem is licensing. CamillaDSP is GPL just like Audacity. The Steinberg license terms mean that Audacity can't be distributed with ASIO support: ASIO Audio Interface - Audacity Manual
Considering these thigns and how well WASAPI exclusive mode works, I don't think adding ASIO is worth the hassle.
v0.6.3 build errors
Just cloned the camilladsp v0.6.3 library and am getting the following build errors on Debian 11.1/64-bit using the following default build command line. I used Debain's default package rustc 1.48.0 packages which appear newer than version 1.43.0.
Any ideas ?
Thanks much.
cargo 1.46.0
rustc 1.48.0
camilladsp$ RUSTFLAGS='-C target-cpu=native' cargo build --release
Just cloned the camilladsp v0.6.3 library and am getting the following build errors on Debian 11.1/64-bit using the following default build command line. I used Debain's default package rustc 1.48.0 packages which appear newer than version 1.43.0.
Any ideas ?
Thanks much.
cargo 1.46.0
rustc 1.48.0
camilladsp$ RUSTFLAGS='-C target-cpu=native' cargo build --release
Code:
Compiling camilladsp v0.6.3 (..../git_clones/camilladsp)
error[E0277]: `[f64; 5]` is not an iterator
--> src/biquadcombo.rs:90:50
|
90 | for (n, ((f, q), g)) in f_all.iter().zip(q_all).zip(g_all).enumerate() {
| ^^^^^
| |
| expected an implementor of trait `IntoIterator`
| help: consider borrowing here: `&q_all`
|
= note: the trait bound `[f64; 5]: IntoIterator` is not satisfied
= note: required because of the requirements on the impl of `IntoIterator` for `[f64; 5]`
error[E0599]: no method named `zip` found for struct `Zip<std::slice::Iter<'_, f64>, [f64; 5]>` in the current scope
--> src/biquadcombo.rs:90:57
|
90 | for (n, ((f, q), g)) in f_all.iter().zip(q_all).zip(g_all).enumerate() {
| ^^^ method not found in `Zip<std::slice::Iter<'_, f64>, [f64; 5]>`
|
= note: the method `zip` exists but the following trait bounds were not satisfied:
`[f64; 5]: Iterator`
which is required by `Zip<std::slice::Iter<'_, f64>, [f64; 5]>: Iterator`
`Zip<std::slice::Iter<'_, f64>, [f64; 5]>: Iterator`
which is required by `&mut Zip<std::slice::Iter<'_, f64>, [f64; 5]>: Iterator`
error: aborting due to 2 previous errors
Some errors have detailed explanations: E0277, E0599.
For more information about an error, try `rustc --explain E0277`.
error: could not compile `camilladsp`.
To learn more, run the command again with --verbose.Oops sorry I used a feature that was introduced in 1.53! I'll update the minimum rustc version to that.
You can easily install the latest with rustup: rustup.rs - The Rust toolchain installer
You can easily install the latest with rustup: rustup.rs - The Rust toolchain installer
HenrikEnquist,
Thanks much, that allowed it to build (and manually blowing away the Debian package rustc install).
Cargo and Rustc are now both at version 1.55.0.
FWIW, you might want to update the git-hub "Building" instructions defining the minimum version number. It currently is:
The minimum rustc version is 1.43.0.
Thanks again.
Build Optimization Questions
I have some build optimization questions if you don't mind.
On a Linux box, is the following sufficient to enable all of the CPU's target-features or do they need to be individually added with "-C target-feature=+sse4.1,+sse4.2,+avx,+etc,+etc,+etc" (from the "rustc --print target-features" listing for the specific CPU) ?
Does LTO (Link Time Optimizations) do anything other than clearing out dead/unused code from the resulting executable ?
After trying to comprehend the cargo and rustc docs, I appended the following "release" target optimization flags to the end Cargo.toml and noticed that the resulting binary reduced from @ 8.5MB to 5.5MB.
Are these flags reasonable for optimization ?
opt-level = 3 - supposedly sets optimization level and code-inlining to max
lto = true - supposedly enables link time optimizations
codgen-units = 1 - supposedly produces faster code at the expense of a slower compile time
Thanks much !!!
P.S.
I also noticed the build is using "--edition=2018" when there appears to be a 2021 option. Is there any reason to be not using the 2021 option ?
Example:
I have some build optimization questions if you don't mind.
On a Linux box, is the following sufficient to enable all of the CPU's target-features or do they need to be individually added with "-C target-feature=+sse4.1,+sse4.2,+avx,+etc,+etc,+etc" (from the "rustc --print target-features" listing for the specific CPU) ?
Code:
RUSTFLAGS='-C target-cpu=native' cargo build --release
or
RUSTFLAGS='-C target-cpu=ivybridge' cargo build --releaseDoes LTO (Link Time Optimizations) do anything other than clearing out dead/unused code from the resulting executable ?
After trying to comprehend the cargo and rustc docs, I appended the following "release" target optimization flags to the end Cargo.toml and noticed that the resulting binary reduced from @ 8.5MB to 5.5MB.
Are these flags reasonable for optimization ?
Code:
# Added profile.release section to add optimization flags
[profile.release]
opt-level = 3
lto = true
codegen-units = 1opt-level = 3 - supposedly sets optimization level and code-inlining to max
lto = true - supposedly enables link time optimizations
codgen-units = 1 - supposedly produces faster code at the expense of a slower compile time
Thanks much !!!
P.S.
I also noticed the build is using "--edition=2018" when there appears to be a 2021 option. Is there any reason to be not using the 2021 option ?
Example:
Code:
Running `rustc --crate-name serde_with --edition=2018 ...
Last edited: