Haha - yes I did. OK... sorry!
I thought dither didn't work like this - live and learn. I do understand that a "noise" is added but I thought it was just an equal raise for all frequencies. I also get that there are different shaped dither as I think about it but I must say I was surprised of the "high" levels...
//
I thought dither didn't work like this - live and learn. I do understand that a "noise" is added but I thought it was just an equal raise for all frequencies. I also get that there are different shaped dither as I think about it but I must say I was surprised of the "high" levels...
//
It's does work. I just tried it with a simpler stereo in / stereo out setup.
Code:
devices:
samplerate: 96000
buffersize: 8192
enable_rate_adjust: true
capture:
type: Alsa
channels: 4
device: "hw:CARD=M4,DEV=0"
format: S32LE
playback:
type: Alsa
channels: 4
device: "hw:CARD=M4,DEV=0"
format: S32LE
filters:
volume:
type: Volume
parameters:
ramp_time: 200
mixers:
line_in_to_stereo_out:
channels:
in: 4
out: 4
mapping:
- dest: 0
sources:
- channel: 2
gain: 0
inverted: false
- dest: 1
sources:
- channel: 3
gain: 0
inverted: false
pipeline:
- type: Filter
channel: 2
names:
- volume
- type: Filter
channel: 3
names:
- volume
- type: Mixer
name: line_in_to_stereo_outHi - I am trying out CamillaDSP under macOS using WAV file impulse response filters exported from REW - this appears to work and give the desired impact on the sound output, but the CPU usage is quite high (also there is some glitchiness on start/stop of sound playback but maybe that's another issue).
I wouldn't be surprised if some of the filter coefficients from REW aren't really doing much of anything, but I wasn't sure if there is any straightforward way to simplify - for example is there some flag in CamillaDSP yaml which could ignore some of the very insignificant filters, or some kind of easy pre-processing step which can be performed (ideally under macOS)?
Thank you!
I wouldn't be surprised if some of the filter coefficients from REW aren't really doing much of anything, but I wasn't sure if there is any straightforward way to simplify - for example is there some flag in CamillaDSP yaml which could ignore some of the very insignificant filters, or some kind of easy pre-processing step which can be performed (ideally under macOS)?
Thank you!
How long are the impulse responses?
CamillaDSP will always use everything from the files you give it. If the impulse responses contain a lot of silence, this will significantly increase the cpu usage.
Can you trim them with for example Audacity?
There were often glitches on start when using some older version of Blackhole. What are you using?
CamillaDSP will always use everything from the files you give it. If the impulse responses contain a lot of silence, this will significantly increase the cpu usage.
Can you trim them with for example Audacity?
There were often glitches on start when using some older version of Blackhole. What are you using?
I tried trimming in Audacity and then re-importing into REW to see if the filter magnitude response has visibly changed or not. This took a little experimentation to see how much I could trim but it seems like I can often trim the initial ~2 s export down to e.g. 0.5 s - 1.0s. This helped a lot with the CPU load. Thanks!
I have tried Soundflower [2ch] and Blackhole [2ch], both recently downloaded - switching between the two didn't seem to change much. I am also running SoundSource, though I tried closing it which again didn't seem to matter (not sure if it is still running something in the background). I think the long FIR filter did make the glitch much more obvious, it produced a 1s or longer robotic/metallic pulsing sort of effect. I tried various turning on enable_rate_adjust or enable_resampling but that also didn't seem to help. Audio sources are primarily Ableton Live and Apple Music app.
The most obvious triggers seem to be either a lack of audio playing or perhaps a change in native samplerate in the Music app. In Ableton I found I needed to basically continue playing silence so it wouldn't get into some kind of rapidly playing start/stop cycle of the camilla audio engine.
With the shorter FIR filter it mostly works okay and any audible glitch is much more subtle. But, one lingering issue is: if the audio starts/stops, sometimes camillaDSP seems to develop additional latency which doesn't go away until restart. One way I am using it is for digital piano playback, so this time delay can be an issue. (I'm not sure if it is intended for this kind of "real time" use but it is so close to working!) Maybe there is some kind of buffer that is gradually accumulating samples at a slightly different rate and not getting "purged"?
I attached config file, some logs (incl SW version info), and the shorter WAV which more or less works (the "problem" one was too large to upload
). Just in case it is helpful... Thank you!
I'll have to experiment a bit to figure out what is going wrong.
Sample rate changes are problematic on Macos, since the library I'm using (CPAL) doesn't have any way of notifying when things like that happen. Could it be that the sample rate is changed when playback starts, and then somehow switches back automatically when it stops?
What happens if you configure everything for say 48kHz in camilladsp and Audio and MIDI setting, and only play 48kHz material? Still glitching on start and stop?
The proper solution to all this is to stop using the CPAL library and go directly to CoreAudio. I have started looking at that but unfortunately there are some issues. The only Rust binding for CoreAudio is the one used by CPAL, and it's not well maintained. It hasn't seen any meaningful updates in a long time and bugs that don't affect CPAL don't get fixed. I could use it as it is, or I could fork it and fix the issues. Or I could start over and make a new binding. I'll start looking into this properly after v0.6.0 is ready.
Sample rate changes are problematic on Macos, since the library I'm using (CPAL) doesn't have any way of notifying when things like that happen. Could it be that the sample rate is changed when playback starts, and then somehow switches back automatically when it stops?
What happens if you configure everything for say 48kHz in camilladsp and Audio and MIDI setting, and only play 48kHz material? Still glitching on start and stop?
The proper solution to all this is to stop using the CPAL library and go directly to CoreAudio. I have started looking at that but unfortunately there are some issues. The only Rust binding for CoreAudio is the one used by CPAL, and it's not well maintained. It hasn't seen any meaningful updates in a long time and bugs that don't affect CPAL don't get fixed. I could use it as it is, or I could fork it and fix the issues. Or I could start over and make a new binding. I'll start looking into this properly after v0.6.0 is ready.
Update on the previous one. I haven't managed to reproduce the problem where starting and stopping playback causes trouble.
If I set both the real soundcard and Blackhole to 48 kHz in "Audio MIDI Setup", and start camilladsp at 44.1 kHz, then both devices are switched to 44.1 kHz. Stopping CamillaDSP does not make them switch back.
While playing at 44.1 kHz, if I then switch samplerate of Blackhole, then CamillaDSP stops receiving sound. If I then switch Blackhole back to 44.1, then CamillaDSP starts receiving sound again and resumes processing.
Again while playing, if I switch samplerate of the real soundcard, then there is a short (fraction of a second) glitch. Then playback is resumed, but the buffer level of CamillaDSP has increased, likely by the same time as the glitch. If rate adjust and resampling are active, it will recover back to the target level but that will take some time. If these glitches come too often, there will be a quite large delay after a while.
I think the problems are caused by sample rate changes, but I don't know why it happens so much in your system. Maybe SoundSource does some weird stuff?
Can you keep Audio MIDI Setup open while playing around? It seems to always show the current rate of the devices.
If I set both the real soundcard and Blackhole to 48 kHz in "Audio MIDI Setup", and start camilladsp at 44.1 kHz, then both devices are switched to 44.1 kHz. Stopping CamillaDSP does not make them switch back.
While playing at 44.1 kHz, if I then switch samplerate of Blackhole, then CamillaDSP stops receiving sound. If I then switch Blackhole back to 44.1, then CamillaDSP starts receiving sound again and resumes processing.
Again while playing, if I switch samplerate of the real soundcard, then there is a short (fraction of a second) glitch. Then playback is resumed, but the buffer level of CamillaDSP has increased, likely by the same time as the glitch. If rate adjust and resampling are active, it will recover back to the target level but that will take some time. If these glitches come too often, there will be a quite large delay after a while.
I think the problems are caused by sample rate changes, but I don't know why it happens so much in your system. Maybe SoundSource does some weird stuff?
Can you keep Audio MIDI Setup open while playing around? It seems to always show the current rate of the devices.
Would it be possible to have a setting that more aggressively clears this buffer/delay for this type of semi-realtime use case?
I experimented a bit and did find that one VST, Garritan CFX Grand, when loaded in Ableton Live seems particularly good at producing weird sample rate blips (although I'm not sure I saw anything conspicuous in the Audio MIDI setup, maybe I was looking in the wrong spot. It's quite surprising to me because Ableton is nominally set to 48 kHz but somehow it seems to still briefly switch to 44.1 kHz (which if I recall is the native recording sample rate for that plugin). If you want some kind of log let me know, but it sounds like there may not be any easy near term fixes on that side.
Mostly I am not having any major issues with audio artifacts if I keep the convolution filters to <=1 s duration at 48 kHz, the latency is generally acceptable too but sometimes gets a bit long which requires manual restart.
I guess one related question is whether I should really just be converting the room EQ filters to a parametric EQ (IIR?) rather than using the full impulse response WAV but I'm not too clear on the pros/cons there, and I'm also not aware of an easy import path there aside from writing my own REW output -> camillaDSP filter syntax converter...
Also, just FYI I noticed sometimes CamillaDSP seems to use about 60% CPU when idle but <5% active which is a bit of a mystery.
The suggestion from TNT is good, try that! And I would suggest using much shorter impulse responses than a full second. Does your IRs actually have anything with significant amplitude after say the first 100 ms?
I have decided to fork the existing CoreAudio binding (coreaudio-rs), fix the issues and add the missing functionality, and then build a new camilladsp backend using that. This should work much better in the end, but will of course take some time to finish.
I have decided to fork the existing CoreAudio binding (coreaudio-rs), fix the issues and add the missing functionality, and then build a new camilladsp backend using that. This should work much better in the end, but will of course take some time to finish.
Error when trying to implement into linux
Hi,
I've previously had camillaDSP working in moode audio but I am now trying to implement it separately, I have followed the instructions GitHub - HEnquist/camilladsp-config: Help for setting up CamillaDSP, example config files etc but when starting the service I get the following error messages.
(code=exited, status=101) and
Failed to start camilladsp.service
/etc/systemd/system/camilladsp.service:1: Missing '='.
Any ideas on how I could fix this? The Alsa loopback is working properly, but I'm not sure what this error means and I can't find an answer on google. Hope you can help.
Many thanks,
Elliott Dyson
Hi,
I've previously had camillaDSP working in moode audio but I am now trying to implement it separately, I have followed the instructions GitHub - HEnquist/camilladsp-config: Help for setting up CamillaDSP, example config files etc but when starting the service I get the following error messages.
(code=exited, status=101) and
Failed to start camilladsp.service
/etc/systemd/system/camilladsp.service:1: Missing '='.
Any ideas on how I could fix this? The Alsa loopback is working properly, but I'm not sure what this error means and I can't find an answer on google. Hope you can help.
Many thanks,
Elliott Dyson
I mostly just copied the config from the GitHub but I'll post it when I get home. As for starting it normally, I've tried running it as ./camilladsp config.yml and three lines of code show up saying it's all working but then the terminal seems to freeze which seems a bit weird, not entirely sure what it means, maybe it's just taking a while to finish loading? The os does fully run in terminal so maybe it's trying to open a UI or something?
Are you using ALSA loopback or the cdsp ALSA plugin?
Please post your config yml, and the output when starting camilladsp manually, but add the -v flag to get debug output. It shouldn't take more than a fraction of a second to start, and it won't show any UI, just print a stream of debug messages.
Please post your config yml, and the output when starting camilladsp manually, but add the -v flag to get debug output. It shouldn't take more than a fraction of a second to start, and it won't show any UI, just print a stream of debug messages.
Debug mode ran great, hard to all fit in frame though so I split it into 2 pictures so that it still had enough resolution for the text to be legible. Still getting the flashing cursor at the bottom with no commands responding though, not even sudo shutdown now. Config attached too. I added them as a onedrive share since this forum needs really small image files in order to upload... too small: Microsoft OneDrive - Access files anywhere. Create docs with free Office Online.