Initial WM8960 Support

[hftsai256]

Initial Waveshare WM8960 Audio HAT support. Requires a separated archive:
/lib/modules/5.4.83+/kernel/sound/soc/codecs/snd-soc-wm8960.ko
/lib/modules/5.4.83+/kernel/sound/soc/bcm/snd-soc-wm8960-soundcard.ko
/boot/overlays/wm8960-soundcard.dtbo

Can those kernel modules be built under qemu-static environment?

[hftsai256]

alsanum varies across different SBC (1 on pi zero, 2 on pi 3B+/4). I think it is used for collecting amixer from console, but amixer can also take alsacard as an argument, e.g.:

volumio@voluzero:~$ amixer -c wm8960soundcard
Simple mixer control 'Headphone',0
  Capabilities: pvolume
  Playback channels: Front Left - Front Right
  Limits: Playback 0 - 127
  Mono:
  Front Left: Playback 109 [86%] [-12.00dB]
  Front Right: Playback 109 [86%] [-12.00dB]
...

I believe we could deprecate alsanum field?

[ashthespy]

Small request for clarity down the line - could you move your changes to i2s_dacs/index.js into a new commit and force push?

Out of curiosity, why does this DAC require both modules and the overlay? The device tree should technically load the modules right?

[hftsai256]

Out of curiosity, why does this DAC it require both modules and the overlay? The device tree should technically load the modules right?

Well... Yes and no. I reached this thread and checked the default kernel configuration. Turns out CONFIG_SND_SOC_WM8960 is not set by default and I believe the majority of Volumio users wouldn't bother (or don't know how) to build their own kernel for the device.

[ashthespy]

Out of curiosity, why does this DAC it require both modules and the overlay? The device tree should technically load the modules right?

Well... Yes and no. I reached this thread and checked the default kernel configuration. Turns out CONFIG_SND_SOC_WM8960 is not set by default

Correct, but that is to compile the kernel module, which thanks to your other PR in the build repo will bake the required modules into the image.

The overlay normally should then be able to pick the compiled modules up, without having to additionally manually load them right?

[hftsai256]

The overlay normally should then be able to pick the compiled modules up, without having to additionally manually load them right?

Just confirmed simply loading the overlay will also pull in the related kernel module, which is snd_soc_wm8960. I guess I was missing i2c-dev so the device won't talk.

volumio@voluzero:~$ cat /etc/modules
i2c-dev
volumio@voluzero:~$ lsmod | grep wm8960
snd_soc_wm8960         40960  1
regmap_i2c             16384  1 snd_soc_wm8960
snd_soc_core          200704  4 snd_soc_simple_card_utils,snd_soc_bcm2835_i2s,snd_soc_wm8960,snd_soc_simple_card
snd_pcm                94208  5 snd_pcm_dmaengine,snd_soc_bcm2835_i2s,snd_bcm2835,snd_soc_core,snd_soc_wm8960
snd                    73728  12 snd_compress,snd_seq,snd_timer,snd_seq_device,snd_bcm2835,snd_soc_core,snd_soc_wm8960,snd_pcm

This kernel option is kinda likely being overlooked, because CONFIG_SND_SOC_WM8960 option doesn't show up in any of bcm{2709|2711|2835|rpi}_defconfig. We could:

1. Host the kernel module separately as this PR is doing
2. Build our own flavored kernel
3. File an issue to raspberrypi/linux and request a fix upstream (here)

[ashthespy]

Great work, sorry if my comments have led you down the rabbit hole ;-)

Ideally, option 3 would be best, as CONFIG_SND_SOC_WM8960 should also have a depend that should ensure i2c-dev gets loaded as well. Then you'd only have to load the device tree overlay.

Until it's fixed upstream, we could use the modules that you have built.

I would really like to avoid custom kernels for the pi, will be less maintenance effort, we (well @gkkpch) already has multiple platforms that use special kernels.

[hftsai256]

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) in order to get the sound out. I'm a bit surprised about it because tuning those volumes in alsamixer won't help, and am curious about what's the magic under the hood to make it work.

I've figured out the actual config that mutes both output channels by default, and worked out a new commit to unmute those channels in the init script.

[hftsai256]

Finally this works OOB after initial setup wizard + reboot

[EDIT] Kernel v5.4.y received this patch. At this moment I made an automated build/package script to deploy kernel modules across multiple platforms to work with another PR.

[ashthespy]

@hftsai256 Don't have hardware to test this -- but it looks good to me!
See my comments over at volumio/Build#513 (comment) we should be fine using the modules from wm8960-rpi-modules until we switch to 5.10.yy that has everything baked in.