CamillaDSP - Cross-platform IIR and FIR engine for crossovers, room correction etc.

After you do the sudo make install you need to kill any running mpd / squeezeilte processes and restart them. Otherwise they will not reload the changed plugin and obviously there would be no difference.
After stopping and starting squeezelite - No more buffer underruns! :) The commenting of line 312 did the trick then.

Thanks a bunch!

MPD still runs at 100 %. It's MPD I use the most, so that would be nice to get working.
 
@audiac good to hear the underruns stopped in squeezelite.

Did you "sudo killall -9 mpd" or some other way stop the daemon so it loaded the new plugin?

There are the only two settings I see in the mpd.conf I use on a raspberry pi that might have an effect. They're just defaults from moode. mpd only takes a few % of processing.

audio_buffer_size "4096"
max_output_buffer_size "131072"

To everyone else, I'm curious if you comment out line 312 if everything still works ok for you.
 
Hmmm, I really have no idea why that would be happening. Does squeezelite use 100% also?
Only MPD runs at 100 %. I should be able run MPD using the original configuration, because I only use it for streaming 44100.

Regarding the fix in line 312. I think I hear skipping now, or small jumps forward in time, that occur now and then. So you'll better keep that row as is until it's really clear if its needed or not.


I'll continue investigating another day. Which log might tell if there are problems with the playback? syslog doesn't tell anything this time.
 
Regarding the fix in line 312. I think I hear skipping now, or small jumps forward in time, that occur now and then. So you'll better keep that row as is until it's really clear if its needed or not.


I'll continue investigating another day. Which log might tell if there are problems with the playback? syslog doesn't tell anything this time.
Logs appear wherever stdin/stdout for the playback program appear. For squeezelite and mpd you need to specify their log locations.
 
I just pushed a change to plugin for some requests from Henrik. I included a fix to make the internal clock run fast. @audiac could you see if this fix works for you in terms of under runs?
With 1.01 in:
Code:
asrsync_init(&asrs, 1.01*io->rate);
... I can hear pops and small jumps that affects the timing of the music. I now listen with 1.0 and don't think I've heard anything strange yet. No underruns either.
 
I just pushed a change to plugin for some requests from Henrik. I included a fix to make the internal clock run fast. @audiac could you see if this fix works for you in terms of under runs?

With 1.01 in:
Code:
asrsync_init(&asrs, 1.01*io->rate);
... I can hear pops and small jumps that affects the timing of the music. I now listen with 1.0 and don't think I've heard anything strange yet. No underruns either.
With 1.0 there is a risk of underruns. The rates probably vary a little so it happens some days but not others. Can you try with 1.001, or even 1.0001?
 
I can now say with confidence that the plugin does not work good enough for me, regardless of the factor for the internal clock. I think it's worse for 48000 than for 44100, if that can be a clue. If anyone else got it working perfectly, please tell.


Can you try with 1.001, or even 1.0001?
I tried both values if I remember right, but I'll do it again, to be sure.
 
Last edited:
Thinking about using CamillaDSP for crossover computations on my Raspi 4b. Also thinking about using it for Ambiphonic speaker crosstalk cancellation. Apparently the latest filtering algorithms for it use long FIR filters, which can be computed efficiently using partitioned convolutions which I seem to remember that Camilla can do.

Has anyone experimented with / know of any open source ambiphonic DSP algorithms?? This would be pretty exciting.
 
Sorry @audiac, I tried. Something is clearly odd with the plugin and your configuration because mpd shouldn't be using 100% CPU. I've certainly fought through lots of ALSA issues to get it this far and this is it for me.

If you want to try one more thing I'm curious if threading is still an issue with the IO plugin in some cases. It certainly shouldn't be but who knows. If you're done with it all I don't blame you.

If you're curious try changing the #if line here to #if 1 so it always disables the thread-safe API. At least see if it changes the mpd CPU utilization.

Code:
#if SND_LIB_VERSION >= 0x010102 && SND_LIB_VERSION <= 0x010103
  /* ALSA library thread-safe API functionality does not play well with ALSA
   * IO-plug plug-ins. It causes deadlocks which often make our PCM plug-in
   * unusable. As a workaround we are going to disable this functionality. */
  if (setenv("LIBASOUND_THREAD_SAFE", "0", 0) == -1)
    SNDERR("Couldn't disable ALSA thread-safe API: %s", strerror(errno));
#endif
 
Thank You seashell for making your software publicly available, and trying to make it work for me! Unfortunately the #if 1 fix didn't make any difference for MPD's CPU usage. I can test more in the future if you make any changes that you think can solve the problems I've had with the plugin. I hope it works as intended for everybody else.