@TNT seems weird. An unused fir filter won't do any harm. Biquads are not perfectly samplerate-independant, there is still frequency warping at high frequencies. But that should just get better at the higher samplerate..
Could you post the config? Ideally both the 44.1 and 96kHz versions.
Could you post the config? Ideally both the 44.1 and 96kHz versions.
Determining pipeline processing time.
I'm trying to determine how much delay / time is taken by a pipeline. is it channel independent based on number of filters or "aligned" to the longest? is there an easy way to work this out? I want to be able to determine the required delay in a 3 way for midrange and woofer. I have measured Z offset so know accoustically exactly the voice coil centres relative to listening / measuring axis. When I use that value, I don't get the reverse null symmetry of my crossover model meaning there is some extra processing delay in my chain I am not allowing for (could be alsa too). What I want to do now is account for filter processing time and add that in to the delay filters for the channels that require them.
I'm trying to determine how much delay / time is taken by a pipeline. is it channel independent based on number of filters or "aligned" to the longest? is there an easy way to work this out? I want to be able to determine the required delay in a 3 way for midrange and woofer. I have measured Z offset so know accoustically exactly the voice coil centres relative to listening / measuring axis. When I use that value, I don't get the reverse null symmetry of my crossover model meaning there is some extra processing delay in my chain I am not allowing for (could be alsa too). What I want to do now is account for filter processing time and add that in to the delay filters for the channels that require them.
Thanks Henrik that's good to know.
No I'm pure IIR. I'm just surprised my measured Z offset as a delay doesn't give as deep LR reverse null as I was expecting. Must be something wrong with my acoustic measurements.
I'm finding I get a pop / click when I use the websocket to switch between configurations. The 2 I am switching between have identical devices and mixers sections. It's just the filters that are changing. Is there a setting or a websocket command I should issue to drain or pause whilst the config loads? what could be causing the pop / click?
I have noticed it is better if no other applications are using the dmix / dsnoop ALSA device that camilla is listening / playing to, but the click is still there.
My devices section:
I have noticed it is better if no other applications are using the dmix / dsnoop ALSA device that camilla is listening / playing to, but the click is still there.
My devices section:
Code:
devices:
# for measuring in REW - use 48KHz all the way through, or REW misses the timing reference or you get some echo effect playing through a plug
#samplerate: 48000
# for all playback from MPD
samplerate: 44100
chunksize: 4096
#target_level: 2048
queuelimit: 1
enable_rate_adjust: true
capture:
type: Alsa
channels: 2
device: "hw:Loopback,1"
format: S16LE
playback:
type: Alsa
channels: 8
device: "hw:0,1"
format: S16LE
mixers:
to8chan:
channels:
in: 2
out: 8
mapping:
- dest: 0
mute: false
sources:
- channel: 0
- dest: 1
mute: false
sources:
- channel: 1
- dest: 2
mute: false
sources:
- channel: 0
#inverted: true
- dest: 3
mute: false
sources:
- channel: 1
- dest: 4
mute: false
sources:
- channel: 0
- dest: 5
mute: false
sources:
- channel: 1
- dest: 6
# Subwoofer - send both chanels (unfiltered)
mute: false
sources:
- channel: 0
gain: -7
- channel: 1
gain: -7
- dest: 7
mute: true
sources:
- channel: 1Merry Christmas everyone,
Dear Henrik, thank you for all of your work, great tool.
This will be a long post, I'll try to keep it brief and elaborate later - if required.
I have been struggling with professional use of CamillaDSP for last 2 months.
It's difficult for me to contribute in other way than to provide my feedback with many combinations of hardware.
2 months ago, when i have started playing around with combination of CDSP on a server + firewire interface, the only problems I had were:
About 2-3 weeks ago something changed, completely new system with same hardware and installation method (audioscience review tutorial):
The system freeze means dropped connection via web GUI and SSH as well as console notification:
NMI Watchdog detected hard LOCKUP on CPU XX
The only thing I can do at this point is to do a hard reset of the machine, or power cycle.
Needles to say this is unacceptable from a stability point of view.
Tested Hardware:
PCs:
Firewire PCIe cards:
Firewire interfaces (all of them made by MOTU):
A lot of different FW cables, various lenghts and makes
Tested Software:
Firewire drivers:
Kernels:
Distros:
CDSP versions:
Every combination of the above gives the same result. Even if I can make it work ‘stable’, the chunksize is so big that latency without FIR filters is significant (above 30-40 ms).
Unstability means system lockup, as I have mentioned before. It used to work before last 2-3 weeks. My yet another conclusion is that the problem lies in dependencies, for example updated python packages? The distribution, kernel, hardware, drivers and CDSP doesn’t seem to matter.
I have invested a lot of time and funds to make it work – no success now, with a big red flag that package upgrades might ruin this software/hardware combination.
I beg you all for help, I can provide logs/configs after NYE. Even if my problem can’t be resolved – this can be a warning for everyone who wants to try to go ‘pro’ with firewire.
I also have strange problems with USB – this is for another post, but in short: MOTU UltraLite MK4 works with CDSP on Thinkcentre M900 Tiny, but changes channel-mapping while playing, without underruns/restarts of software, extremely unreliable.
Respectfully,
Tom
Dear Henrik, thank you for all of your work, great tool.
This will be a long post, I'll try to keep it brief and elaborate later - if required.
I have been struggling with professional use of CamillaDSP for last 2 months.
It's difficult for me to contribute in other way than to provide my feedback with many combinations of hardware.
2 months ago, when i have started playing around with combination of CDSP on a server + firewire interface, the only problems I had were:
- Some buffer underruns/CDSP restarts with 96k sampling frequency and 128 sample chunksize
- Rare buffer underruns/CDSP restarts with 96k sampling frequency and 256 sample chunksize
- Stalling of CDSP with 96k sampling frequency and 64 sample chunksize - recoverable, I could just change chunksize via web gui and CDSP would restart itself with stable parameters
About 2-3 weeks ago something changed, completely new system with same hardware and installation method (audioscience review tutorial):
- No buffer underruns/CDSP restarts with 96k sampling frequency and 2048 (!) sample chunksize, at least for 14-hour stability test
- Complete freezing of whole system with 96k sampling frequency and 1024 (!) sample chunksize, within minutes of running
- Complete freezing of whole system with 96k sampling frequency and 512 sample chunksize or less, right after applying changes
The system freeze means dropped connection via web GUI and SSH as well as console notification:
NMI Watchdog detected hard LOCKUP on CPU XX
The only thing I can do at this point is to do a hard reset of the machine, or power cycle.
Needles to say this is unacceptable from a stability point of view.
Tested Hardware:
PCs:
- Haswell-based Supermicro server (Xeon E3-1271 V3, X10 supermicro MB)
- Skylake-based Suprmicro server (Xeon E3-1220 V6, Asus P10 MB)
Firewire PCIe cards:
- TI-based (...)ZAY chip, 3x FW800 ports
- TI-based (...)ZAY chip, 1x FW400 + 2x FW800 ports (recommended by ‘Interfacing Linux’ guy)
- VIA – based chip with PCI bridge chip, 3x FW400
Firewire interfaces (all of them made by MOTU):
- 2 different UltraLite
- 2 different 828 MK2
- 2 different 828 MK3
- UltraLite MK3 FW
- UltraLite MK3 Hybrid
- Traveler
A lot of different FW cables, various lenghts and makes
Tested Software:
Firewire drivers:
- Takashi Sakamoto’s alsa-firewire, versions 4.17 and 5.19
- Kernel-included from 5.14 upwards
Kernels:
- almost everyone from 4.10 to 6.06
- generic
- lowlatency
- rt
Distros:
- Ubuntu desktop 18.4; 20.4; 20.10
- Ubuntu server 18.4; 20.4; 20.10
- Debian 10
- Debian 11
- Debian 12
CDSP versions:
- 1.0.0; 1.0.1; 1.0.2; 1.0.3
- no GUI and GUI 1.0.0; 1.0.1
Every combination of the above gives the same result. Even if I can make it work ‘stable’, the chunksize is so big that latency without FIR filters is significant (above 30-40 ms).
Unstability means system lockup, as I have mentioned before. It used to work before last 2-3 weeks. My yet another conclusion is that the problem lies in dependencies, for example updated python packages? The distribution, kernel, hardware, drivers and CDSP doesn’t seem to matter.
I have invested a lot of time and funds to make it work – no success now, with a big red flag that package upgrades might ruin this software/hardware combination.
I beg you all for help, I can provide logs/configs after NYE. Even if my problem can’t be resolved – this can be a warning for everyone who wants to try to go ‘pro’ with firewire.
I also have strange problems with USB – this is for another post, but in short: MOTU UltraLite MK4 works with CDSP on Thinkcentre M900 Tiny, but changes channel-mapping while playing, without underruns/restarts of software, extremely unreliable.
Respectfully,
Tom
The error message means something in kernel-space is causing the issue. Since CamillaDSP runs in user space, it can't cause this. There must be something like a driver bug, or a hardware issue. Check the kernel logs, there may be something useful.
The earlier results with som underruns with small chunk sizes seem reasonable. 256 frames at 96kHz is quite small.
Thank you all for answers,
I will check the 'non-DAC' pipeline with small chunksizes, as well as usb, also report back for potentially interested.
If the problem is indeed only firewire related - i will signal it to Takashi Sakamoto and other developers of firewire stack.
I's a shame that I don't have any other brand of firewire interface, maybe the problem is only with snd-fw-motu, not fw in general.
Best regards
I will check the 'non-DAC' pipeline with small chunksizes, as well as usb, also report back for potentially interested.
If the problem is indeed only firewire related - i will signal it to Takashi Sakamoto and other developers of firewire stack.
I's a shame that I don't have any other brand of firewire interface, maybe the problem is only with snd-fw-motu, not fw in general.
Best regards
@TNA: Chunksize 1024 frames at 96kHz means period time 2.5ms in CDSP (buffer size 2048 frames, period size 1/8 of buffer size). Below that the timing is quite tight. Chunksize 64 frames means buffer time (i.e. the timing margin) 660us, period time 160us. IMO permanent xruns are unavoidable then.
Your kernel lockups are caused by drivers, unrelated to the user-space CDSP, as explained above.
Your kernel lockups are caused by drivers, unrelated to the user-space CDSP, as explained above.
Building a CamillaDSP config for modified K-Horns.
The aim of this post is to show the process I followed to build a config file for CamillaDSP to tri-amp a pair of modified Klipschorns. A secondary aim is to provide enough information for someone to follow the procedure to build a CamillaDSP config for their own speakers.
CamillaDSP is running on a RPi4 and using a Motu Ultralight Mk5 audio interface.
This is not the only way to build a config, the methods and options I have chosen work for me.
This is not going to be another tutorial on using REW and rePhase, but there will be a lot of REW measurements shown as screengrabs. REW has excellent help and there are good tutorials on the web. For rePhase I have lots of screengrabs. The screengrabs for REW and rePhase should provide enough information to show the process being performed.
The K-Horn mods are a new top hat using B&C DCX464 coax drivers mounted on an Eliptrac horn for mid and hi. The B&C DCX464 is a 111db/W 1.4" compression horn with a 290-20,000Hz response. The K-Horn bass is about 105db/W. The only ramification of using a coax from a seperate tweeter is that the mid and hi use the same delay for time alignment. Due to horn length the bass is delayed by 5msec (far more than a standard 3 driver box) and I show how to determine this and the DSP filters required for time alignment.
Currently I am using an Allo Boss2 streamer feeding analog into a NAD receiver acting as a pre-amp (volume control & source selection) , then analog into a Motu UL5/RPi .
The outputs from the Motu UL5/RPi are balanced analog and feed a single stereo N-Core amp for left and right K-Horn bass and and a pair of XLR balanced input SMSL SH9 THX Headphone amps for mid and hi. The nominally 16ohm (tests show 12ohm) B&C DCX are 111db/W and the SH9 will put out 6W into 16ohm and 9W into 8ohm. More than enough power for a domestic system remembering that there are no passive crossovers sucking power. Also, these amps and the Motu UL5 and Raspberry Pi cost about half what I spent a few years ago on a passive steep slope crossover.
I use a Behringer ECM8000 measurement condenser mic that connects with an XLR plug to a Motu M4 audio interface. I use loopback in the M4 to provide reference timing for REW. A miniDSP UMIC will work just as well with acoustic timing for reference, an advantage of the Behringer and Motu M4 is that I can also use Open Sound Meter, a disadvantage is that I must calibrate the sound level of the Behringer each measurement session.
Software used is REW and Rephase . I run all this on Win 11 on an Asus laptop and use WinSCP for file transfer from Laptop to CamillaDSP on the RPi. Both CamillaDSP and my laptop are on a LAN.
Measurements are taken with the tip of the microphone 1m from the centre of the Eliptrac horn which is 118cm off the floor. This microphone position is generally accepted in the Klipsch community for measuring K-Horns as it all but eliminates room reflections. The listening room is 6.5m wide by 10.8m long with 2.6m ceiling. The flooring is polished hardwood with extensive rug covering, couches and furnishings. Walls are sheetrock drywall with curtained windows. Klipschorns are corner horns so the corner sheetrock is re-enforced to reduce flex as the corner wall is part of the bass horn. The floor immediately in front of the K-Horns are covered with large woolly dog beds to reduce reflection.
The basic procedure I followed is -
1. Measure drivers using REW and use REW EQ to calculate EQ settings for a flat frequency response using 1/6 smoothing. Add the EQs to the Pipeline in CamillaDSP (REW has just added the function to save EQ filters in CamillaDSP format).
2. Add Linear Phase XO in Rephase to the Pipeline in CamillaDSP
3. Measure response, set gains for each driver, determine delays for each driver go back and adjust XO frequencies to give smoothest result while taking advantage of "acoustic crossover" of the drivers.
4. After getting the delays between drivers correct, manipulate the phase in Rephase for each driver to get the Excess Phase close to zero.
5. Guild the lily by doing another EQ of the full system (80-10,000Hz) to flatten SPL peaks and troughs across the cross over regions.
Rather than fill the thread with graphs, the steps are in .pdf format as attachments, this also has the advantage of being able to zoom in on the screen dumps.
Thank you Henryk for CamillaDSP and Michael for his tutorial on setting up Camilla on a Raspberry Pi and a Motu Ultralight Mk 5. Thanks also to Cask05 for help with REW in my early days of coming to grips with DSP.
Links :
https://www.audiosciencereview.com/forum/index.php?threads/rpi4-camilladsp-tutorial.29656/
https://www.avnirvana.com/forums/official-rew-room-eq-wizard-support-forum.10/
https://rephase.org/
https://winscp.net/eng/download.php
The aim of this post is to show the process I followed to build a config file for CamillaDSP to tri-amp a pair of modified Klipschorns. A secondary aim is to provide enough information for someone to follow the procedure to build a CamillaDSP config for their own speakers.
CamillaDSP is running on a RPi4 and using a Motu Ultralight Mk5 audio interface.
This is not the only way to build a config, the methods and options I have chosen work for me.
This is not going to be another tutorial on using REW and rePhase, but there will be a lot of REW measurements shown as screengrabs. REW has excellent help and there are good tutorials on the web. For rePhase I have lots of screengrabs. The screengrabs for REW and rePhase should provide enough information to show the process being performed.
The K-Horn mods are a new top hat using B&C DCX464 coax drivers mounted on an Eliptrac horn for mid and hi. The B&C DCX464 is a 111db/W 1.4" compression horn with a 290-20,000Hz response. The K-Horn bass is about 105db/W. The only ramification of using a coax from a seperate tweeter is that the mid and hi use the same delay for time alignment. Due to horn length the bass is delayed by 5msec (far more than a standard 3 driver box) and I show how to determine this and the DSP filters required for time alignment.
Currently I am using an Allo Boss2 streamer feeding analog into a NAD receiver acting as a pre-amp (volume control & source selection) , then analog into a Motu UL5/RPi .
The outputs from the Motu UL5/RPi are balanced analog and feed a single stereo N-Core amp for left and right K-Horn bass and and a pair of XLR balanced input SMSL SH9 THX Headphone amps for mid and hi. The nominally 16ohm (tests show 12ohm) B&C DCX are 111db/W and the SH9 will put out 6W into 16ohm and 9W into 8ohm. More than enough power for a domestic system remembering that there are no passive crossovers sucking power. Also, these amps and the Motu UL5 and Raspberry Pi cost about half what I spent a few years ago on a passive steep slope crossover.
I use a Behringer ECM8000 measurement condenser mic that connects with an XLR plug to a Motu M4 audio interface. I use loopback in the M4 to provide reference timing for REW. A miniDSP UMIC will work just as well with acoustic timing for reference, an advantage of the Behringer and Motu M4 is that I can also use Open Sound Meter, a disadvantage is that I must calibrate the sound level of the Behringer each measurement session.
Software used is REW and Rephase . I run all this on Win 11 on an Asus laptop and use WinSCP for file transfer from Laptop to CamillaDSP on the RPi. Both CamillaDSP and my laptop are on a LAN.
Measurements are taken with the tip of the microphone 1m from the centre of the Eliptrac horn which is 118cm off the floor. This microphone position is generally accepted in the Klipsch community for measuring K-Horns as it all but eliminates room reflections. The listening room is 6.5m wide by 10.8m long with 2.6m ceiling. The flooring is polished hardwood with extensive rug covering, couches and furnishings. Walls are sheetrock drywall with curtained windows. Klipschorns are corner horns so the corner sheetrock is re-enforced to reduce flex as the corner wall is part of the bass horn. The floor immediately in front of the K-Horns are covered with large woolly dog beds to reduce reflection.
The basic procedure I followed is -
1. Measure drivers using REW and use REW EQ to calculate EQ settings for a flat frequency response using 1/6 smoothing. Add the EQs to the Pipeline in CamillaDSP (REW has just added the function to save EQ filters in CamillaDSP format).
2. Add Linear Phase XO in Rephase to the Pipeline in CamillaDSP
3. Measure response, set gains for each driver, determine delays for each driver go back and adjust XO frequencies to give smoothest result while taking advantage of "acoustic crossover" of the drivers.
4. After getting the delays between drivers correct, manipulate the phase in Rephase for each driver to get the Excess Phase close to zero.
5. Guild the lily by doing another EQ of the full system (80-10,000Hz) to flatten SPL peaks and troughs across the cross over regions.
Rather than fill the thread with graphs, the steps are in .pdf format as attachments, this also has the advantage of being able to zoom in on the screen dumps.
Thank you Henryk for CamillaDSP and Michael for his tutorial on setting up Camilla on a Raspberry Pi and a Motu Ultralight Mk 5. Thanks also to Cask05 for help with REW in my early days of coming to grips with DSP.
Links :
https://www.audiosciencereview.com/forum/index.php?threads/rpi4-camilladsp-tutorial.29656/
https://www.avnirvana.com/forums/official-rew-room-eq-wizard-support-forum.10/
https://rephase.org/
https://winscp.net/eng/download.php
@HenrikEnquist I am looking for easy step by step Camilladsp configuration tutorial on Windows 10. Could you please assist me here? Raspberry and Linux based are very well documented. However nothing I can find for Windows. Help would be highly appreciated!🙂
I hardly follow the debate here: https://www.diyaudio.com/community/...nearization-by-fir.393435/page-6#post-7213543
Could these filters be implemented in CDSP?
Could these filters be implemented in CDSP?
Hi @Dave Bullet , I was just about to post a question myself about something very similar. I've been using websocket to swap config files for some time without any issue at all. Recently I set up a new config file for a different source (on a different alsaloop device) and get a pop switching to this new config, but confusingly only some of the time, and never swapping away from this source/config to another source/config. Let me know if there's anything useful I can send you, and please let me know what you discover. Thanks
I asked if it could be done by IIR. Answer was no. So you have to design them as FIR somehow use that in CDSP.
//
Hi @johnanon.
One thing I think helps (I need to do more testing) is ensuring when you swap configs, you keep the devices and mixer pretty much the same. For example - don't switch sample rates, chunk sizes nor channels etc...
the popping isn't consistent and must be load related as I'm sure its an alsaloop underrun condition.
Without alsaloop it's much better. I run a chunksize of 2,048 on a pi3.
Hi @Dave Bullet
Thanks for the info. If this is an alsaloop issue, then perhaps we should try to work around it - maybe with CamillaDSP's mute? I know that with the latest version 1.0.3 the mute status is preserved when changing configuration. However, rather than muting before changing configuration, it would be one step shorter to simply define all configurations with mute status as true, and then unmute when the configuration reload is acknowledged. When I get a moment I'll try that and report back