Volumio Debian Buster Beta - Raspi images debugging

apt-get -y install chromium-browser

saying al ready have the latest …

How about force install ( apt-get -fy install chromium-browser ) ?

gonna try macmpi maybe that works…

volumio@volumio:~$ sudo apt-get -fy install chromium-browser
Reading package lists… Done
Building dependency tree
Reading state information… Done
chromium-browser is already the newest version (78.0.3904.108-rpt1).
0 upgraded, 0 newly installed, 0 to remove and 23 not upgraded.

both did nothing… new guess please …

so the by hand installed plugins show but the one the official plugin store not…
bit funny first we have it other way around …

Reason for my test was to find out if the same error (“E: Unable to correct problems, you have held broken packages.”) ashthespy experienced on a buster beta also occurs on a Jessie based system.

The “-f” option could be interesting for future install scripts though I am hesitating because it might complicate hunting down errors if packages get installed despite missing/broken dependencies and then not working.

I guess macmpi’s post about force installing was not directed at your issues. :wink:

Why did you try to install chromium-browser again? According to your earlier post I thought the touch display plugin was working now…

Edit: Culprit is the version number “1.1.9beta02”, specifically the “beta02” part… :roll_eyes:

The new zip file you find below was packaged on the latest buster beta image 3.010-2020-08-21-pi and has the plain version number 1.1.9. Its files are identical with version 1.1.9 of the plugin from the plugin store with the exception of the install and uninstall scripts which take care of the differing hardware ID used in the buster betas for Raspberry Pis.

touch_display_1_1_9busterbeta.zip (849,0 KB)

yes mine works fine :wink: look good now wait for a nice design for it :slight_smile:

On a factory reset sytem running 2.806:

sudo apt-mark showhold shows nothing

apt-cache policy raspberrypi-bootloader shows:

N: Unable to locate package raspberrypi-bootloader

After running apt-get update the result of apt-cache policy raspberrypi-bootloader is:

raspberrypi-bootloader: Installed: (none) Candidate: (none) Package pin: 1.20170703-1 Version table: 1.20170703-1 -1 500 http://archive.volumio.org/debian/ jessie/main armhf Packages

@macmpi I modified the install script of the touch display plugin by removing all fake package related lines and adding the proposed -f option to apt-get -y install chromium-browser but chromium-browser failed installing. From journalctl:

info: chromium-browser : Depends: libraspberrypi0 but it is not going to be installed

I hit a similar issue with the latest available Raspberry Pi Volumio-3.010-2020-08-21-pi on a pi 3 with IQaudIO Pi-DAC+ .

Setting I2C DAC ON and Output Device to IQaudIO Pi-DAC+ results in no sound.

Checking /etc/mpd.conf I see it has :-

device “hw:2,0”

when I see from “aplay -l” the IQaudIO Pi-DAC+ is card 3.
Manually editing mpd.conf and rebooting fixes the problem.

I also found if I enable the Volumio Simple Equalizer plugin after editing mpd.conf then this
works OK as well.

Everything else I’ve tried, e.g. Spotify etc. works fine.

Thanks for the good work

That is interesting, why does only MPD have the wrong card, but Spotify pick up the right card?

Either way, don’t edit mdp.conf but instead use this:

I didn’t bother uploading a new image for this, and would rather consolidate more fixes into a new build…

Thanks ashthespy, yes changing “/boot/cmdline.txt snd-bcm2835.enable_compat_alsa= 0” works great and is persistent after a reboot unlike changes to mpd.conf which keeps getting overwritten.

I didn’t try Spotify until after I got the IQaudIO Pi-DAC+to work by changing mpd.conf so it probably didn’t work either before.

Hi !

I’m currently testing version 3.010-2020-08-21 on a Pi3B+, and I can’t get sound out of my IQaudIO Pi-DAC Pro. I tried to follow the steps that @ashthespy advised to @steve65, but it did not solve it.

Here is my audio device list :

$ aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: Headphones [bcm2835 Headphones], device 0: bcm2835 Headphones [bcm2835 Headphones]
  Subdevices: 8/8
  Subdevice #0: subdevice #0
  Subdevice #1: subdevice #1
  Subdevice #2: subdevice #2
  Subdevice #3: subdevice #3
  Subdevice #4: subdevice #4
  Subdevice #5: subdevice #5
  Subdevice #6: subdevice #6
  Subdevice #7: subdevice #7
card 1: IQaudIODAC [IQaudIODAC], device 0: IQaudIO DAC HiFi pcm512x-hifi-0 [IQaudIO DAC HiFi pcm512x-hifi-0]
  Subdevices: 1/1
  Subdevice #0: subdevice #0

In the Web UI under Playback Options, if I choose :

  1. I2S DAC : Off and Output Device : Headphones

    $ grep hw /etc/mpd.conf
    device          "hw:0,0"
    
  2. I2S DAC : Off and Output Device : IQaudIO DAC

    $ grep hw /etc/mpd.conf
    device          "hw:1,0"
    
  3. I2S DAC : On and DAC Model : IQaudIO DAC Plus

    $ grep hw /etc/mpd.conf
    device          "hw:2,0"
    

Here is what actually happens when trying to play audio in these 3 cases :

  1. I hear audio out of the Raspberry Pi’s headphone jack
  2. I hear no audio anywhere (well, I do hear a hum out of the DAC headphone jack)
  3. Playback does not start and errors, as hw:2,0 does not exist

Before trying Volumio I tried the latest Raspberry Pi OS, and everything was working fine : even the hum in case 2 wasn’t occuring.

I did check alsamixer for any mutes or low levels. I also tried to aplay a file, which worked on RPi OS, but not on Volumio. Also, when I try it in case 2, it fails with the following message :

$ aplay -D hw:1,0 FIP\ Groove_07.wav 
aplay: main:828: audio open error: Device or resource busy 

Which indicates that MPD is effectively using the right device.

What am I missing here ?

Thanks !

After investigating a bit today, I noticed these errors in the dmesg boot log :

[   18.104406] snd-rpi-iqaudio-dac soc:sound: ASoC: failed to init link IQaudIO DAC: -517
[   18.112503] input: raspberrypi-ts as /devices/platform/soc/soc:firmware/soc:firmware:touchscreen/input/input0
[   18.113529] snd-rpi-iqaudio-dac soc:sound: ASoC: failed to init link IQaudIO DAC: -517
[   18.296883] cfg80211: Loading compiled-in X.509 certificates for regulatory database
[   18.468062] cfg80211: Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7'
[   18.596538] snd-rpi-iqaudio-dac soc:sound: ASoC: failed to init link IQaudIO DAC: -517
[   18.597019] brcmfmac: F1 signature read @0x18000000=0x15264345
[   18.614112] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43455-sdio for chip BCM4345/6
[   18.614522] usbcore: registered new interface driver brcmfmac
[   18.615907] snd-rpi-iqaudio-dac soc:sound: ASoC: failed to init link IQaudIO DAC: -517
[   18.742102] brcmfmac mmc1:0001:1: Direct firmware load for brcm/brcmfmac43455-sdio.raspberrypi,3-model-b-plus.txt failed with error -2
[   18.953105] random: crng init done
[   18.953119] random: 7 urandom warning(s) missed due to ratelimiting
[   18.973399] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43455-sdio for chip BCM4345/6
[   18.996082] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM4345/6 wl0: Mar  2 2020 23:30:41 version 7.45.202 (r724630 CY) FWID 01-72f6ece2 

Any idea what might cause this ?

It looks like my last message may not be relevant, as I get these same errors in the boot log of Raspberry Pi OS and it works fine.

[   18.615907] snd-rpi-iqaudio-dac soc:sound: ASoC: failed to init link IQaudIO DAC: -517

Hello to all,
Currently I am using test version 2.847. I use button plugin, led for status volumio and rpi4 status, when is powered on. My connection is wired Lan… Also I am using 4.3 inch dsi touchscreen and mpd oled script on an 1.3 inch oled.
I would like to switch to buster image due to python 3 version cause I would like to install mpd2chromecast and peppy meter.
If I will switch to beta buster image I will be able to still use the configuration from above and of course new qobuz beta mode or when new implementation from qobuz will be released officially I still be able to use it on this new buster image?
Thanks in advance

You should go with the Nodev8 version (please see the first post) build then to ensure you don’t have to recompile core modules for those plugins.

Hmm, Unfortunately at this stage there all the MyVolumio stuff is untested with Buster. I built a test image a few months back, but since it contains closed source things, I would rather someone from the core Volumio team check and then release that image :wink:

Kernel 5.x+ does not load the “rpi_ft5406” module anymore but the “raspberrypi_ts” module when a Raspberry Pi Foundation touchscreen is connected. This required an adaption of the Touch Display plugin: touch_display_1_2_1Busterbeta.zip (793,3 KB)

it’s still running over here ash it’s missing some folders for the plugin’s but
runs mutch better than the latest release i can say …
yt plugin (doesn’t search yt any more), auto start, system,
touch display, local music and radio runs well …
it’s for me the best release only you have to do all by hand…

ash are you still working on the 3.10 or is it gone?

There should be a link to the 5.4 kernel version in the opening post - but be ready to set up more by hand :wink:

i got a version bit tweaked runs smooth only yt plugin bug some times
but that is normal…

Hello all friends!

I tested Volumio 3.0 and found that:
The operating system runs really well, and it’s fast, the sound seems pure.
Stores USB scan history
the big downside I see all volumio versions have is: the boot speed is very slow when the music files increase for example:
Hard drive contains 1T of music: boot speed is: 1 min 30 s. 2 Tb music: 2 minutes. This is bad, because I tried the Moodeaudio, it was very smart, it stored the first scan and the boot time was very fast, only 50 S, and regardless of the number of songs and hard drive space!

So can you handle this? ie the start-up speed is independent of the number of music files, and retains the first scan history ??
Thank you very much!
Mac

Hey @mac
What pi are you running this on?
This is a pet project that I would like to investigate - the slowdown during boot due to database scanning. It’s some quirk with the async code. However, I don’t really have a large music collection, as I mostly stream these days. So if you don’t mind - could you share your /var/lib/mpd/tag_cache (privately) with me? I’d like to play around a bit to see where the bottleneck is :slight_smile:

Cheers,