Yes, very easily. My main setup is a LXmini with 4 sub channels, so 8 channels total. I've been doing this for the last 6 months and it is great. I've measured the response compared to miniDSP and it is identical. I have the plans for the LX521.4 but have not built it, I've developed an initial configuration file for the LX521.4 with CamillaDSP but have not fully checked it yet.
Michael
Merry christmas!
Allpass filters should obviously not cause any HF rolloff. Can you post the plots for this config from the plotting script?
The 8to8 mixer doesn't appear to be doing anything, you can just as well remove it.
I will try to get the map plotter working and post the script.
The 8to8/AllPass mixer is a precursor to what is coming next. I am using the AllPass filters as place-holders to make sure I haven't adversely impacted anything before adding the specific driver correction filters next.
LOL, I haven't used this feature in a long time and ssh'd in to use the CLI. When I ran it the 1st time, I got a warning that more than 20 images were loaded and no images were written to the hard drive. I suppressed the warning in python and the reran it. Still no image files written to the hard drive. It then occurred to me it may be opening windows on the remote machine and sure enough, here it is.
The left channel propagates to all even channels.
The right channel propagates to all odd channels.
The topology is as expected.
The L_HOUSE_FIR and R_HOUSE_FIR's are both ALLPASS_FIRs (for the initial tests)
The ALLPASS_FIRs in the final step will hopefully be replaced with unique driver correction filters.
This is a test configuration to learn the tool and may change in its final incarnation.
Everything looks as anticipated. Note: The bass and mids are intentionally muted because I am measuring the sub relative to the tweeter. I added a few more variable text substitutions in Alsa_CDSP so I can quickly modify the config file (e.g. mute [Sub|Bass|Mid|Tweet], swap FIR sets based on playback sampling frequency, swap stereo House Curves, etc.)
The left channel propagates to all even channels.
The right channel propagates to all odd channels.
The topology is as expected.
The L_HOUSE_FIR and R_HOUSE_FIR's are both ALLPASS_FIRs (for the initial tests)
The ALLPASS_FIRs in the final step will hopefully be replaced with unique driver correction filters.
This is a test configuration to learn the tool and may change in its final incarnation.
Everything looks as anticipated. Note: The bass and mids are intentionally muted because I am measuring the sub relative to the tweeter. I added a few more variable text substitutions in Alsa_CDSP so I can quickly modify the config file (e.g. mute [Sub|Bass|Mid|Tweet], swap FIR sets based on playback sampling frequency, swap stereo House Curves, etc.)
Thanks Henrik.
It looks like the ALLPASS (same as the current HouseFilter) filter maybe the culprit. It appears as a flat line in RePhase and in REW but not in the plot function. It was created in RePhase without any XO, frequency or phase settings enabled with the same file generation parameters as the XO filters (# taps, centering, windowing, sample rate, 64-bit float, etc.).
Do you want all of the step images as well ?
Sub 50Hz Low Pass
Bass [50-250]Hz Band Pass
Mid [250-3k]Hz Band Pass
Tweet 3kHz High Pass
All Pass ???
All Pass ???
If I understand this correctly, the Step is @ 94.2% causing the high frequency rolloff to worsen the more times the "not-so-all-pass" is applied (e.g. not 1 x 1 = 1, but 0.942 x 0.942= 88.7% of max high frequency on 2nd application and 94.2% on first application). Need to figure out a way to make a "clean allpass" filter.
The ALL-SPL plot shows the HF gets rolled off by at least 1 octave when the 3rd ALLPASS step is added.
I am trying to substitute a delay of the same duration as the ALLPASS as an alternative strategy.
Ok! Do you get the same result if you leave out the 8to8 mixer and just add the allpass to the list of filters before? Could you show the plot where the rolloff can be seen?
There could be a bug in the plotting script. It uses some simplifications to get the frequency response of a series of several filters. I would guess this config works fine in camilladsp itself.
There could be a bug in the plotting script. It uses some simplifications to get the frequency response of a series of several filters. I would guess this config works fine in camilladsp itself.
I just reworked the pipeline to use delays vs the AllPass FIR and get the same behavior so I must be doing something else wrong that I do not understand yet.
This (Sub/Tweeter) plot looks the same way (HF rolloff @ 7kHz) if I use delays or the ALLPASS FIR in the 3rd stage.
Blue - 2 Stage HF extension to over 20kHz
Green - 3 Stage HF rolloff @ 7kHz [ delay(743.039ms) or ALLPASS FIR (743.039ms) ]
Last edited:
I agree that it is likely a measurement issue and likely the result of the additional delay that you are adding. I’ve observed similar issues when making measurements with REW using airplay (which adds delay). See thread below for more info.
https://www.audiosciencereview.com/...lay2-vs-direct-hdmi-input-measurements.20585/
Michael
https://www.audiosciencereview.com/...lay2-vs-direct-hdmi-input-measurements.20585/
Michael
Since REW does not offer playing to CamillaDSP, I am using REW's 176.4kHz generated sweep files (with timing chips) and an aplay script to play them into Alsa_cdsp/CamillaDSP at native rates.
FWIW, I submitted a REW feature request to optionally spawn a bash-script file (with the path and filename of the selected sweep file) when REW starts the "record from file" so Linux users could write to interfaces (such as CamillaDSP or a RPC) that REW currently does not support (and bypass REW's plughw/Pulse interface).
The only thing that changes is using the 2 or 3 step config files (and my coffee cup location =).
The mic preamp is slave clock sync locked to the DAC's clock.
CamillaDSP is writing to "hw:dac8" to bypass the Pulse "plughw:dac8". REW appears to only use the Pulse "plughw" interface.
The sweep file, FIR filters, capture and playback rates are all 176.4kHz so no rate changes should be involved.
FWIW, I just updated Alsa_cdsp to automatically calculate FIR duration from the specified playback samplerate and # of filter taps to populate a new $tap_delay_ms$ token assuming a delay takes less CPU cycles than an ALLPASS FIR.
Since playback is "from file" and everything goes through the same pipeline (including the timing chirps), REW should not be able to detect a constant delay in playback any more than it would if you manually started the playback sooner or later.
Last edited:
I assume you are using a loopback timing reference? Try an acoustic timing reference and see if the results change. As I mentioned in my experience REW does not do well with large constant delays when using a loopback timing reference.
You could also try playing white noise and see if you observe a similar rolloff.
Michael
You could also try playing white noise and see if you observe a similar rolloff.
Michael
Hi Michael,
I am not using a loopback in REW nor in ALSA. I am using the REW sample-rate specific generated sweep files so I can measure through the CamillaDSP filter pipeline. The embedded fore and aft timing chirps are the timing references in the generated sweep wav files.
The sweep files contain both the sweep and the fore and aft gating timing chirps so everything in the playback file "should be" time-delay shifted by the same amount.
Being such, REW should not detect any delays because everything gets shifted by the same amount plus how long it takes me to start the playback script. REW should not be able to determine if the delay is in the filter or in the time it takes me to manually start the playback script or a combination thereof. All of the following scenarios should be indistinguishable by REW unless I am missing something.
- [---chirp---s w e e e e e p---chirp---]
- [human delay][---chirp---s w e e e e e p---chirp ---]
- [human delay + filter delay][---chirp---s w e e e e e p---chirp ---]
Last edited:
My RTA is REW.
What I could try is doubling the delay in stage one and omit stage 3 so I theoretically end up with the same total delay.
Yes, I am suggesting using the RTA functionality in REW. Play full range periodic white noise and observe the response in REW's RTA to see if you see high frequency roll off like you do with the frequency sweeps.
Also, when troubleshooting you might want to use a DAC -> ADC measurement path to completely eliminate the mic / speaker / amplifier variables.
Michael
Also, when troubleshooting you might want to use a DAC -> ADC measurement path to completely eliminate the mic / speaker / amplifier variables.
Michael
You guys are spot on !!!
I got rid of the 3rd step and varied the length of the delay in the 1st step. As the delay increased, the HF cutoff got worse until it cut off the entire tweeter as well as the aft timing chirp.
I went into Audacity, copied a bunch of silence from before the 1st timing chip and added it after the end of the aft timing chip in the generated sweep file increasing the trailing length by more than the delay.
Problem solved (or at least identified).
It appears the measurement sweep in REW needs more silence appended after the last gating timing chirp or something in the [aplay->alsa_cdsp->CamillaDSP] playback chain is truncating the end of the file playback equal to the aggregate delay length. It also explains the steep HF cutoff slope.
Last edited: