OK, and agreed. Maybe his might be a fun trial-and-error investgative project. If so, then I certainly will publish my struggles and findings.
Last edited:
How about a new column under Files that says "Comp"... For a "diff" between 2 (or more?) configs and an output (to file or/and GUI) that presents the differences?
In the end for me when all have been measured it's about fine tuning (0,1 dB.... etc) and I end up in quite man files with many PEQs... it's a troublesome situation but I know there is useful info in there... just that it's really hard to harvest...
//
In the end for me when all have been measured it's about fine tuning (0,1 dB.... etc) and I end up in quite man files with many PEQs... it's a troublesome situation but I know there is useful info in there... just that it's really hard to harvest...
//
I'm sure this has been answered but, Is camilladsp capable of multiple fir filters while playing movies? I wonder what latency would be acceptable.
What sort of FIR filters are you looking at applying (tap centering, length, sample rate, etc)?
High tap, linear phase filters will have a lot of inherent latency regardless of DSP used. The only way to achieve good lip sync when using these is to delay video as mentioned by @TNT. You can apply high tap, minimum phase FIR filters with minimal delay.
CamillaDSP has a relatively high baseline latency without any filters applied. I would anticipate at least 10 ms as a baseline. I'd personally try to keep total latency (baseline + FIR latency) below than 25 ms in an A/V application. Depending on your sensitivity to lip sync you may be able to tolerate more delay. For reference a 1400 tap, linear phase FIR filter at 48000 Hz will have about 15 ms latency.
Michael
High tap, linear phase filters will have a lot of inherent latency regardless of DSP used. The only way to achieve good lip sync when using these is to delay video as mentioned by @TNT. You can apply high tap, minimum phase FIR filters with minimal delay.
CamillaDSP has a relatively high baseline latency without any filters applied. I would anticipate at least 10 ms as a baseline. I'd personally try to keep total latency (baseline + FIR latency) below than 25 ms in an A/V application. Depending on your sensitivity to lip sync you may be able to tolerate more delay. For reference a 1400 tap, linear phase FIR filter at 48000 Hz will have about 15 ms latency.
Michael
A post on Audio Science Review regarding speaker cross talk cancellation piqued my interest on this subject. After a bit of research I decided to try it out on my main 2 speaker stereo system which uses camilladsp. The implementation I did uses camilladsp for the processing and is based on Recursive Ambiophonic Crosstalk Elimination (RACE) as per the AES paper 360° Localization via 4.x RACE Processing by Ralph Glasgal.
When setup properly, I find the processing to significantly improve sound stage width and depth as well as improved clarity. There are however serious limitations the main one being that it will only work for a single listening position. Also, how well the processing works is dependent on the recording techniques used. Not necessarily a limitation but the speaker placement should be at a narrow angle of 20 to 30 deg instead of the conventional 60 deg. Left and right speakers must be positioned very carefully with equal distance to the listener within of about 1 cm for best results.
In my case, for serious listening I am always alone and in the same listening position so the processing is always effective. For the odd times when listening with family and friend or when I am not in my listening chair, I simply turn off the processing. For some recordings the sound stage width is too large, in these cases I pan the L and R to the center position to reduce the width, this seems to work OK.
The processing is recursive, here is a pipeline with 3 stages of cancellation.
For the processing to be effective about 20 stages are needed. Also in order to have enough resolution in the time delay, a sample rate of 96k or higher should be used.
Time delay and attenuation can be adjusted on the fly using custom shortcuts. If the left and right speakers are not at the same distance to the listener, this must be corrected with speaker delays values which are also available via custom shortcuts. There are shortcuts to mute the left or right inputs. This can be used when adjusting the delay and gain values so that when the right input signal is muted the left will appears as far left as possible and vice versa for the right. There is the option of changing the passband frequencies for the processing via sliders as well as bypassing the passband filters so that the processing is done full bandwidth.
If you are interested in trying this out see the attached files with the elements that will need to be imported or pasted in your config:
Camilladsp configuration file which has the required filters, mixers and pipeline elements for RACE, not sure how to attach a yml file so this is saved as a text file.
Camillagui config custom shortcuts for the above (V3 is required)
Please do initial testing with amp turn down just in case. The processing may add up to about 3 to 5 dB to the level at times so ensure to allow for this by setting camilladsp volume accordingly.
Once the optimum delay and attenuation values are found, the above cumbersome pipeline can be replaced via convolution. I will do a separate post for the implementation via convolution.
When setup properly, I find the processing to significantly improve sound stage width and depth as well as improved clarity. There are however serious limitations the main one being that it will only work for a single listening position. Also, how well the processing works is dependent on the recording techniques used. Not necessarily a limitation but the speaker placement should be at a narrow angle of 20 to 30 deg instead of the conventional 60 deg. Left and right speakers must be positioned very carefully with equal distance to the listener within of about 1 cm for best results.
In my case, for serious listening I am always alone and in the same listening position so the processing is always effective. For the odd times when listening with family and friend or when I am not in my listening chair, I simply turn off the processing. For some recordings the sound stage width is too large, in these cases I pan the L and R to the center position to reduce the width, this seems to work OK.
The processing is recursive, here is a pipeline with 3 stages of cancellation.
For the processing to be effective about 20 stages are needed. Also in order to have enough resolution in the time delay, a sample rate of 96k or higher should be used.
Time delay and attenuation can be adjusted on the fly using custom shortcuts. If the left and right speakers are not at the same distance to the listener, this must be corrected with speaker delays values which are also available via custom shortcuts. There are shortcuts to mute the left or right inputs. This can be used when adjusting the delay and gain values so that when the right input signal is muted the left will appears as far left as possible and vice versa for the right. There is the option of changing the passband frequencies for the processing via sliders as well as bypassing the passband filters so that the processing is done full bandwidth.
If you are interested in trying this out see the attached files with the elements that will need to be imported or pasted in your config:
Camilladsp configuration file which has the required filters, mixers and pipeline elements for RACE, not sure how to attach a yml file so this is saved as a text file.
Camillagui config custom shortcuts for the above (V3 is required)
Please do initial testing with amp turn down just in case. The processing may add up to about 3 to 5 dB to the level at times so ensure to allow for this by setting camilladsp volume accordingly.
Once the optimum delay and attenuation values are found, the above cumbersome pipeline can be replaced via convolution. I will do a separate post for the implementation via convolution.
How do you keep that practically? A tiny move of your head is more than 1cm, IMO
I didnt realize there were different types... i always did a inverse convolution min phase.
This probably rules out cdsp for me then... maybe hangloose convolver has better latency numbers. As far as i know my ps5 doesnt have lip sync delay functions, nor my optoma projector.
I'm using it with short fir filters and a tv, no problems. The tv doesn't have any way to set a delay.
Awesome thanks. Its my understanding that less taps can be used for mids and highs and iir can be used for sub bass so that could be a solution.. my intent is to build a dsp 8 channel dac with iancanada mcfifo. I would like my convolutions to incorporate the crossovers as well. All this is a side note really but thats my goal.
If you are using minimum phase FIR filters there should not be any issues as long as you aren't using middle centering.
I've used CamillaDSP with both IIR and FIR in A/V applications for about 4 years now, latency is not a concern with reasonable FIR filter design.
The primary contributor to FIR latency is the FIR filter itself. If you are using a linear phase, 16K tap FIR filter at 48000 Hz you will have long latency (170 ms) regardless of the convolver you use.
For reference, miniDSP products with Dirac have around 25 ms latency. 10-20 ms baseline latency from CamillaDSP is not unreasonable for an A/V application unless you are adding long linear phase filters on top of that.
Michael
The idea is to carefully set the speaker distance to the target sitting position. The system works well when sitting within a few inches from the target position.
The system is effective when left and right speaker sound travel distance is closely matched. Because of the geometry of using a narrow speaker angle, moving your head side to side from the target sitting position has much less impact on this travel distance than an incorrect forward to back speaker position. Also moving your head forward or backward from the target position has little impact as this maintains equal travel distance.
I would not recommend using a fifo if you want to keep latency down!
This is exactly what I do, my fir filters (at 44.1kHz) are just 1024 taps, and I use IIR to take care of the low frequency room resonances.
It would be quite easy to add a button to compare a file with the config currently loaded in the gui, the diff function already exists because the undo/redo uses it. Added to the todo-list!
May I ask how you do the transition from one config to the other using Shortcuts? It seems gradual and a bit delayed...
//
//
This is how I implemented RACE using FIR filters in camilladsp.
This is a plot of the two filters used for a delay of 115 usec and gain of -2.75 dB, both are applied to each channel input signal. The blue filter output is sent to that channel output while the orange filter is sent to the cross channel output. For example if we are processing the left input channel, the signal of the left input channel is convolved with the blue impulse response and sent to the left speaker while the signal of the left input channel is convolved with the orange impulse response and sent to the right speaker.
These filters generate the recursive cancellation signals that alternate between left and right speakers for the specified time interval and decrease in amplitude.
This is an image of the pipeline
The attached python program is what I use to generate the filters which will need to be saved to your camilladsp coefficient directory. My programming skills are limited, this works for me in linux but not sure for other platforms. Not sure how to attach a .py file so it is saved as a text file.
The attached yml (saved as a text file) file contains the filters, mixers and pipeline to be pasted into your config file. You should be able to change it back to a yml file and import the relevant sections via the camilla gui.
You will need to modify the raceir and raceXir filters in the config to point to the correct coefficients files that you generated with the above python program. Channel 0 of the wave file race_delayxxxattenuationxxfxxxxx.wav is for raceir and channel 1 is for raceXir.
I use the same gui shortcuts that I use for the parametric version but note that the gain and delay will be grayed out as these parameters are not adjustable when using the FIR filters. The section to be added in the Camilla gui config is attached.
This is a plot of the two filters used for a delay of 115 usec and gain of -2.75 dB, both are applied to each channel input signal. The blue filter output is sent to that channel output while the orange filter is sent to the cross channel output. For example if we are processing the left input channel, the signal of the left input channel is convolved with the blue impulse response and sent to the left speaker while the signal of the left input channel is convolved with the orange impulse response and sent to the right speaker.
These filters generate the recursive cancellation signals that alternate between left and right speakers for the specified time interval and decrease in amplitude.
This is an image of the pipeline
The attached python program is what I use to generate the filters which will need to be saved to your camilladsp coefficient directory. My programming skills are limited, this works for me in linux but not sure for other platforms. Not sure how to attach a .py file so it is saved as a text file.
The attached yml (saved as a text file) file contains the filters, mixers and pipeline to be pasted into your config file. You should be able to change it back to a yml file and import the relevant sections via the camilla gui.
You will need to modify the raceir and raceXir filters in the config to point to the correct coefficients files that you generated with the above python program. Channel 0 of the wave file race_delayxxxattenuationxxfxxxxx.wav is for raceir and channel 1 is for raceXir.
I use the same gui shortcuts that I use for the parametric version but note that the gain and delay will be grayed out as these parameters are not adjustable when using the FIR filters. The section to be added in the Camilla gui config is attached.
It seem to change efter 1 or 2 seconds and in a fading style. I dont get that "snap" change sensation. No FIR involved.
//