That is a great idea, never considered that option. I don't have room for a full blown AV receiver at my computer/listening desk, but I see there are a couple limited "HDMI Extractors" but not many options to choose from in the 7.1 configuration.
A couple of the small DAC/Amps like the Topping MX3 might also work out OK.
Thanks
This is very true, former top-line AVRs are being offered for next to nothing in perfect condition because nobody wants them without 4k/60Hz. A friend of mine had a hard time selling one large Onkyo with 4k/30Hz only.
Their other advantage is class II isolation (a large properly designed and tested transformer) even though having total power of many hundred watts. A lot of (expensive) regular stereo amps these days are mere class I (cheaper build), without balanced inputs, causing ground loops.
Last edited:
Just HDMI. For this to work, the receiver must of course be able to receive uncompressed PCM over HDMI. It must also be possible to turn off any processing done by the receiver, but I believe pretty much all of them have some form of "direct" mode.
I should mention that although I believe it should work just fine, I havent actually tested this
Nice chart.
Eventhrough i dont use it (yet?) i missed the understanding of where the resampler was in the chain.
Well i have something on my mind.
I have created some BiQuad (PK) Pre-correction.
For a start i used the REW generated one's. And took a remeasure at 44100; they do a great job and it's working as expected. I have to save the REW generated one's at all the samplerates 44100 ... 192000, and manually convert them and copy/paste into .yml at all samplerates etc... Doable but time consuming.
If i export the REW BiQuads they are no longer samplerate dependant so i assume that camilladsp will calculate the BiQuads given at the .yml files samplerate ??? This would make my life so much easier.
Is this correct ?
Good day there.
Jesper.
Eventhrough i dont use it (yet?) i missed the understanding of where the resampler was in the chain.
Well i have something on my mind.
I have created some BiQuad (PK) Pre-correction.
For a start i used the REW generated one's. And took a remeasure at 44100; they do a great job and it's working as expected. I have to save the REW generated one's at all the samplerates 44100 ... 192000, and manually convert them and copy/paste into .yml at all samplerates etc... Doable but time consuming.
If i export the REW BiQuads they are no longer samplerate dependant so i assume that camilladsp will calculate the BiQuads given at the .yml files samplerate ??? This would make my life so much easier.
Is this correct ?
Good day there.
Jesper.
Last edited:
Yes if you use "Peaking" filters with freq, q, and gain then CamillaDSP will calculate the biquad coefficients for the current samplerate. I would say that you should only use the "Free" type if you need an unusual filter that CamillaDSP can't calculate the cofficients for.
Hello.
So i assume i got it right now, my workflow will be like this then :
1. Create BiQuad's in REW as PRE-filter
2. Configure an .yml file for each samplerate i need
3. Setup thoose .yml with the BiQuads
4. Remeasure with BiQuad's in place at/with the .yml file configured for 48000 (my mic's native)
5. Samplerate convert this measurement (Left+Right) to 44100, (48000), 88200, 96000 I will use Audacity for a start for this.
6. Create FIR filters, for thoose samplerates
7. Configure the .yml with the FIR's, again at right samplerate.
So e.g filter for 96000 will be like this :
.yml. ::
Samplerate 96000
...
..
filters:
BiQuads
FIR Left
FIR Right
...
pipeline:
BiQuads
FIR Left
FIR Right
I hope i got it right now?
The resampling thing is something i'am not sure is correct to do, but if i use this workflow i cannot see any other way of doing it when my mic's max measure samplerate is 48000.
Hope some clever ones would chime in ?
Take care out there guy's
Jesper.
Got it thank's.
So i assume i got it right now, my workflow will be like this then :
1. Create BiQuad's in REW as PRE-filter
2. Configure an .yml file for each samplerate i need
3. Setup thoose .yml with the BiQuads
4. Remeasure with BiQuad's in place at/with the .yml file configured for 48000 (my mic's native)
5. Samplerate convert this measurement (Left+Right) to 44100, (48000), 88200, 96000 I will use Audacity for a start for this.
6. Create FIR filters, for thoose samplerates
7. Configure the .yml with the FIR's, again at right samplerate.
So e.g filter for 96000 will be like this :
.yml. ::
Samplerate 96000
...
..
filters:
BiQuads
FIR Left
FIR Right
...
pipeline:
BiQuads
FIR Left
FIR Right
I hope i got it right now?
The resampling thing is something i'am not sure is correct to do, but if i use this workflow i cannot see any other way of doing it when my mic's max measure samplerate is 48000.
Hope some clever ones would chime in ?
Take care out there guy's
Jesper.
I think the easiest way to get started would be to get a home theater receiver. They have all you need: they can receive many channels of uncompressed audio over HDMI, have built in dacs, volume control and even power amps.
I think many are replacing their older receivers to get 4K-support, so you might be able to find really good ones cheaply on the used market. If I were to start over I would probably go this route. Building the dac took waaay to much time..
I am working on a user-friendly solution for FIR filtering with Brutefir on a Raspi 3B+. I have built a two-way ripolar loudspeaker in a concrete housing. For now 4 channels are sufficient.
For input I use a Hifiberry Digi-IO+ card with SPDif input and for output I use the Raspi HDMI output.
If you want to use the AV receiver X.Y as DAC and amplifier, you can only use the X channels, because the Y channels are limited for subwoofers. I haven't got them running yet.
The HDMI extractors also have the same output. For a 4-way speaker you will then need a 9.1 AV receiver. My HDMI extractor needs 96K output if I use LPCM. AC3 input is also possible with lower sampling rates. But AC3 is only possible with Linux up to 5.1.
I will also try CamillaDSP when I have finished Brutefir.
Good luck with the AVs
.
Thanks for a very useful info. Do regular PC HDMI outputs support the 10ch PCM audio?
No Linux LPCM HDMI output support 8 channels only. But I did not found any 8.X AV Receiver. There is a 8 channel HDMI DAC Evolve II-4K HDMI v2.0 / Multi-Channel DAC - Essence For High Res Audio but it is still on transfer from US. I will test this DAC.
Good Day Roland
Good Day Roland
Some benchmarking ...
I set up a pipeline with a "rollercoaster type" SRC parcours from 44.1kHz to 44.1kHz. This pipe is completely useless in terms of audio listening, but not so useless to cumulatively collect possible garbage emerging from it's 6 different stages of SCR:
File Input by Camilladsp | SRC 44.1->192 | 192->48 | 48->176.4 | 176.4->96 | 96->88.2 | 88.2->44.1 | File output by Camilladsp
So a total of eight instances of camilladsp, six of them configured as SRC's. The pipe was run in all different quality presets such as FastSync, FastAsync, BalancedSync, BalancedAsync, AccurateSync and AccurateAsync.
The input signal was a Float64-Bit file, containing six sinewaves, equispaced by one octave along with frequencies such as to produce minimal artefacts while windowing the result @44.1kHz (to avoid swamping the results of the SRC into the artefacts of the windowing itself) The outcoming files were windowed with a Kaiser240 window.
FastSync - All artefacts are <165dB:
MT1_FastSync.png
FastAsync: - All artefacts are <165dB
MT2_FastAsync.png
BalancedSync: - All artefacts are <210dB. In terms of artefacts level and artefacts density this one may become my favourite for static SRC's:
MT3_BalancedSync.png
BalancedAsync: - All artefacts are <165dB
MT4_BalancedAsync.png
AccurateSync: - All artefacts are <230dB
MT5_AccurateSync.png
AccurateAsync: - All artefacts are <230dB
MT6_AccurateAsync.png
Another difference between Fast, Balanced and Accurate is also the behavior of theirs filters. All filters provide decent attenuations at 22050Hz, thus well avoiding violation of the sampling (Nyquist-Shannon) theorem. Best performer is Accurate, then Balanced, then Fast, "as intended by the inventor". The input file contained Float64bit white noise, this time:
WN9_Camilla_zoom.png
Then -what happens visually to my synthesized "torture impulse"? Despite the demanding, cascaded transformations it remains more or less well shaped - better than I had expected:
F9_Camilla.png
And last, not least - I wanted to benchmark against the soxr library. Forget it / no use. Resample-soxr had to vomit riding this roller-coaster. Maybe it's a bug in it's stomach (e.g. within the soxr library) provoking this kind of annoyance:
WN9_soxr.png
I set up a pipeline with a "rollercoaster type" SRC parcours from 44.1kHz to 44.1kHz. This pipe is completely useless in terms of audio listening, but not so useless to cumulatively collect possible garbage emerging from it's 6 different stages of SCR:
File Input by Camilladsp | SRC 44.1->192 | 192->48 | 48->176.4 | 176.4->96 | 96->88.2 | 88.2->44.1 | File output by Camilladsp
So a total of eight instances of camilladsp, six of them configured as SRC's. The pipe was run in all different quality presets such as FastSync, FastAsync, BalancedSync, BalancedAsync, AccurateSync and AccurateAsync.
The input signal was a Float64-Bit file, containing six sinewaves, equispaced by one octave along with frequencies such as to produce minimal artefacts while windowing the result @44.1kHz (to avoid swamping the results of the SRC into the artefacts of the windowing itself) The outcoming files were windowed with a Kaiser240 window.
FastSync - All artefacts are <165dB:
MT1_FastSync.png
FastAsync: - All artefacts are <165dB
MT2_FastAsync.png
BalancedSync: - All artefacts are <210dB. In terms of artefacts level and artefacts density this one may become my favourite for static SRC's:
MT3_BalancedSync.png
BalancedAsync: - All artefacts are <165dB
MT4_BalancedAsync.png
AccurateSync: - All artefacts are <230dB
MT5_AccurateSync.png
AccurateAsync: - All artefacts are <230dB
MT6_AccurateAsync.png
Another difference between Fast, Balanced and Accurate is also the behavior of theirs filters. All filters provide decent attenuations at 22050Hz, thus well avoiding violation of the sampling (Nyquist-Shannon) theorem. Best performer is Accurate, then Balanced, then Fast, "as intended by the inventor"
. The input file contained Float64bit white noise, this time:WN9_Camilla_zoom.png
Then -what happens visually to my synthesized "torture impulse"? Despite the demanding, cascaded transformations it remains more or less well shaped - better than I had expected:
F9_Camilla.png
And last, not least - I wanted to benchmark against the soxr library. Forget it / no use. Resample-soxr had to vomit riding this roller-coaster. Maybe it's a bug in it's stomach (e.g. within the soxr library) provoking this kind of annoyance:
WN9_soxr.png
Attachments
Goodmorning here (at least where i am)
I am trying with some success and failure to get his flow running.
My .yml (flow)file goes like this :
Camilla is calculating BiQuads (working as expected)
Fir's applied
Gaincontrol applied
Is it possibel to run two instances of camilladsp insted of using BiQuads and fir's in the same one?
If this is possible i could much easier control what i am trying to do.
The BiQuads are used as "prefilter", but using "real" fir's chained would be easier for me.
Snip from my attached .yml file:
Jesper.
(at least where i am)I am trying with some success and failure to get his flow running.
My .yml (flow)file goes like this :
Camilla is calculating BiQuads (working as expected)
Fir's applied
Gaincontrol applied
Is it possibel to run two instances of camilladsp insted of using BiQuads and fir's in the same one?
If this is possible i could much easier control what i am trying to do.
The BiQuads are used as "prefilter", but using "real" fir's chained would be easier for me.
Snip from my attached .yml file:
Jesper.
I think you could chain multiple instances together by running them through a chain of alsa loopback devices. I'm not entirely clear on how this would make things easier though, could you elaborate?
I've been daydreaming about a web user interface for camillaDSP- I haven't had time to start writing anything yet though but it's good to understand different use-cases to see how they are (or aren't) catered for in a user interface.
Chris
hochopeper, let me try to explain what my issues are.
If you look at the attached file from my previous post you can see that making camilladsp use BiQuads as Pre-filter is kindoff a bit complicated.
If i could chain two instances instead i could use normal fir's as Pre-filter instead of BiQuads!
But when i think about it i see that it could also be complicated duo to timing etc. The camilladsp i'am running is using the camilladsp rate-adjust for this.
But if both if possible camilla's could use this maybee it would work without problems?
So while i am at it i have some other quistions,
When using fir's i sometimes have difficulties using .wav's (L & R seperated); using the same filters as .bin (L & R seperated) seems to run better?
Problem here is that the only program i have which generate .bin fir's are rePhase, but i would also like to try the DRC-FIR & DRC-Designer, which i think only can generate .wav's. -But maybe i can convert them? i don't know yet.
The attached picture is my measurements at the sweetspot before and after BiQuads are added to camilladsp (Pre-filter)
With the BiQuad corrected measurements my plan is to generate the fir's. Reason for this is that the fir's are less heavy and easier for it to correct, when it's pre-filtered, ok?
Jesper.
If you look at the attached file from my previous post you can see that making camilladsp use BiQuads as Pre-filter is kindoff a bit complicated.
If i could chain two instances instead i could use normal fir's as Pre-filter instead of BiQuads!
But when i think about it i see that it could also be complicated duo to timing etc. The camilladsp i'am running is using the camilladsp rate-adjust for this.
But if both if possible camilla's could use this maybee it would work without problems?
So while i am at it i have some other quistions,
When using fir's i sometimes have difficulties using .wav's (L & R seperated); using the same filters as .bin (L & R seperated) seems to run better?
Problem here is that the only program i have which generate .bin fir's are rePhase, but i would also like to try the DRC-FIR & DRC-Designer, which i think only can generate .wav's. -But maybe i can convert them? i don't know yet.
The attached picture is my measurements at the sweetspot before and after BiQuads are added to camilladsp (Pre-filter)
With the BiQuad corrected measurements my plan is to generate the fir's. Reason for this is that the fir's are less heavy and easier for it to correct, when it's pre-filtered, ok?
Jesper.
Attachments
Hi TNT!
When you save the Peak (PK) EQ from REW, thoose are not samplerate dependant, so if you let camilla calculate the BiQuads from that, you can use the same on all samplerates. So it only have to be done one time for L & R.
You can see my .yml file i posted some posts ago how it looks.
This .yml i can change the samplerate and ofcause the fir filter has to fit the samplerate.
Jesper.
Attachments
DRC_FIR itself generates the correction as raw 32 bit float with .pcm extension. This is the same data format as MiniDSP bin file except it has .bin on the end instead of .pcm change it to bin manually and it will work. I had no luck trying to reconvert the file back from wav to pcm or bin and wasted a lot of time trying to figure out why, when all I needed was to just not convert it in the first place
Gmad's DRC scripts use sox commands embedded in the script to convert the pcm files in a stereo .wav as most Windows and Mac Convolver's want a wav file for the impulse response, even though it is still 32 bit float numbers inside. DRC Designer might do the same thing.
Henrik, when you said before you can add as many filters as you like does that mean you can add one convolver filter after another or chained with PEQ or biquads inbetween?
I think this is what Jesper wants to do, run two convolution filters chained together one after the other