After stopping and starting squeezelite - No more buffer underruns! 🙂 The commenting of line 312 did the trick then.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.
Thanks a bunch!
MPD still runs at 100 %. It's MPD I use the most, so that would be nice to get working.
New release of the GUI, get it here: Release v0.5.2 * HEnquist/camillagui-backend * GitHub
This fixes (hopefully all) the bugs that were found in the previous one, and there are some cosmetic improvements of the various plots.
This fixes (hopefully all) the bugs that were found in the previous one, and there are some cosmetic improvements of the various plots.
@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.
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.
I slammed it with your command as well, just to be sure.Did you "sudo killall -9 mpd" or some other way stop the daemon so it loaded the new plugin?
This did nothing for the CPU usage.audio_buffer_size "4096"
max_output_buffer_size "131072"
Only MPD runs at 100 %. I should be able run MPD using the original configuration, because I only use it for streaming 44100.Hmmm, I really have no idea why that would be happening. Does squeezelite use 100% also?
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.
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?
Logs appear wherever stdin/stdout for the playback program appear. For squeezelite and mpd you need to specify their log locations.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.
No buffer underruns in the log, but I've heard occasional pops and small jumps. I'll test more tomorrow.
I doubt it relates to your 100% cpu problem but I just pushed a change to make mpd happier when it comes to the end of the last song at a given set of hw_params.
New release of the GUI, get it here: Release v0.5.2 * HEnquist/camillagui-backend * GitHub
This fixes (hopefully all) the bugs that were found in the previous one, and there are some cosmetic improvements of the various plots.
I assume this version is without the need for numpy/Matplotlib?
Or is it the pycamilladsp-plot which controls this?
I will ofcourse try it out soon 🙂
Jesper...
Without numpy/matplotlib! Don't worry, I won't make the gui need them again 🙂I assume this version is without the need for numpy/Matplotlib?
is the GUI...for a particular version (Linux / Windows) or universal? thanks
--never mind...read the readme/ Git. Thanks
--never mind...read the readme/ Git. Thanks
Last edited:
With 1.01 in: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?
Code:
asrsync_init(&asrs, 1.01*io->rate);
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.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?With 1.01 in:
... 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.Code:asrsync_init(&asrs, 1.01*io->rate);
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.
I tried both values if I remember right, but I'll do it again, to be sure.Can you try with 1.001, or even 1.0001?
Last edited:
The values 1.001 and 1.0001 doesn't do it either. In layman's terms it's like something is lost in the stream. The next beat comes earlier than expected. No popping sound. It happens more or less every minute, sometimes several times per minute.
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.
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.
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.
- Home
- Source & Line
- PC Based
- CamillaDSP - Cross-platform IIR and FIR engine for crossovers, room correction etc