Hi Adrian,
I just tried it with the cava version you suggested but the behavior on the OLED still seems to be the same. I now however spotted another error message at the mpd_oled service status when a track is played:
volumio@volumio:~$ systemctl status mpd_oled
● mpd_oled.service - MPD OLED Display
Loaded: loaded (/etc/systemd/system/mpd_oled.service; enabled; vendor preset:
Active: active (running) since Sun 2022-11-20 12:07:44 CET; 22s ago
Process: 1238 ExecStartPre=/usr/local/bin/mpd_oled_launch_test (code=exited, s
Main PID: 1239 (mpd_oled)
Tasks: 3 (limit: 2133)
CGroup: /system.slice/mpd_oled.service
└─1239 /usr/local/bin/mpd_oled -o SSD1309,128X64,I2C -b 10 -g 1 -c al
Nov 20 12:07:44 volumio systemd[1]: Starting MPD OLED Display...
Nov 20 12:07:44 volumio systemd[1]: Started MPD OLED Display.
Nov 20 12:08:06 volumio mpd_oled[1239]: ALSA lib pcm_hw.c:1822:(_snd_pcm_hw_open) Invalid value for card
Nov 20 12:08:06 volumio mpd_oled[1239]: error opening stream: No such device
The mpd_oled command in the output is cut off, but ends " -c al…", and so cava is reading audio data from an ALSA audio stream, presumably the loopback device. Have you configured this? The installation instructions I provide for Volumio 3 are a hack, and simply configure mpd to output to a FIFO that cava can be configured to read from. Ideally the development version would be wrapped in a Volumio 3 plugin, so it would be compatible with all audio sources. You could probably hack the existing plugin to ignore the configuration values and run a hard-coded mpd_oled development version command.
I will be reviewing the plugin situation with ALSA loopback, and so could look at a simple modification to run a hardcoded command at that time, and test with the development mpd_oled. I will also be reviewing posible issues with the current cava. It might take me a few days to do this.
I based it on the example you provided on the dev page. I also have the suspicion that alsa as source causes troubles with the setup I have. I use an allo Piano 2.1 DAC and throughout all the troubleshooting I always had issues with one or the other channel being dead when I had Piano set in dual-mono. Now that I removed parameter -c cava works and I have sound on both channels! Thank you so much!
For cava to read audio data from the loopback device there also needs to be an ALSA configuration that sends data to the loopback device, and on Volumio 3 the ALSA configuration is meant to be created using a plugin.
That makes sense. For now everything seems to be working. I guess I’ll just stick with that until your dev version goes into production. If you ever need a test candidate please let me know. I’d gladly help!
I indeed use Kali as reclocker but I dropped the line about the delay as it disappeared after I did another reboot after all those reconfigrations. Now it seems to be fine.
I looked at this and, while I couldn’t completely confirm it, I suspect that the problem is that the plugin mpd_oled binary is built for a different architecture (so it also runs on the Pi Zero) than the replacement cava binary that is built on the Pi 4.
In testing here, the plugin mpd_oled and cava work fine together. If I build mpd_oled and cava on the Pi 4 they work fine together. If I use the same cava I built on the Pi 4 with the plugin mpd_oled binary then it appears that cava crashes in some way and causes mpd_oled to crash.
I‘m running on a Pi 3 B+. Not sure if that makes any additional difference to a 4. If you want me to test any other plugin/binary combination just let me know.
@Zhapox Thanks, but I don’t think it is worth pursuing it. Previously the plugin built the mpd_oled and cava binaries from source on the Volumio machine where they would be running, so it was possible to later build a replacement cava on the same Volumio machine and it would work fine. Now that the plugin installs binaries, in order to update cava with a locally built binary will mean also building mpd_oled and updating that binary too, i.e. more work, but still possible.
@supercrab there is a potential problem that if someone builds mpd_oled from source on their machine and then later installs the plugin, then the original mpd_oled_cava binary will not be overwritten and so the plugin may crash as soon as music is played: volumio-plugins-sources/install.sh at 8fe8886851fba992e17fa2100eb668827ec18b93 · volumio/volumio-plugins-sources · GitHub I included the rename of cava to mpd_oled_cava so it wouldn’t overwrite an existing cava binary that might be used for some other purpose, so it seems fine to overwrite mpd_oled_cava. Is there a reason that the plugin doesn’t always install the mpd_oled_cava binary? Maybe previously it was to save time building the binary?
I can change the installer to not overwrite cava if it exists? Would that be any help? It was @balbuze idea to include cava I don’t know all the reasons for it, I guess to save time building.
The reason is that plugin must not compile anything. It requires to download lot of lib (build essentials + other) and takes time. Not convenient for user…
In that case, I think it is likely fine to remove the section that installs cava. The plugin installs the binary package that I provide for the normal mpd_oled binary install, and this package always installs mpd_oled_cava (to /usr/bin).
The single binary package for the lowest common requirements (build on a Pi Zero running debian Buster) will work fine on Volumio and Moode. The problems are only arising when mpd_oled and cava have been built on different machines.
That’s strange the install script will only install CAVA it is not already installed, so it won’t actaully overwrite and previous installations! From install.sh
##############################
# install CAVA if not present
if [ ! -f "/usr/local/bin/mpd_oled_cava" ]
then
echo "Installing CAVA"
sudo cp ./cava /usr/local/bin/mpd_oled_cava
sudo mkdir /usr/local/share/consolefonts
sudo cp ./cava.psf /usr/local/share/consolefonts
else
echo "CAVA already installed"
fi
If the plugin is installed on a fresh Volumio, the deb package will install mpd_oled_cava to /usr/bin, however the plugin itself will copy its own cava binary to /usr/local/bin, and this is the binary that will then be used by mpd_oled. The cava binary appears to be compatible with the deb package mpd_oled binary.
If mpd_oled is installed from source on a Pi 4 then the mpd_oled and mpd_oled_cava binaries will be installed into /usr/local/bin. If the plugin was installed before the source installation then the source installation will overwrite the plugin mpd_oled_cava. If the plugin is installed after the source installation then the plugin will not overwrite the source installation mpd_oled_cava. Either way the plugin mpd_oled will end up using the source installation mpd_oled_cava.
The plugin doesn´t need to install cava separately, as the deb package already installs it, and so the plugin code that you quoted could be removed (and the plugin cava binary). When the plugin used to install cava from source, there could sometimes be breakage due to changes in cava, and so it was useful to be able to install an older version of cava and use that. This is never needed now the plugin installs the binary package, as the version of cava is fixed.
Regarding a solution to the potential problem, it should be fairly rare for anyone to install from source on Volumio 3, and so I could just include a note in the installation documentation that installing cava from source will likely create an incompatibity with the plugin. I don’t think it is worth adding a check in the plugin. but if you feel it would be useful then maybe it could be done when mpd_oled is activated, for example popping up a warning dialogue if /usr/local/bin/mpd_oled exists.
