The timeout is rounded to a number of full chunks. Are you using 0.5.0-beta4, or a newer build from develop? There is a bug in beta4 (and earlier) that makes it calculate too short times under some circumstances.
This error comes from the Alsa library, saying that it failed to write data to the card. That should have nothing to do with Audacious, and it's not likely caused by camilladsp either. What dac or soundcard is this?
Thanks for the info.
Would it be significantly faster to use the web interface to switch between filenames ?
If so, I need to figure out how to add synchronized hooks into my player. The command line tool would still be convenient to create all of the variants from a single template.
Code:
https://github.com/HEnquist/camilladsp/blob/master/websocket.md
Switch to a different config file.
The new config is applied when the "reload" command is sent.
In [6]: ws.send(json.dumps({"SetConfigName": "/path/to/96000config.yml"}))
Out[6]: 52
In [7]: print(ws.recv())
{"GetConfigName":{"result":"Ok","value":"/path/to/96000config.yml"}}
In [8]: ws.send(json.dumps("Reload"))
Out[8]: 12
In [9]: print(ws.recv())
{"Reload":{"result":"Ok"}}FWIW, I am using the latest beta compiled on an i7 with hw AVX acceleration on a 5.10 PREEMPT_RT kernel.
I am not certain if this is an accurate assessment, but the REW IR plots show a 3 microsecond latency delta between measuring straight to the HW versus measuring through the 64K tap CamillaDSP FIR filter (no rate switcher in circuit).
Using cyclictest, maximum system playback latencies are 22 microseconds with the PREEMPT_RT kernel and over 500 micoseconds with the vanilla kernel.
I haven't compared, but I don't think so. A full reload, like when switching sample rate still means tearing down the whole processing pipeline, and closing the devices before starting everything up again.
Were both measurements done through camilladsp, one with and one without a fir filter? 3us is a very short delay (it's less than one sample) , 3ms would be more reasonable.
Yes a RT kernel will respond quicker, but in most cases there is no benefit in practice. What are you actually trying to accomplish?
Sorry, you're living in 2008. Everything is built for 64-bit OS nowadays, and you can pick up a modern system that handles x86-64 or aarch64 for <$50, Thinkpads included. If you're talking specifically about raspi, Ubuntu aarch64 runs wonderfully, skip Raspbian (Raspberry Pi OS) because they don't want to migrate for some odd reason.
ExpressCard and Thunderbolt are also a thing. USB3 supports data rates greatly exceeding that necessary for audio.... PCI busses and, by extension, PCMCIA was tossed because it's slow as s**t. PCI-Express, and by extension, ExpressCard, supplanted it and nowadays USB is more than adequate with USB3.2/4 2x2 doing 20Gbps.
Last edited:
Thanks, so it appears it saves killing and starting 1 process and possibly a tread or so. I was considering a possible VST3 plugin to send the sample rate change JSON messages from the player.
One set was using "default" picking up the camilladsp and the other set was using "hw:N,0". The first set's plots verified frequency corrections while the 2nd set did not have the frequency corrections. I was starting/stopping camilladsp by hand in another window.
I also noticed that there is a bigger latency delta using a UMIK-1 versus a Focusrite 8i6/ECM8000 for the IR and Steps with the Focusrite/ECM8000 having the lower latency by almost 30 microseconds.
The FR/ECM measurements all stacked on the green plot.
The UMIK-1-No FIR all stacked on the blue plot.
The UMIK-1-FIR plots all stacked on the green plot.
Haven't tried the FIR with the FR/ECM yet.
Steady state predictability, consistent repeatable measurements and playback while avoiding Win10 issues/releases/telemetry.
yes, 0.5.0-beta4
I hoped it is a SW issue. I use AMD RX580 connected to a AV receiver via HDMI. It seems it is related to the graphic card, I had launched graphic benchmark and popping appeared very often. There are complains of people using AMD graphics on Windows, so it is probably valid also for Linux
Yes, that would be the difference. Why do you need very fast rate switches? It normally only takes a fraction of a second.
The scale here is a bit odd. REW always shows smooth lines, which can be a little misleading. At 48 kHz (the max for the UMIK if I'm not mistaken) a single sample coresponds to 21 us. If this was done at 48 kHz, the delay was just 1.5 sample. I would argue that this is insignificant.
Ok, then the silence timeout thing should get fixed once the final 0.5.0 is out (very soon now).
It is more of a workflow optimization for measuring. My current workflow is:
Measure: Run camilladsp by hand with mic specific frequency config.yml. Write to "hw:Loopback,0" (REW doesn't offer the "camilladsp" option).
Playback: Write to "camilladsp" with automatic "alsa_cdsp" rate switcher.
I wasn't sure what was causing the 3 us, but agree, it is a very small latency whatever is causing it.
UMIK-1 is limited to 48kHz and the measurements were done in 48kHz. The Focusrite supports up to 192kHz and will hopefully replace the UMIK-1 once everything is configured in Linux.
I just tried multi-pass convolution and it works. Very, very cool. I always wanted my XO's to be in one pass and my "DRC/house curves" to be in another. Not all player convolution engines allow multi-pass convolution.
Last edited:
Minor asla_cdsp native rate switcher optimization
Please delete this post if this contribution is not appropriate.
FWIW, here is a minor optimization for the alsa_cdsp rate switcher code.
Instead of rewriting the same config_out.yml file every time, it checks to see if a rate specific file already exists. If it does exist, it uses the preexisting file. It does not reread the config_in.yml template file, parse, substitute and rewrite a new config_out.yml unless absolutely necessary.
It creates rate specific config_out.yml files by appending "_SampleRate" to the specified output filename. It will create as many different sample rate output files as played and reuse them. Note, the specified config_out.yml will just be used as a prefix for the actual files being created.
Example: Output files are created in order of sample rates played.
To force it to reprocess a modified config_in.yml template file, just delete the generated output files and they will regenerate as the sample rates are replayed.
Alternatively, the "if (access(pcm->cargs[1], F_OK))" could be modified to include comparisons of the input/output file modification dates to update them automatically.
Here is the patch code. Place the "non-blank" lines (exclude any trailing blank lines) into a file (e.g. "patchfilename") exactly as it is.
Run the following patch command in the local source code directory. Then build and install as normal.
patch libasound_module_pcm_cdsp.c patchfilename
As a final optimization, I created a tmpfs ramdisk like others have previously done here. Thanks for the ideas. The ramdisk has increased the file read speeds by a factor 10X. The PC is basically getting PCIe3 NVMe read speeds out of a PCIe2/SATA2/DDR3 system.
I placed the FIR filters, config_in.yml, config_out.yml_SampleRate and camilladsp executable in the ramdisk which should further help speed up the rate switch reconstructions.
HTH
Please delete this post if this contribution is not appropriate.
FWIW, here is a minor optimization for the alsa_cdsp rate switcher code.
Instead of rewriting the same config_out.yml file every time, it checks to see if a rate specific file already exists. If it does exist, it uses the preexisting file. It does not reread the config_in.yml template file, parse, substitute and rewrite a new config_out.yml unless absolutely necessary.
It creates rate specific config_out.yml files by appending "_SampleRate" to the specified output filename. It will create as many different sample rate output files as played and reuse them. Note, the specified config_out.yml will just be used as a prefix for the actual files being created.
Example: Output files are created in order of sample rates played.
Code:
/pathto/config_out.yml_44100
/pathto/config_out.yml_48000
...
...
/pathto/config_out.yml_384000To force it to reprocess a modified config_in.yml template file, just delete the generated output files and they will regenerate as the sample rates are replayed.
Alternatively, the "if (access(pcm->cargs[1], F_OK))" could be modified to include comparisons of the input/output file modification dates to update them automatically.
Here is the patch code. Place the "non-blank" lines (exclude any trailing blank lines) into a file (e.g. "patchfilename") exactly as it is.
Run the following patch command in the local source code directory. Then build and install as normal.
patch libasound_module_pcm_cdsp.c patchfilename
Code:
493a494,506
> // OPTIMIZATION: CHANGE single use config_out.yml to reuseable config_out.yml_SRATE
> if (pcm->cargs[1]) {
> int len;
> char *ptr = malloc( (len = (strlen(pcm->cargs[1]) + sizeof(srate) + 2)) );
> if(!(ptr)) {
> SNDERR("Out of memory");
> return -ENOMEM;
> }
> snprintf(ptr, len, "%s_%u", pcm->cargs[1], pcm->io.rate);
> free(pcm->cargs[1]);
> pcm->cargs[1] = ptr;
> }
>
545a559,562
>
>
> // OPTIMIZATION: Only create rate specific config_out.yml_SRATE file if it doesn't already exist
> if (access(pcm->cargs[1], F_OK)) {
565c582,583
< fprintf(cfgout,"%s",obuf);
---
> //fprintf(cfgout,"%s",obuf);
> fputs(obuf,cfgout); // OPTIMIZATION - parsing format string not needed
568a587,589
> }
>
>As a final optimization, I created a tmpfs ramdisk like others have previously done here. Thanks for the ideas. The ramdisk has increased the file read speeds by a factor 10X. The PC is basically getting PCIe3 NVMe read speeds out of a PCIe2/SATA2/DDR3 system.
I placed the FIR filters, config_in.yml, config_out.yml_SampleRate and camilladsp executable in the ramdisk which should further help speed up the rate switch reconstructions.
HTH
Thank you for this contribution!
I'm thinging about how to keep this available. In a week this post will be several pages back in the thread and few will see it. Would you consider opening a PR to GitHub - scripple/alsa_cdsp: ALSA plugin for Camilla DSP?
For that this optimization should probably be enabled by a setting in the plugin config.
I am not familiar with the Github patch submission request procedure, but will see if I can figure it out. It appears you create an account, need appropriate access privileges to the Github branch, create a sub branch, apply your patches to the sub branch and then submit a "PullRequest" (strange name for a merge request).
I tried pm'ing SeaShell before posting, but he hasn't been around since Nov and doesn't accept pm's. Don't know if he (or anyone) is still actively managing the Github branch.
I assume you mean by expanding the "type cdsp" parameter set in asound.conf. Making it a configurable start-time option is a great idea. Can then provide all 3 forms (e.g. "off" [default], "auto" [compare last modified dates], "manual" [manual deletions, least disk access]).
Last edited:
Almost, but you don't need any special privileges. You just fork the project to your own account, and then make the pull request from there.
I think he is still maintaining it, the last commit is from february.
Yes that's exactly what I meant.
Hi HenrikEnquist,
I am new to your amazing software.
Got it up and running on MacOS Big Sur 11.2.2 in a matter of hours with 3 way filter - fanatic.
One challenge - on the Mac - when camillaDSP is running and I am NOT playing music then coreaudiod (mac core audio deamon) consumes 50% CPU
When I do play music then coreaudiod consumes 20%
I am using Soundflower 2.0b2
Any hints on why this is happening ?
I am new to your amazing software.
Got it up and running on MacOS Big Sur 11.2.2 in a matter of hours with 3 way filter - fanatic.
One challenge - on the Mac - when camillaDSP is running and I am NOT playing music then coreaudiod (mac core audio deamon) consumes 50% CPU
When I do play music then coreaudiod consumes 20%
I am using Soundflower 2.0b2
Any hints on why this is happening ?
CamillaDSP - Sample FIR coeeficients and configs
For those interested I have posted some sample FIR coefficient files and CamillaDSP configurations available here if you want to try: GitHub - ynot123/CamillaDSP-Cfgs-FIR-Examples: Example setups for CamillaDSP filter configurations and sample convolver coefficients files.
Setup PI3 with Debian Lite, Squeezelite and CamillaDSP with IQAudio tophat. Sound is now wonderful. Many thanks Henrik.
Always looking for some great FIR files, if you want to add yours to the repository, let me know. Ynot.
For those interested I have posted some sample FIR coefficient files and CamillaDSP configurations available here if you want to try: GitHub - ynot123/CamillaDSP-Cfgs-FIR-Examples: Example setups for CamillaDSP filter configurations and sample convolver coefficients files.
Setup PI3 with Debian Lite, Squeezelite and CamillaDSP with IQAudio tophat. Sound is now wonderful. Many thanks Henrik.
Always looking for some great FIR files, if you want to add yours to the repository, let me know. Ynot.
I haven't seen this, but I also don't have anything that can run big sur.
Soundflower hasn't been updated in ages. It could be worth trying BlackHole instead:GitHub - ExistentialAudio/BlackHole: BlackHole is a modern macOS virtual audio driver that allows applications to pass audio to other applications with zero additional latency.
Use the 16-channel version since the 2-channel version has a bug that sometimes gives choppy sound.
CamillaDSP As An AddOn For Kodi (LibreElec / CoreElec)
Hi HenrikEnquist,
first thanks for such a great job with CamillaDSP
I'd really like to run this in Kodi via LibreElec/CoreElec ie. on a cheap SOC
To that end it would need to be "packaged" as an add-on
I have added a request for help building such a Kodi AddOn here Create AddOn For CamillaDSP - Help Needed
Has anyone begun packaging for use in Kodi ?
Please advise if you're ok with "me" packaging CamillaDSP for Kodi users. (My limited Kodi / python skills means it will take a while)
There's a long way to go before its a package, and even further before before it works for multiple platforms.
Worth noting that Kodi users are often non-technical and also likely to want to use DSP effects for Home Theatre ie. >2 speakers and that will likely lead to some confusion ... and potentially support requests (noise) - which will primarily be handled by the AddOn maintainer
What do you think ?
Rob
Hi HenrikEnquist,
first thanks for such a great job with CamillaDSP
I'd really like to run this in Kodi via LibreElec/CoreElec ie. on a cheap SOC
To that end it would need to be "packaged" as an add-on
I have added a request for help building such a Kodi AddOn here Create AddOn For CamillaDSP - Help Needed
Has anyone begun packaging for use in Kodi ?
Please advise if you're ok with "me" packaging CamillaDSP for Kodi users. (My limited Kodi / python skills means it will take a while)
There's a long way to go before its a package, and even further before before it works for multiple platforms.
Worth noting that Kodi users are often non-technical and also likely to want to use DSP effects for Home Theatre ie. >2 speakers and that will likely lead to some confusion ... and potentially support requests (noise) - which will primarily be handled by the AddOn maintainer
What do you think ?
Rob
Hi!
I'm not away of any work on integrating with Kodi. If you want to try, just go ahead!
You should probably start with one of the complete distributions like LibreElec, and figure out how to configure it to set it up so the output from Kodi is processed by camilladsp. Then you would need an add-on for managing the configuration.
I'm not away of any work on integrating with Kodi. If you want to try, just go ahead!
You should probably start with one of the complete distributions like LibreElec, and figure out how to configure it to set it up so the output from Kodi is processed by camilladsp. Then you would need an add-on for managing the configuration.
Hi HenrikEnquist,
Once again thanks a lot for creating CamillaDSP !!
Have tried BlackHole - not much different CPU load than SoundFlower.
But I did get a bit of optimization by compiling CamillaDSP explicitly for my Mac
Now I have a 3 way system using 3 individual stereo DAC's - all synchronized through an "Aggregate Device" in the MacOS Audio MIDI Setup.
And I must report that it just works - as in it works like perfection.
Next step is to make CamillaDSP start as a daemon - which seems to be somewhat of a challenge.
Once again thanks a lot for creating CamillaDSP !!
Have tried BlackHole - not much different CPU load than SoundFlower.
But I did get a bit of optimization by compiling CamillaDSP explicitly for my Mac
Now I have a 3 way system using 3 individual stereo DAC's - all synchronized through an "Aggregate Device" in the MacOS Audio MIDI Setup.
And I must report that it just works - as in it works like perfection.
Next step is to make CamillaDSP start as a daemon - which seems to be somewhat of a challenge.
This is very interesting! I think more people could be interested in running like this. I have a bunch of questions then:
- Are the three dacs of the same model?
- What model(s) are they?
- Do you use one of them for both tweeters, one for midrange etc, or did you map the channels in some other way?
- Did you try to measure the delay between them, and how well they keep synchronized?
- Which one do you use as master?