Maybe
I have it on a list titled "Things that would be nice to have but are probably a lot of work, let's save this for later"
Cool! :-D
//
There is a new branch called "dither". It's really not well tested but seems to work ok(?).
It's fun to play with dither at very low bit depths like 4 or 5 bits. Try something with just a voice (I have been playing with Suzanne Vega - Tom's diner) and try the different dither types. Good fun
It's fun to play with dither at very low bit depths like 4 or 5 bits. Try something with just a voice (I have been playing with Suzanne Vega - Tom's diner) and try the different dither types. Good fun
Hi...
So i will try to make it work...
I hooked up the RPI4 to my DAC (Dac shows samplerate btw.. just to tell)
After loading snd-aloop (with the aloop.conf) i got this with aplay -l :
Starting squeezelite on the RPI4 :
I also copied the asound.conf to /etc/asound.conf
So now i have to figure out howto chain it together, and put in the right parameters in the config files.
Jesper.
So i will try to make it work...
I hooked up the RPI4 to my DAC (Dac shows samplerate btw.. just to tell)
After loading snd-aloop (with the aloop.conf) i got this with aplay -l :
Starting squeezelite on the RPI4 :
I also copied the asound.conf to /etc/asound.conf
So now i have to figure out howto chain it together, and put in the right parameters in the config files.
Jesper.
I stopped squeezelite and started it with the loopback :
But i'am having trouble figuring out howto start camilladsp with the right parameters and plugins configured right and filters (filter.txt)...
Hope you can help me further Henrik
Jesper.
But i'am having trouble figuring out howto start camilladsp with the right parameters and plugins configured right and filters (filter.txt)...
Hope you can help me further Henrik
Jesper.
Attachments
Last edited:
Loopback devices are quite easy to loose track of. I would recommend naming them appropriately in your asound config, e.g. Installation on Linux * pavhofman/nonlinear-compensation Wiki * GitHub
Thanks... phofman.
So i created .asoundrc
After unloading snd-aloop and modprobed it again, aplay don't show up the names, just the usual :
So i don't know if it's working.
I can start squeezelite with the "card" through
Also i must say, that i am really stuck now. I cannot move further until i understand howto setup all configurations files.
I need some really simple setup to try i guess, but right now i cannot do it by myself!
Jesper.
So i created .asoundrc
After unloading snd-aloop and modprobed it again, aplay don't show up the names, just the usual :
So i don't know if it's working.
I can start squeezelite with the "card" through
Also i must say, that i am really stuck now. I cannot move further until i understand howto setup all configurations files.
I need some really simple setup to try i guess, but right now i cannot do it by myself!
Jesper.
aplay(1) - Linux man page
aplay -l lists hardware devices
aplay -L lists PCM devices, i.e. devices created by alsa configuration, including those defined in .asoundrc
aplay -l lists hardware devices
aplay -L lists PCM devices, i.e. devices created by alsa configuration, including those defined in .asoundrc
Let's see, you are running stereo in and out. Unless you want to do some mixing between left and right you can then skip the mixers section, and only define filters and the pipeline. Try this config file, should add a highpass filter at 300 Hz for both channels so you can easily tell if it's doing something or not:
Code:
---
devices:
samplerate: 44100
buffersize: 1024
capture:
type: Alsa
channels: 2
device: "camilla_loop"
format: S32LE
playback:
type: Alsa
channels: 2
device: "hw:Amanero"
format: S32LE
filters:
highpass_test:
type: Biquad
parameters:
type: Highpass
freq: 300
q: 0.5
pipeline:
- type: Filter
channel: 0
names:
- highpass_test
- type: Filter
channel: 1
names:
- highpass_testGreat! Good job
What filter(s) are you running?
I have updated the "dither" branch and added some tests. It seems to be working just fine and it's quite fun to play with. 10 bits with noise shaped dither is actually quite good. 8 bits isn't bad either but the noise can be a little annoying.
Next up, segmented convolution...
What filter(s) are you running?
I have updated the "dither" branch and added some tests. It seems to be working just fine and it's quite fun to play with. 10 bits with noise shaped dither is actually quite good. 8 bits isn't bad either but the noise can be a little annoying.
Next up, segmented convolution...
Great! Good job
What filter(s) are you running?
I have updated the "dither" branch and added some tests. It seems to be working just fine and it's quite fun to play with. 10 bits with noise shaped dither is actually quite good. 8 bits isn't bad either but the noise can be a little annoying.
Next up, segmented convolution...
Hi again here guy's
I only did try the simple filter you pasted here (highpass), and it is working for sure.
Right now i'am compiling an realtime kernel to see if it gives even better performance & to avoid possible glitches and other nasty stuff.
I will use this camilladsp for room correction with the UMIK-1 microphone i will recieve very soon. I plan to use REW and maybe RePhase for creating the fir filters for each corrosponding samplerate (44.1, 88, 96, 192 etc...)
I donno if i can resample everything to 96Khz before it enters camilladsp without loss of quality (I'am audiophile for sure
)... If that's possible i will make a room correction filter for 96Khz and let camilladsp handle only this until Henrik eventually will code so camilladsp is capable of switching ?Rgds; Jesper.
This detail is very interesting! I never tried doing that, thanks for reporting
It might open up an easy way to catch sample rate changes (at least for the Alsa backend), meaning that automatic switching might be a lot easier than I thought... Need to experiment a bit...
Nowadays I actually work with software development on full time (since about two years), and since the switch I've become much faster at writing working code..Ur on a wave
//
I'm using the same hardware I've had for about five years, with a pair of Heil AMT tweeters together with 8-inch woofers in vented boxes. And still with FIR crossovers
Got it running this morning with a simple filter running on pi 2 with hifiberry soundcard.
Very nice software, much easier to configure then Brutefir.
I use Squeezelite output via loopback into Camilla DSP using same .asoundrc as Jesper.
What I am still getting is a ''crackle'' sort of dropout every few minutes...sort of vinyl play experience.
Is there a way to solve this?
Regards and thank you for such a nice program.
Ronnie
Very nice software, much easier to configure then Brutefir.
I use Squeezelite output via loopback into Camilla DSP using same .asoundrc as Jesper.
What I am still getting is a ''crackle'' sort of dropout every few minutes...sort of vinyl play experience.
Is there a way to solve this?
Regards and thank you for such a nice program.
Ronnie
Hi,
It is simple filter from the Camilla dsp library. It just mixes to mono.
Had the same problem with Brutefir. Also without loopback, direct fileplay.
I think it is configuration. Some people with Volumio and brutefir plugin had dropouts.
Switching to Camilla might solve it I hoped.
Thanks for the help you offered
It is simple filter from the Camilla dsp library. It just mixes to mono.
Had the same problem with Brutefir. Also without loopback, direct fileplay.
I think it is configuration. Some people with Volumio and brutefir plugin had dropouts.
Switching to Camilla might solve it I hoped.
Thanks for the help you offered
The problem is most likely that the loopback runs a little slower than the dac, so the playback thread runs out of data one in a while. Does CamillaDSP print "prepare playback" in the terminal every time you get the noise?
You can probably get rid of some of it by pausing the processing between songs. This resets the timing, just set a short silence_timeout, half a second maybe.
I have a few ideas on how to improve this:
- Let the buffer underrun happen (as it's done now) but add a longer delay before restarting playback. This would mean it takes much longer until the next one.
- Watch the buffer and when it's getting dangerously low insert some interpolated samples to make the glitch less audible.
- Same as the previous one but try insert silence when the music is quiet.
Opinions?
You can probably get rid of some of it by pausing the processing between songs. This resets the timing, just set a short silence_timeout, half a second maybe.
I have a few ideas on how to improve this:
- Let the buffer underrun happen (as it's done now) but add a longer delay before restarting playback. This would mean it takes much longer until the next one.
- Watch the buffer and when it's getting dangerously low insert some interpolated samples to make the glitch less audible.
- Same as the previous one but try insert silence when the music is quiet.
Opinions?