Result!
here is some interesting technical data, that might be use full.
Well done! 
I think I’m gonna pick up one of these to USB adapters 
Just follow the instruction and it should work.
- CAVA needs to be sorted out.
- A way to get the bus address fixed, as currently after every reboot it changes.
1 Like
Thanks! Now I have to pick up a little x86 machine too 
Well 45 euro, for a Dell Wyse 3040, great little piece of hardware. Still a few left.
I had noticed you were using a Del Wyse! I’ve never used one myself but that’s an excellent price for what you get. Also, the super slim Dell USFF Optiplexs are also pretty good, I’m thinking about getting one for plex and now and another for Volumio 
Also got CAVA running, a bit dirty but it works.
(just ran sudo bash mpd_oled_volumio_install_latest.sh, which took care of the CAVA part.)
The bars run smooth, so no issues with frame rates.
Seems we have a winner, a working POC
3 Likes
Did helpt me om er toch dicht bij te blijven.
Super job!
Soms denk ik, “69, and why the hell still doing this”…
Yep, and the most annoying part of it, I start thinking who the F is the boss, this 200 cents display or me… So I keep on digging.
And finally 3 days lost for a lousy 35 lines of code…
Some notes:
I built the i2c-ch341-usb module on linux v5.15, rather than on v5.10 that Volumio uses, and this required a code change to the module. Hopefully by the time Volumio uses a later kernel the module code will be updated and will build without any changes.
Although this thread refers to x86, it is more about a general linux solution for running mpd_oled (e.g. the adapter could also be used with mpd_oled on the Raspberry Pi). The short instructions are
- install a kernel driver for any I2C/SPI/GPIO connection/adapter that is used to connect the screen.
- use the development version of mpd_oled GitHub - antiprism/mpd_oled_dev: mpd_oled development version (unstable)
The development version of mpd_oled is just a quick modification I made to the current version of mpd_oled in order to test the feasibility of using U8g2. And… the U8g2 library it links with is a combination of U8g2 and a linux port, which I modified to support user specified bus numbers. The U8g2 code is assembled and modified by a flaky script that builds all the code into a single binary (splitting some fonts into separate libraries to avoid licensing issues) so that the OLED driver can be specified at run time, and adds in some extra code to enable this. In other words, while the development version of mpd_oled is functional, it should be considered early development. Also, the project is stalled and “unsupported”, in that I might help out with installation but I probably won’t make code changes (e.g. I notice the loop of the letter g is cut off in the bottom line of the screenshot I posted earlier, but I won’t fix this until I resume development).
Adrian.
Thanks for the update.
The main concern at this point, is the fact that the i2C bus keeps changing per reboot. Haven’t found a way to force it, as it’s generated dynamically.
tried with a rule, but it’s not working.
ACTION==“add”, SUBSYSTEMS==“i2c-dev”, ATTRS{idProduct}==“5512”, ATTRS{idVendor}==“1d6b”, ATTRS{name}==“i2c-ch341-usb at bus 003 device 003”, SYMLINK+=“i2c-14”
So bus_number=x
1 Like
Forcing the bus number would be a good solution if it can be made to work.
A not-so-good alternative is that mpd_oled could be wrapped in a script that adds the bus number. The USB port that the adapter is plugged into is known (in case there is more than one adapter), and so the dmesg output could be parsed to extract the bus number from the last entry for this USB port where the adapter is assigned an I2C bus number, and then the mpd_oled command rewriiten to specify it.
What is your main project at the mo?
1 Like
Just playing around, but this is a dirty solution, but working for the time being.
/usr/local/bin/mpd_oled -o SSD1306,128X64,I2C,bus_number=$(dmesg | grep -iE "i2c-ch341-usb 3-6:1.0: ch341_i2c_probe: created i2c device" | sed 's/^.*[/]//' | sed 's/.*-//') -f 50
I am not currently working on anything (!), but hopefully that won’t be for too much longer.
1 Like
For the smart ones:
If I start mpd_oled via a service (executing a bash script), 2 pipes are created, but CAVA won’t work.
If I start the same script manual, 2 new pipes are created and CAVA works.
Which logic am I missing here?
Is the same mpd_oled command being run in both cases? You could print the contents of the two cava_config_XXXXXXX files and see if cava is reading audio data from the same place.
Not working:
volumio@volumio-x86-s2:~$ sudo cat /tmp/cava_config_H9ldn8
[general]
framerate = 50
bars = 16
[input]
method = fifo
source = /tmp/mpd_oled_fifo
[output]
method = raw
data_format = binary
channels = mono
raw_target = /tmp/cava_fifo_1757
bit_format = 8bit
volumio@volumio-x86-s2:~$
Working:
volumio@volumio-x86-s2:~$ sudo cat /tmp/cava_config_4yHvuo
[general]
framerate = 50
bars = 16
[input]
method = fifo
source = /tmp/mpd_oled_fifo
[output]
method = raw
data_format = binary
channels = mono
raw_target = /tmp/cava_fifo_1977
bit_format = 8bit
volumio@volumio-x86-s2:~$
both uses the same script…
Not working is started via a service:
volumio@volumio-x86-s2:~$ sudo cat /lib/systemd/system/oled.service
[Unit]
Description=MPD OLED Plugin
After=network.target sound.target mpd.service
Requires=mpd.service
[Service]
ExecStart=/bin/bash /home/volumio/scripts/start_mpd.sh
[Install]
WantedBy=multi-user.target
The working one started via putty.
./start_mpd.sh
#/bin/bash
sleep 10s
/usr/local/bin/mpd_oled -o SSD1306,128X64,I2C,bus_number=$(dmesg | grep -iE "i2c-ch341-usb 3-6:1.0: ch341_i2c_probe: created i2c device" | sed 's/^.*[/]//' | sed 's/.*-//') -f 50
The config files seem fine. I recommend stopping the mpd_oled service, checking no copies of mpd_oled or mpd_oled_cava are running, then restart mpd and then start the mpd_oled service again. Sometimes when running a lot of test mpd_oled commands the spectrum fails to work for some reason, and so checking using a fairly fresh state should hopefully discount this.