I can't reproduce this on "rawfiles" or "develop". Can you try download again and rebuild?
Just do
Code:
git checkout rawfiles
git pull
Code:
> git log
commit 4b90f9325feff4169690f3f0387d4e22cdeb2337 (HEAD -> rawfiles, origin/rawfiles)
Author: Henrik Enquist <##########>
Date: Mon Mar 16 21:31:45 2020 +0100
Add biquad readme
(plus more lines below with older stuff..)The latest "rawfiles" should work with .bin, .dbl and .txt. Just set the format to FLOAT32, FLOAT64 or TEXT.
Could you attach the filter you tried?
Works. FLOATt32LE, BIN files.
If I want to pad down tweeterlevel, where in the configfile do you put the gainsetting like below?
Do you put it straight under the highpass section?
highpass_fir:
type: Conv
parameters:
type: File
filename: /home/pi/highpass.bin
format: FLOAT32LE
(here??)
filters:
gainexample:
type: Gain
parameters:
gain: -3.0
inverted: false
You define it as a separate filter:
Code:
filters:
tweetergain:
type: Gain
parameters:
gain: -7.3
Code:
pipeline:
- type: Mixer
name: mono
- type: Filter
channel: 1
names:
- highpass_fir
- tweetergainOfcourse, logical.
Define it first, then "attach'' it in the pipeline to the desired channel.
"rawfiles" has been updated. There were a few bugs in reading coefficients in float64 and int16 formats.
I also added an option to specify delay in samples.
I also added an option to specify delay in samples.
When i'll be back from job today, i'am gonna build the new RAW with git checkout / git pull, also enabling the 32bit
I feel i have control over the most basic alsa stuff now, so getting it to work now should be easier for me 😉
Next move is then to create some real filters for room correction.
I will make measurements in REW with my UMIK-1 and load it into RePhase and try to make some adjustments.
I will make two mono files (L+R) at each samplerate i need...
Jesper.
Henrik,
Considering CPU resources on a simple pi, is it possible to create LR2 orLR4 filter with biquads?
Considering CPU resources on a simple pi, is it possible to create LR2 orLR4 filter with biquads?
Yes, you just use one or two Highpass / Lowpass with appropriate q-values.
camilladsp/filterfunctions.md at rawfiles * HEnquist/camilladsp * GitHub
(not complete and for some reason Github didn't like my tables)
In short,
- for LR2, use a single Highpass / Lowpass with Q=0.5
- for LR4, chain two Highpass / Lowpass, each with Q=0.707
Hi...
So i found this link http://forums.melaudia.net/attachment.php?aid=22240
And took some measurements at my shop/office, and followed the guide (well i think i screewed small parts of it up, but it's my first time😛)
I loaded the filter in the camilladsp config :
Really worked 1. shoot 🙂
I really have to adjust the rate settings, as i still have some glitches (could be the crappy dac through)
I have attached the filters in .bin / .txt & .wav (I missed some "real" files along my way to test, therefore i attach them here for othe newbies to look at)
Jesper.
Btw: PI is loaded ~11% on CPU when build with 32bit, looking good:
So i found this link http://forums.melaudia.net/attachment.php?aid=22240
And took some measurements at my shop/office, and followed the guide (well i think i screewed small parts of it up, but it's my first time😛)
I loaded the filter in the camilladsp config :
Really worked 1. shoot 🙂
I really have to adjust the rate settings, as i still have some glitches (could be the crappy dac through)
I have attached the filters in .bin / .txt & .wav (I missed some "real" files along my way to test, therefore i attach them here for othe newbies to look at)
Jesper.
Btw: PI is loaded ~11% on CPU when build with 32bit, looking good:
Attachments
The glitches/xruns can happen at any device.You are checking the output soundcard buffer, but are all remaining buffers large enough (playback software -> loopback playback, loopback capture -> camilladsp)?
One thing is having the clocks synchronized (you already have that), another thing is getting the data soon enough (buffer sizes).
Ofcause your'e right. I can adjust the buffer on the squeezelite, but i think it's good allready as there are no glitches when playing without camilladsp for sure.
So i think playback software (LMS) are good also, so it must be either the loopback or the camilla.
I donno yet howto adjust loopback, so back to reading, thanks phofman 😉
.asoundrc :
Buffer and period sizes for opened devices are listed in their /proc/asound/card*/pcm*/sub*/hw_params files. I would suggest to check them to see if there are reasonable values (period time at least 10ms, possibly more if latency is no issue). The more, the better.
THIS must be my loopback device 0 (squeeze) - sends stream to squeezelite player
pi@SuperBPI:/proc/asound/card0/pcm0p/sub0 $ cat hw_params
pi@SuperBPI:/proc/asound/card0/pcm0p/sub0 $ cat sw_params
THIS must be my loopback device 1 (camilla_in) - Which captures the stream from squeezelite
pi@SuperBPI:/proc/asound/card0/pcm1c/sub0 $ cat hw_params
pi@SuperBPI:/proc/asound/card0/pcm1c/sub0 $ cat sw_params
Do i set these parameters 'period time etc...' in .asoundrc or do i have to go deeper 🙂
Jesper.
period_size: 128 at 44.1kHz is 2.9ms IRQ period. Why so low?...
The playback side of loopback at 40ms is probably OK.
What are the soundcard buffer/period?
You can either configure your PCM device with custom period/buffer sizes and tell the alsa client to use it, or most alsa clients offer this as configuration. Henrik will know right away...
The playback side of loopback at 40ms is probably OK.
What are the soundcard buffer/period?
You can either configure your PCM device with custom period/buffer sizes and tell the alsa client to use it, or most alsa clients offer this as configuration. Henrik will know right away...