For the moment i am happy, it works... had not that much sleep the last day's 😉
But later on i will try the sox capture!
Crackling Noise with Async Resampler on Terratec Aureon 5.1 MK2 USB in CamillaDSP
Hello diyAudio community,
I’m experiencing a crackling noise issue when enabling a preset that uses the async resampler, which I need to capture an SPDIF signal. The noise occurs as a brief crackle lasting only a fraction of a second right when the preset is activated.
This crackling also happens at the end of the silence timeout period.
The noise appears with all presets except the “very fast and free” preset. This issue is specific to the Terratec Aureon 5.1 MK2 USB sound card; with another USB sound card, there is no noise.
I’m running camillaDsp 3 and the latest Raspberry Pi OS.
Has anyone encountered this or know what might cause it?
Thanks in advance for your help!
P.S. Additionally, could someone clarify the audio quality of the “free” preset, especially its cutoff frequency at 48 khz sample rate ? this is the resampler parameters
sinc_len 128
oversampling_factor 256
interpolation Quadratic
window BlackmanHarris2
Hello diyAudio community,
I’m experiencing a crackling noise issue when enabling a preset that uses the async resampler, which I need to capture an SPDIF signal. The noise occurs as a brief crackle lasting only a fraction of a second right when the preset is activated.
This crackling also happens at the end of the silence timeout period.
The noise appears with all presets except the “very fast and free” preset. This issue is specific to the Terratec Aureon 5.1 MK2 USB sound card; with another USB sound card, there is no noise.
I’m running camillaDsp 3 and the latest Raspberry Pi OS.
Has anyone encountered this or know what might cause it?
Thanks in advance for your help!
P.S. Additionally, could someone clarify the audio quality of the “free” preset, especially its cutoff frequency at 48 khz sample rate ? this is the resampler parameters
sinc_len 128
oversampling_factor 256
interpolation Quadratic
window BlackmanHarris2
Last edited:
HI
Can anybody tell me, what to do, to make sure, that i can hard cut power on the Raspi without risk of broken files?
Thx in advance!
Can anybody tell me, what to do, to make sure, that i can hard cut power on the Raspi without risk of broken files?
Thx in advance!
@chriss0212 : It's simple to say but a bit hard to do : do not write to the storage when cutting the power. Embedded systems designed for safety use read-only filesystems and keep modified files only in memory. All changes are lost are reboot, of course. That's e.g. what Daphile does.
Using a filesystem with journal (ext4, COW-based fs like BTRFS) helps a lot, since the power cut either comes at writing the journal (the main fs is OK, only that part of journal is corrupted), or at later writing from journal to the main fs (the main fs gets corrupted, but can be fixed with automatic fscheck at boot using the unaffected journal data).
I enjoyed working with Voyage linux which keeps its root fs read-only and could switch to RW with a simple command, allowing easy installation/setup. It would keep specified directories in TMPFS (RAM) and sync their contents with the root fs at shutdown. I have a device https://github.com/pavhofman/plabs-player running every day with no fs corruption for 9 years, countless hard power cuts.
The same (apart of the integrated tmpfs dirs) should be possible with Raspi (lite) - custom R/O setup. For an embedded device I would certainly recommend such approach. In many cases there is no need for a permanently R/W filesystem on an embedded device.
Using a filesystem with journal (ext4, COW-based fs like BTRFS) helps a lot, since the power cut either comes at writing the journal (the main fs is OK, only that part of journal is corrupted), or at later writing from journal to the main fs (the main fs gets corrupted, but can be fixed with automatic fscheck at boot using the unaffected journal data).
I enjoyed working with Voyage linux which keeps its root fs read-only and could switch to RW with a simple command, allowing easy installation/setup. It would keep specified directories in TMPFS (RAM) and sync their contents with the root fs at shutdown. I have a device https://github.com/pavhofman/plabs-player running every day with no fs corruption for 9 years, countless hard power cuts.
The same (apart of the integrated tmpfs dirs) should be possible with Raspi (lite) - custom R/O setup. For an embedded device I would certainly recommend such approach. In many cases there is no need for a permanently R/W filesystem on an embedded device.
Perfect THX
I found this:
https://learn.adafruit.com/read-only-raspberry-pi/overview
Using the raspi-config it is possible to set the boot partitition to read only and with this command i can disable write protection temporarily.
Will check!
I found this:
https://learn.adafruit.com/read-only-raspberry-pi/overview
Using the raspi-config it is possible to set the boot partitition to read only and with this command i can disable write protection temporarily.
sudo mount -o remount,rw /bootWill check!
Well, that handles only the small boot partition which IIUC is typically vfat. But setting the overlay option in the GUI/TUI (also described in that article) should set the root partition R/O which is a much bigger change.
That's what i want to do.
And i thought that:
Code:
sudo mount -o remount,rw /bootIs this wrong?
That is the boot partition (mounted in /boot), not the root one (/), IIUC. For the root one the process is described in https://www.and-e.co.uk/sysadmin/raspberryPiOverlayFileSystem.html
I'm trying to use the GUI and keep getting an error message from CDSP: 'unknown field config_path on line 2 column 1', even though I'm using the example state file, which has:
"
---
config_path: my-path-to-the-config_file.yml
mute:
- false
- false
<etc. -- 2 more mute commands and 4 volume commands >
"
the error message goes on to say that it expects one of "title", "description", "devices", "mixers", 'filters", "processors" or "pipeline". All those look like items that would actually appear in the config file (which runs OK w/o trying to use the GUI BTW).
I was able to get the gui running without using a state file but now can't reconstruct the commands that accomplished it. I was getting a missing statefile.yml message.
Is the example statefile.yml curent? If so, what is the problem?
"
---
config_path: my-path-to-the-config_file.yml
mute:
- false
- false
<etc. -- 2 more mute commands and 4 volume commands >
"
the error message goes on to say that it expects one of "title", "description", "devices", "mixers", 'filters", "processors" or "pipeline". All those look like items that would actually appear in the config file (which runs OK w/o trying to use the GUI BTW).
I was able to get the gui running without using a state file but now can't reconstruct the commands that accomplished it. I was getting a missing statefile.yml message.
Is the example statefile.yml curent? If so, what is the problem?
The state file format hasn't changed. The error message means that it's trying to parse the state file as a normal config. What is your backend config, and what options do you give on the command line when starting CamillaDSP?
I first start camillagui_backend with no options because if I start first CDSP using the command
"camilladsp -w -p5005 -s statefile.yml" the backend reports an error because the port is already in use.
When starting the backend first, CDSP (as started up using the above command) initially works OK but when I send my browser to localhost:5005/gui/index.html the backend generates an error, claiming that the config file path in the statefile is wrong. It wants stuff in "configs", NOT "config". This was confusing to me because CDSP docs indicate that you need to store them in "config". So to migrate from a command-line approach to using the GUI requires that all the stuff in "config" has to be copied over into "configs". I didn't see that requirement in the docs. There also seems to be some back & forth in the docs regarding "config" and "configs".
I did finally figure out that the -p parameter can NOT be 5005 because then CDSP eventually reports that the port already is in use. I assumed that the "-p1234" parameter in the docs was just an example of a port number you might use, but it was not obvious that the port assignment(s) can NOT be the same. The backend is (?) hardwired to use port# 5005, end of sentence. So what is port# 1234 used for? Not clear in the docs, either. What happens if I use, say, "-p4567"? Is port# 1234 required??
I have to say that adding the "configs" folder requirement is confusing -- why was it necessary? And the port assignment issue isn't all that clearly spelled out.
All this whining done, by trial and error I managed to get the GUI running.
"camilladsp -w -p5005 -s statefile.yml" the backend reports an error because the port is already in use.
When starting the backend first, CDSP (as started up using the above command) initially works OK but when I send my browser to localhost:5005/gui/index.html the backend generates an error, claiming that the config file path in the statefile is wrong. It wants stuff in "configs", NOT "config". This was confusing to me because CDSP docs indicate that you need to store them in "config". So to migrate from a command-line approach to using the GUI requires that all the stuff in "config" has to be copied over into "configs". I didn't see that requirement in the docs. There also seems to be some back & forth in the docs regarding "config" and "configs".
I did finally figure out that the -p parameter can NOT be 5005 because then CDSP eventually reports that the port already is in use. I assumed that the "-p1234" parameter in the docs was just an example of a port number you might use, but it was not obvious that the port assignment(s) can NOT be the same. The backend is (?) hardwired to use port# 5005, end of sentence. So what is port# 1234 used for? Not clear in the docs, either. What happens if I use, say, "-p4567"? Is port# 1234 required??
I have to say that adding the "configs" folder requirement is confusing -- why was it necessary? And the port assignment issue isn't all that clearly spelled out.
All this whining done, by trial and error I managed to get the GUI running.
The location for the config files is given in the backend config, it doesn't have to be "configs". See https://github.com/HEnquist/camillagui-backend?tab=readme-ov-file#configuration
The port you give to camilladsp with -p is the where it starts the websocket server. This is used by the gui backend to communicate with the camilladsp process. Port number 1234 is just an example, but a pretty good choice because it's easy remember and usually not occupied by anything else. You can use another, just edit the "camilla_port" in the backend config to match.
Port 5005 for the backend can also be changed, it's called just "port" in the backend config.
This short two sentences have been posted the 17th of February 2020. And ... we completely forgot to celebrate
CamillaDSP's five years jubilee
So then, better late than never! Let me express my thank to you, Henrik, for your ongoing commitment. And also my thank goes to you all contributors here having helped tracking down eventual unexpected behaviors, and by this way exposed and explained the deeper function of CamillaDSP's host sound systems. As for me, I am not only a more than satisfied and happy CamillaDSP user, but, and as a Linux Audioer, I have learned and am still ongoingly learning a lot about ALSA also.
Thank you!
Five years! My first thought was that no that can't be right, no way it's already been five years. But you are of course right. Time flies when you're having fun!
CamillaDSP has gotten a lot more attention than I dared hoping for when I made that first post. I don't have any good way of guessing how many use it today, but I can see that the binary releases have been downloaded about 99000 times. I can't see how many have downloaded just the source and compiled themselves, and no idea how many use it in moOde.
The largest success has actually been the RustFFT wrapper I made, to do FFT of real numbers twice as fast, based on an application note from TI. It started as a part of CamillaDSP and then I thought it maybe could be useful for a few others as well. It has now been downloaded from crates.io over 3.4 million times! After that comes the Rubato resampling library which is another CamillaDSP spin-off. That has "only" 1.8 million downloads 😀
Big thanks to everyone here helping out in so many different ways! CamillaDSP would not be what it is today without you!
Let's not miss the 10-year celebrations in 2030!
CamillaDSP has gotten a lot more attention than I dared hoping for when I made that first post. I don't have any good way of guessing how many use it today, but I can see that the binary releases have been downloaded about 99000 times. I can't see how many have downloaded just the source and compiled themselves, and no idea how many use it in moOde.
The largest success has actually been the RustFFT wrapper I made, to do FFT of real numbers twice as fast, based on an application note from TI. It started as a part of CamillaDSP and then I thought it maybe could be useful for a few others as well. It has now been downloaded from crates.io over 3.4 million times! After that comes the Rubato resampling library which is another CamillaDSP spin-off. That has "only" 1.8 million downloads 😀
Big thanks to everyone here helping out in so many different ways! CamillaDSP would not be what it is today without you!
Let's not miss the 10-year celebrations in 2030!
This only works if I use a command option when starting camillagui_backend, to change its default configuration directory. It took a bit of browsing through the docs to find the command-line options.
For my purposes it would be nice if I can use the GUI to change the current CDSP config file -- for instance, to select different sources like the turntable or CD player. The GUI allows me to reload the current configuration but not to select a different configuration. Is this possible to do by changing the backend config file or the GUI config file?
That should not be needed. How did you install the gui, in conda, a virtual env, or using the binary bundle from the GitHub release page? And where is the backend config you edited located?
That should work, we just need to figure out what is wrong with your setup.
I installed the binary bundle. My file hierarchy is: /home/mark/camilladsp/. In turn, /camilladsp contains the executable "camilladsp", /camillagui_backend, /config, /configs, and statefile.yml. The /configs folder was part of the bundle.
I have found that I can view and load CDSP config files with the GUI if the backend is directed to use the same folder for its config file. It appears to ignore the default_dir parameter.
I have found that I can view and load CDSP config files with the GUI if the backend is directed to use the same folder for its config file. It appears to ignore the default_dir parameter.
Did you edit the backend config as described here?
https://github.com/HEnquist/camillagui-backend?tab=readme-ov-file#configureing-the-bundled-gui
If I get your structure correctly then it should be at: /home/mark/camilladsp/camillagui_backend/_internal/config/camillagui.yml
Can you show the contents of that file?
https://github.com/HEnquist/camillagui-backend?tab=readme-ov-file#configureing-the-bundled-gui
If I get your structure correctly then it should be at: /home/mark/camilladsp/camillagui_backend/_internal/config/camillagui.yml
Can you show the contents of that file?
My setup is as you describe. camillagi.yml inside /home/mark/camilladsp/camillagui_backend/_internal/config/ is the same as what I downloaded:
camilla_host: "127.0.0.1"
camilla_port: 1234
bind_address: "0.0.0.0"
port: 5005
ssl_certificate: null
ssl_private_key: null
gui_config_file: null
config_dir: "~/camilladsp/configs"
coeff_dir: "~/camilladsp/coeffs"
default_config: "~/camilladsp/default_config.yml"
statefile_path: "~/camilladsp/statefile.yml"
log_file: "~/camilladsp/camilladsp.log"
on_set_active_config: null
on_get_active_config: null
supported_capture_types: null
supported_playback_types: null
I am not editing this config file because the readme indicated that the config file that's used by the backend is in /home/mark/camilladsp/config/ -- but the default location used by the backend appears to be /configs. I added that folder inside ~/camilladsp: " /home/mark/camilladsp/configs/" and copied the two yml files there -- and the backend was good with that.
Except for the problem of not being able to use my camilladsp config files unless they are copied to the "configs" folder -- or if I execute the backend as: " camillagui_backend -c /home/mark/camilladsp/config/camillagui.yml". This DOES permit me to access all my camilladsp config files, but I have to edit the backend's config file so its default config directory also is ~/camilladsp/config.
What is the purpose of "~/camilladsp/default_config.yml"? I haven't seen any examples of its use.
camilla_host: "127.0.0.1"
camilla_port: 1234
bind_address: "0.0.0.0"
port: 5005
ssl_certificate: null
ssl_private_key: null
gui_config_file: null
config_dir: "~/camilladsp/configs"
coeff_dir: "~/camilladsp/coeffs"
default_config: "~/camilladsp/default_config.yml"
statefile_path: "~/camilladsp/statefile.yml"
log_file: "~/camilladsp/camilladsp.log"
on_set_active_config: null
on_get_active_config: null
supported_capture_types: null
supported_playback_types: null
I am not editing this config file because the readme indicated that the config file that's used by the backend is in /home/mark/camilladsp/config/ -- but the default location used by the backend appears to be /configs. I added that folder inside ~/camilladsp: " /home/mark/camilladsp/configs/" and copied the two yml files there -- and the backend was good with that.
Except for the problem of not being able to use my camilladsp config files unless they are copied to the "configs" folder -- or if I execute the backend as: " camillagui_backend -c /home/mark/camilladsp/config/camillagui.yml". This DOES permit me to access all my camilladsp config files, but I have to edit the backend's config file so its default config directory also is ~/camilladsp/config.
What is the purpose of "~/camilladsp/default_config.yml"? I haven't seen any examples of its use.