The build module in master branch is terribly broken and is nowhere close to get it up and running. After pulling my heir multiple times I finally realized that recent developing activities are moving over volumioOS branch, with kernel version bumped to 5.4.83 – This draws another story as WaveShare patched up their master branch to match API changes in kernel version 5.10.y and will cause compiling error.
I’m putting together a PR to volumioOS branch here and hope we can have this support OOB, but there are still some problems. At this moment, you could try to build your own image based on Debian Buster (kernel 5.4.83+) by checking out volumioOS branch, and then do the following things once you can ssh to the pi:
I can play pink noise through my audio HAT (Waveshare WM8960 Audio HAT) with speaker-test -Dsysdefault:wm8960-soundcard -c2, but seems like volumio is not getting the correct audio card.
Error Message:
Failed to open ALSA device “volumio”: No such device
HW Configuration:
Raspberry Pi Zero W + Waveshare WM8960 Audio HAT
Image version:
Volumiobuster-3.078-2021-07-01-pi
(Or nightly build, please refer to this PR)
Thanks @ashthespy. Before re-open that PR, I think I am going to figure out a structured build system to generate those artifacts and maybe host those binaries in my Github repository.
However there’s a separate issue that Volumio is calling the (at least it is obvious to me) wrong audio device to mpd. Is there any detailed log I can check or can you point out where does the API call take place in Volumio2 repo? I’m not familiar with node.js debugger but have something to print is good enough for me to dig further.
BTW is there a discussion about CI/CD, deployment structure and unit-test framework? I found it quite difficult to trace the development work from READMEs and available documents.
I did manage to get these out-of-tree kernel modules built in containers so that they can be deployed via CI/CD.
But then life and summer came in the way. I’m away from dev machine for a few weeks, but will share when I am back if you are interested.
unit-test what?
The motivation behind my rewrite of the build system was to modularise it for ease of development, DRY, and so it can run in containers. Since my normal machines are all Windoze boxes, I build all my images via CircleCI… But, AFAIK the official Voumio images aren’t build by a CI/CD, and runs on Volumio’s servers to include the myVolumio closed source stuff.
It looks like you alsa configuration is wrong and is looking for a MAX98357A instead of the wm8960soundcard ?
pcm.!default {
type copy
slave.pcm "volumio"
}
pcm.volumio {
type copy
slave.pcm "volumioOutput"
}
# There is always a plug before the hardware to be safe
pcm.volumioOutput {
type plug
slave.pcm "volumioHw"
}
pcm.volumioHw {
type hw
card "MAX98357A"
}
Thank you very much for pointing it out. I educated myself to merge the asound.conf with the vender-provided one. The following works beautifully with speaker-test -Dvolumio:
pcm.!default {
type copy
slave.pcm "volumio"
}
pcm.volumio {
type copy
slave.pcm "volumioOutput"
}
# There is always a plug before the hardware to be safe
pcm.volumioOutput {
type plug
slave.pcm "volumioHw"
}
pcm.volumioHw {
type copy
slave.pcm "wm8960"
}
defaults.pcm.rate_converter "samplerate"
pcm.wm8960 {
type asym
playback.pcm "playback"
capture.pcm "capture"
}
pcm.playback {
type plug
slave.pcm "dmixed"
}
pcm.capture {
type plug
slave.pcm "array"
}
pcm.dmixed {
type dmix
slave.pcm "hw:wm8960soundcard"
ipc_key 555555
}
pcm.array {
type dsnoop
slave {
pcm "hw:wm8960soundcard"
channels 2
}
ipc_key 666666
}
However I’m not feeling good from SW management/engineering aspect, and just as I expected, it would be overriden whenever I change the Audio Output Device in Web Interface.
[Edit] Figured out when the config file is overriden. However it doesn’t seem like to be the case. May you again show me where is the configuration maintained in Volumio backend?
However in the current index.js it wouldn’t touch overlay if modules has assigned values. I’d propose to separate modules and overlay control logics such as:
if (modules) {
this.config.set('i2s_id', id);
self.writeModulesFile(modules);
}
if (overlay) {
self.revomeAllDtOverlays();
self.writeI2SDAC(overlay);
if (script) {
self.hotAddI2SDAC({'overlay': overlay, 'script': script});
} else {
self.hotAddI2SDAC({'overlay': overlay});
}
this.config.set('i2s_id', overlay);
}
AFAIK master override is not doing anything, and bcm2835/bcm2708 are basically the same thing with different packaging.
Looks like the one merged into upstream would detect the proper clock of the device… it is kinda out of my scope to figure out if it works, but my gut tends to believe it.
Unfortunately my wm8960 hat seems to be broken – SW/FW still works, but not sound output from speaker terminal nor headphone jack.
[EDIT] I can confirm that the card is detectable/accessible with upstream overlay dtbo and upstream (fixed) kernel module snd-soc-wm8960.ko only.
With that being said, I was thinking about: being a targeted OS distribution, wouldn’t it make sense to build our own kernel with all in-tree codecs enabled? I can recall there’s an “rpi update” phase during the build to push kernel to version 5.4.83+, and I wonder if we could put in a customized .config file for it.
I poked around and was trying to figure out the “no sound” problem on my board while waiting reposes from the issue filed upstream. Turns out in addition to kernel modules (which the two PRs mentioned above have it implemented properly), wm8960_asound.state from official repo has to be applied with a refresh (alsactl nrestore).
Just few minutes ago the issue was responded and the module will be in future kernel builds (yay). Let’s defer implementation details to Github PR thread.
make -j1 KERNELRELEASE=5.10.90+ -C /lib/modules/5.10.90+/build M=/var/lib/dkms/wm8960-soundcard/1.0/build…(bad exit status: 2)
Error! Bad return status for module build on kernel: 5.10.90+ (armv6l)
Consult /var/lib/dkms/wm8960-soundcard/1.0/build/make.log for more information.
Created symlink /etc/systemd/system/sysinit.target.wants/wm8960-soundcard.service → /lib/systemd/system/wm8960-soundcard.service.
Blockquote
DKMS make.log for wm8960-soundcard-1.0 for kernel 5.10.90+ (armv6l)
Sun Aug 28 20:05:00 UTC 2022
make: Entering directory ‘/usr/src/rpi-linux’
CC [M] /var/lib/dkms/wm8960-soundcard/1.0/build/wm8960.o
/var/lib/dkms/wm8960-soundcard/1.0/build/wm8960.c:1390:3: error: ‘struct snd_soc_dai_driver’ has no member named ‘symmetric_rate’; did you mean ‘symmetric_rates’?
.symmetric_rate = 1,
^~~~~~~~~~~~~~
symmetric_rates
/var/lib/dkms/wm8960-soundcard/1.0/build/wm8960.c:1390:20: warning: initialization of ‘const struct snd_soc_cdai_ops *’ from ‘int’ makes pointer from integer without a cast [-Wint-conversion]
.symmetric_rate = 1,
^
/var/lib/dkms/wm8960-soundcard/1.0/build/wm8960.c:1390:20: note: (near initialization for ‘wm8960_dai.cops’)
make[1]: *** [scripts/Makefile.build:280: /var/lib/dkms/wm8960-soundcard/1.0/build/wm8960.o] Error 1
make: *** [Makefile:1825: /var/lib/dkms/wm8960-soundcard/1.0/build] Error 2
make: Leaving directory ‘/usr/src/rpi-linux’
