Go Back   Home > Forums > >

PC Based Computer music servers, crossovers, and equalization

CamillaDSP - Cross-platform IIR and FIR engine for crossovers, room correction etc.
CamillaDSP - Cross-platform IIR and FIR engine for crossovers, room correction etc.
Please consider donating to help us continue to serve you.

Ads on/off / Custom Title / More PMs / More album space / Advanced printing & mass image saving
Reply
 
Thread Tools
Old 29th January 2021, 04:26 PM   #1571
TNT is offline TNT  Sweden
diyAudio Member
 
Join Date: Apr 2003
Location: Sweden
CamillaDSP - Cross-platform IIR and FIR engine for crossovers, room correction etc.
Taps are ... taps in rePhase. FFT length in rePhase seem hard to understand but has no consequences outside rePhase.

//
__________________
More distortion to the people! Timing . . . . is paramount.
  Reply With Quote
Old 29th January 2021, 07:41 PM   #1572
darkless is offline darkless  Denmark
diyAudio Member
 
Join Date: Jan 2011
Location: Denmark
Quote:
Originally Posted by HenrikEnquist View Post
What happens now when the rate changes? Is data being fed to CamillaDSP at the new rate?
Yes it is.


Quote:
Originally Posted by HenrikEnquist View Post
CamillaDSP measures the incoming sample rate, and you can read the value on the websocket. Is that changing?
Yes, the "Fireface USB Settings" panel shows that the soundcard locks onto the new incoming sample rate regardless of whether CamillaDSP is running or not. CamillaDSP is able to measure the new sample rate if it's running while the audio stream changes sample rate, i.e. when skipping to a new 176.4 KHz track while the samplerate=44100 and capture_samplerate=96000 (see quote below). However, CamillaDSP is not changing its input and output audio unit sample rates to match the actual sample rate on the soundcard device itself, so you end up with distorted playback. The stackoverflow post linked in my previous reply appears to list the steps needed to handle the transition.

Code:
sundebo@m1 ~ % camilladsp -p 1234 config.yml -vv
Jan 29 21:39:32.857 DEBG Read config file Some("config.yml"), module: camilladsp
Jan 29 21:39:32.857 DEBG Config is valid, module: camilladsp
Jan 29 21:39:32.858 DEBG Start websocket server on 127.0.0.1:1234, module: camillalib::socketserver
Jan 29 21:39:32.858 DEBG Wait for config, module: camilladsp
Jan 29 21:39:32.858 DEBG Config ready, module: camilladsp
Jan 29 21:39:32.858 DEBG Using channels [true, true], module: camilladsp
Jan 29 21:39:32.858 DEBG Build new pipeline, module: camillalib::filters
Jan 29 21:39:32.858 DEBG build filters, waiting to start processing loop, module: camillalib::processing
Jan 29 21:39:32.882 DEBG Opened CPAL playback device Digiface USB (24011413), module: camillalib::cpaldevice
Jan 29 21:39:32.882 DEBG Opened CPAL capture device Digiface USB (24011413), module: camillalib::cpaldevice
Jan 29 21:39:32.882 DEBG Playback thread ready to start, module: camilladsp
Jan 29 21:39:32.882 TRCE Build f32 output stream, module: camillalib::cpaldevice
Jan 29 21:39:32.882 DEBG Capture thread ready to start, module: camilladsp
Jan 29 21:39:32.882 DEBG Both capture and playback ready, release barrier, module: camilladsp
Jan 29 21:39:32.882 TRCE Build f32 input stream, module: camillalib::cpaldevice
Jan 29 21:39:33.535 TRCE f32 output stream ready, module: camillalib::cpaldevice
Jan 29 21:39:33.540 TRCE f32 input stream ready, module: camillalib::cpaldevice
Jan 29 21:39:33.540 DEBG Starting capture loop, module: camillalib::cpaldevice
Jan 29 21:39:33.540 DEBG Starting playback loop, module: camillalib::cpaldevice
Jan 29 21:39:33.559 WARN No data to play, dropping a callback, module: camillalib::cpaldevice
Jan 29 21:39:33.583 WARN No data to play, dropping a callback, module: camillalib::cpaldevice
Jan 29 21:39:34.546 TRCE Measured sample rate is 30550.89572073703 Hz, module: camillalib::cpaldevice
Jan 29 21:39:35.550 TRCE Measured sample rate is 176392.5199562633 Hz, module: camillalib::cpaldevice

Another scenario is the quote below showing the output after starting CamillaDSP with enable_resampling=true and capture_samplerate=176400 while playing audio @ 192 KHz. CamillaDSP plays distorted sound while still correctly measuring the right input sample rate.

Code:
sundebo@m1 ~ % camilladsp -p 1234 config.yml -vv
Jan 29 21:18:30.758 DEBG Read config file Some("config.yml"), module: camilladsp
Jan 29 21:18:30.758 DEBG Config is valid, module: camilladsp
Jan 29 21:18:30.758 DEBG Start websocket server on 127.0.0.1:1234, module: camillalib::socketserver
Jan 29 21:18:30.758 DEBG Wait for config, module: camilladsp
Jan 29 21:18:30.758 DEBG Config ready, module: camilladsp
Jan 29 21:18:30.758 DEBG Using channels [true, true], module: camilladsp
Jan 29 21:18:30.758 DEBG Build new pipeline, module: camillalib::filters
Jan 29 21:18:30.758 DEBG build filters, waiting to start processing loop, module: camillalib::processing
Jan 29 21:18:30.758 DEBG Creating resampler, module: camillalib::cpaldevice
Jan 29 21:18:30.759 DEBG Creating asynchronous resampler with parameters: InterpolationParameters { sinc_len: 128, f_cutoff: 0.92591465, oversampling_factor: 1024, interpolation: Linear, window: Blackman2 }, module: camillalib::audiodevice
Jan 29 21:18:30.780 DEBG Opened CPAL playback device Digiface USB (24011413), module: camillalib::cpaldevice
Jan 29 21:18:30.780 DEBG Opened CPAL capture device Digiface USB (24011413), module: camillalib::cpaldevice
Jan 29 21:18:30.780 DEBG Playback thread ready to start, module: camilladsp
Jan 29 21:18:30.780 DEBG Capture thread ready to start, module: camilladsp
Jan 29 21:18:30.780 DEBG Both capture and playback ready, release barrier, module: camilladsp
Jan 29 21:18:30.780 TRCE Build f32 output stream, module: camillalib::cpaldevice
Jan 29 21:18:30.780 TRCE Build f32 input stream, module: camillalib::cpaldevice
Jan 29 21:18:31.415 TRCE f32 output stream ready, module: camillalib::cpaldevice
Jan 29 21:18:31.426 WARN No data to play, dropping a callback, module: camillalib::cpaldevice
Jan 29 21:18:31.428 TRCE f32 input stream ready, module: camillalib::cpaldevice
Jan 29 21:18:31.428 DEBG Starting capture loop, module: camillalib::cpaldevice
Jan 29 21:18:31.428 DEBG Starting playback loop, module: camillalib::cpaldevice
Jan 29 21:18:31.438 WARN No data to play, dropping a callback, module: camillalib::cpaldevice
Jan 29 21:18:31.449 WARN No data to play, dropping a callback, module: camillalib::cpaldevice
Jan 29 21:18:31.460 WARN No data to play, dropping a callback, module: camillalib::cpaldevice
Jan 29 21:18:31.471 WARN No data to play, dropping a callback, module: camillalib::cpaldevice
Jan 29 21:18:31.476 WARN No data to play, dropping a callback, module: camillalib::cpaldevice
Jan 29 21:18:31.530 WARN No data to play, dropping a callback, module: camillalib::cpaldevice
Jan 29 21:18:32.468 TRCE Measured sample rate is 27910.049476527634 Hz, module: camillalib::cpaldevice
Jan 29 21:18:33.471 TRCE Measured sample rate is 188951.4862883025 Hz, module: camillalib::cpaldevice
Jan 29 21:18:34.471 TRCE Measured sample rate is 191703.32903834837 Hz, module: camillalib::cpaldevice
Jan 29 21:18:35.479 TRCE Measured sample rate is 192382.891015803 Hz, module: camillalib::cpaldevice
Jan 29 21:18:36.479 TRCE Measured sample rate is 191694.60696425877 Hz, module: camillalib::cpaldevice

Last edited by darkless; 29th January 2021 at 07:48 PM.
  Reply With Quote
Old 29th January 2021, 08:19 PM   #1573
TNT is offline TNT  Sweden
diyAudio Member
 
Join Date: Apr 2003
Location: Sweden
CamillaDSP - Cross-platform IIR and FIR engine for crossovers, room correction etc.
Little problem to remember Load / Upload... what do they do now again...? It would be good if the button that says "Apply" used the same lingo as Load / Upload.

Load = Apply? An Upload will just show the config but not activiate it until "Apply"...

If so, Rename Apply -> Load.

Or Load and Load/Apply...

//
__________________
More distortion to the people! Timing . . . . is paramount.
  Reply With Quote
Old 29th January 2021, 08:38 PM   #1574
HenrikEnquist is offline HenrikEnquist  Sweden
diyAudio Member
 
Join Date: Apr 2016
Location: Lund
@Darkless:
This is very good, because it means you can easily solve the rate switching with a python script that monitors the measured capture sample rate. Whenever it changes, it can then let CamillaDSP load a suitable config for the new rate.
Catching the rate changes through CoreAudio would be quicker at detecting them, but it only solves part of the problem. You still have to decide what to do at the new rate. Just switching the sample rate of the pipeline often isn't enough. If you have FIR filters you will want to switch to new filter coeffs for example.



Since I use a library (CPAL) that completely hides the CoreAudio API I can't implement the stuff from the stackoverflow post in CamillaDSP. Instead it would have to go in CPAL, which at the moment doesn't even have any way of forwarding the info. I'm considering to skip that library and use CoreAudio and Wasapi directly. I haven't decided on that yet and it's quite a large amount of work.
__________________
CamillaDSP - cross platform dsp engine
Reporting an issue with CamillaDSP? Please attach the config file and the log from a run with "debug" log level.
  Reply With Quote
Old 29th January 2021, 08:50 PM   #1575
HenrikEnquist is offline HenrikEnquist  Sweden
diyAudio Member
 
Join Date: Apr 2016
Location: Lund
Quote:
Originally Posted by TNT View Post
Little problem to remember Load / Upload... what do they do now again...? It would be good if the button that says "Apply" used the same lingo as Load / Upload.
Load - load a config file into the GUI
Upload - pick a local config file to store in the config folder on the server (meant for when camilladsp runs on some other machine than the one you use to access the gui). This is not very useful yet.

Apply - send the config from the gui to camilladsp.


I'm getting help to make some quite significant improvements to the gui, expect the next version to be a nice big improvement
__________________
CamillaDSP - cross platform dsp engine
Reporting an issue with CamillaDSP? Please attach the config file and the log from a run with "debug" log level.
  Reply With Quote
Old 29th January 2021, 08:54 PM   #1576
TNT is offline TNT  Sweden
diyAudio Member
 
Join Date: Apr 2003
Location: Sweden
CamillaDSP - Cross-platform IIR and FIR engine for crossovers, room correction etc.
Aha .-)

Yepp that would be good. Using Load for both these cases threw me off...

Looking fwd!!

//
__________________
More distortion to the people! Timing . . . . is paramount.
  Reply With Quote
Old 29th January 2021, 10:07 PM   #1577
darkless is offline darkless  Denmark
diyAudio Member
 
Join Date: Jan 2011
Location: Denmark
Quote:
Originally Posted by HenrikEnquist View Post
@Darkless:
This is very good, because it means you can easily solve the rate switching with a python script that monitors the measured capture sample rate. Whenever it changes, it can then let CamillaDSP load a suitable config for the new rate.
I'm not convinced that monitoring through Python always works, because CamillaDSP doesn't always seem to register the change. To make matters worse, the RME Digiface USB often sends out some nasty noise spikes when the incoming sample rate changes. I really don't want to subject my sensitive (and expensive) treble drivers to potentially damaging noise spikes. As such I believe a proper callback in CoreAudio is needed that can be triggered as soon as the physical device changes its rate. I imagine that muting and stopping the playback until the sample rate has been properly synced would be ideal, but I haven't looked at the code. Once it has been implemented the Python script for monitoring the capture sample rate and loading a suitable config should work just fine.

Quote:
Originally Posted by HenrikEnquist View Post
Catching the rate changes through CoreAudio would be quicker at detecting them, but it only solves part of the problem. You still have to decide what to do at the new rate. Just switching the sample rate of the pipeline often isn't enough. If you have FIR filters you will want to switch to new filter coeffs for example.
I completely agree. In the case of the RME Digiface USB it's even more needed, as the number of device channels depend on the sample rate, i.e. 44.1 and 48 KHz gives you 32 ADAT channels (ignoring the two phono channels), whereas 88.2 and 96 KHz gives you 16 channels and finally 176.4 and 192 KHz gives you 8 channels.
In the first case I need the mixer to send output to ADAT channels 1/2, 9/10, 17/18 and 25/26 for a 4-way setup. If the sample rate changes to e.g. 96 KHz I suddenly need to change my mixer mappings to 1/2, 5/6, 9/10 and 13/14 plus all the associated filters in the pipeline. It's a royal pain having to maintain three configs, but that's how it is.

Quote:
Originally Posted by HenrikEnquist View Post
Since I use a library (CPAL) that completely hides the CoreAudio API I can't implement the stuff from the stackoverflow post in CamillaDSP. Instead it would have to go in CPAL, which at the moment doesn't even have any way of forwarding the info. I'm considering to skip that library and use CoreAudio and Wasapi directly. I haven't decided on that yet and it's quite a large amount of work.
I didn't realise that CPAL is not able to provide meaningful feedback to the caller. If it requires custom patches for CPAL, then that's what must be done. Pity that I don't know my way around Rust. As much as I'd love to add another language to my resume, my IRL situation precludes me from doing that for the time being. I love the pace and direction you're taking CamillaDSP, no easy feat!

Last edited by darkless; 29th January 2021 at 10:20 PM.
  Reply With Quote
Old 30th January 2021, 06:46 AM   #1578
Traktorist3d is offline Traktorist3d  Russian Federation
diyAudio Member
 
Join Date: Jun 2015
Hello! I know very little about the intricacies of Linux, I can only generate "brilliant" ideas, I will ask questions, sorry if they are stupid.
1. When will it be possible to use Camillia as an already debugged application with a working graphical interface on an ARM device? Will the opportunity be realized, download an image that can be loaded onto MicroDS in Pi or BBB and enjoy life.
2. How well is Camillia's signal processing? It's no worse than DSP in ROON, HQP, JRIVER and other P (I'm talking about the version for ARM)
3. (Very important IMHO) Is it possible to implement Camilia so that on the ARM device on which it is installed, you can send a stream from any UPnP player, the same BubbleUPnP, and from Camillia, in turn, an already processed signal to another network endpoint capable of output 2-8 channels. For example BBB (BeagleBone Black) with PURE firmware from Pavel Pogodin, which can output a signal via UPnP (MDP), squeezelite and others. Sobsvenno IMHO a bunch when each device does its own thing. Camillia is running on Pi 3 \ 4, she sends already processed DSP channels to the BBB endpoint.
4. Is Camillia's version possible for the BBB?
5. Will the filter pulses generated in Rephase work in Camilli?
6. Is there a time delay setting?

Henrik Thank you for what you are doing. I am especially pleased that you are making a version of Camillia for single-board devices, since there are a lot of programs on x86, and for ARM there is no such software at all, as far as I know.
  Reply With Quote
Old 30th January 2021, 01:10 PM   #1579
darkless is offline darkless  Denmark
diyAudio Member
 
Join Date: Jan 2011
Location: Denmark
@HenrikEnquist:

It would be nice to either rate limit the "No data to play, dropping a callback" message to once per second or have a way to turn it off completely. I want to be able to see the other debug and trace messages, but this one quickly clutters the screen and/or log files if you pause the playback or hit a track with a different sample rate.
  Reply With Quote
Old 30th January 2021, 04:11 PM   #1580
xorcz is offline xorcz  Czech Republic
diyAudio Member
 
Join Date: Feb 2020
Quote:
Originally Posted by Traktorist3d View Post
5. Will the filter pulses generated in Rephase work in Camilli?
Yes, it is working fine.

Quote:
Originally Posted by Traktorist3d View Post
6. Is there a time delay setting?
Delay, see in the documentation GitHub - HEnquist/camilladsp: A flexible linux IIR and FIR engine for crossovers, room correction etc.
  Reply With Quote

Reply


CamillaDSP - Cross-platform IIR and FIR engine for crossovers, room correction etc.Hide this!Advertise here!
Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
The room correction or speaker correction? What can we do with dsp power now availabl Raimonds Full Range 233 28th January 2017 07:51 AM
Introducing OpenDRC, Open Digital Room Correction engine minidsp miniDSP 20 20th January 2016 05:37 PM
What the difference between dsp room correction eq and software correction erez1012 PC Based 0 10th March 2014 07:07 PM
Writing a Cross-Platform, Free Software Modeling Tool and TS-Parameter DB justinzane Software Tools 6 31st December 2013 06:55 AM
FS: DAC, room-correction, active crossovers, amp, speakers! taloyd Swap Meet 4 14th April 2009 03:16 PM


New To Site? Need Help?

All times are GMT. The time now is 03:21 AM.


Search Engine Optimisation provided by DragonByte SEO (Pro) - vBulletin Mods & Addons Copyright © 2021 DragonByte Technologies Ltd.
Resources saved on this page: MySQL 14.29%
vBulletin Optimisation provided by vB Optimise (Pro) - vBulletin Mods & Addons Copyright © 2021 DragonByte Technologies Ltd.
Copyright ©1999-2021 diyAudio
Wiki