Waveshare WM8960

hi, is it possible to make an image of your working volumio with the WM8960 HAT?

I can’t get it to work…

Thanks

Hi,

Im trying to get this wm8960 working on a RPi Zero, but I can’t seem to get past the “resizing of the /boot partition”, and is stuck with the ‘linux-image-3.6-trunk-rpi’ error message.

Whatever I do, I cant find any way to resize it, and im stuck.
I found this page which sums up my problem, but still haven’t got it working:

What have you guys done to successfully do this resizing?

Resize the boot partition on Linux with gparted. (with error when gparted verifies the boot partition)
With a Windows PC (maybe possible with Linux), save all the files present on the fat32 partition.
From Disk Manager format the partition (FAT32). The new partition size is applied.
Move all saved files to the fat32 partition.

But for me the install.sh command failed… (ZeroW)

Hi , how can I extend the /boot partition from 60M to e.g. 100M?
It doesn’t work with raspi-config.
Clearing space under /boot: what can I delete?

It worked!

So the steps you have to take!

  1. Download and install Volumio version 2.692 on a SD
    Older volumio versions .img files - #3 by tobidud
  2. Let it run and install it and select HDMI as output
  3. Shut it down, take the SD and put it on another linux/raspberry pi pc and use gparted to change the boot partition size to 100MB(it’s possible it gives a small error, but the important thing is that your FAT partition is around 100MB)
  4. put it back in to your RP ZW and start up
  5. add the rule in the /volumio/app/plugins/system_controller/i2s_dacs/dacs.json file

Blockquote

{“id”:“wm8960-soundcard”,“name”:“Waveshare - WM8960”,“overlay”:“wm8960-soundcard”,“alsanum”:“0”,“mixer”:“Digital”,“modules”:"",“script”:"",“i2c_address”:“1a”,“needsreboot”:“yes”},

Blockquote

  1. sudo volumio kernelsource
  2. git clone -b rpi-4.9.y https://github.com/waveshare/WM8960-Audio-HAT.git
    cd WM8960-Audio-HAT
    sudo ./install.sh
    sudo reboot
  3. You should hear a sound when it is finished turning on.
  4. Go to your browser and go to your volumio page, open the play options
  5. put on I2S DAC and choose the Waveshare -WM8960 and save, it will reboot
  6. For making the sound level go to the max:
    go into alsamixer(just type it in a shell) and put the speakers to the max
  7. Now for making the volume change(go up and down) you have to play with the volume options in the browser, I choose mixer type Software
  8. Now the volume can be changed and “everything” should work(small stuff that doesn’t work like pausing music played from another source is a Volumio problem).

Although reverting back to version 2.692 is the easiest way to get things up and running, I took a dip on version 2.882 and figured out that it is required to add Stretch repository into package lists (under /etc/apt/sources.list), referring to this post

deb http://raspbian.raspberrypi.org/raspbian/ stretch main contrib non-free rpi

Also, in order to build kernel properly, the following packages are required:

  • libssl-dev

There are several error messages while running volumio kernelsource command:

tar: include/dt-bindings/input: Directory renamed before its status could be extracted
tar: include/dt-bindings: Directory renamed before its status could be extracted
tar: include: Directory renamed before its status could be extracted
tar: arch/arm64/boot/dts/broadcom: Directory renamed before its status could be extracted
tar: arch/arm64/boot/dts/arm: Directory renamed before its status could be extracted
tar: arch/arm64/boot/dts: Directory renamed before its status could be extracted
tar: arch/arm64/boot: Directory renamed before its status could be extracted
tar: arch/arm64: Directory renamed before its status could be extracted
tar: arch: Directory renamed before its status could be extracted
tar: Exiting with failure status due to previous errors
...
  HOSTCC  scripts/extract-cert
Linking Modules
ln: failed to create symbolic link ‘/lib/modules/4.19.118+/build/rpi-linux’: File exists

I don’t know what the script is trying to do, but those errors don’t look right to me. More over, the install.sh from branch rpi-4.9.y installs linux headers 3.6, which doesn’t make sense to me neither.

Anyway. In the end it kinda built dmks modules and have them installed as:

volumio@voluzero:~$ sudo dkms status
wm8960-soundcard, 1.0, 4.19.118+, armv6l: installed

Yet those built kernel modules are not loaded properly, even though both snd-soc-wm8960.ko and snd-soc-wm8960-soundcard.ko are installed in place (as indicated in install.sh)

volumio@voluzero:~$ sudo systemctl status systemd-modules-load.service
● systemd-modules-load.service - Load Kernel Modules
   Loaded: loaded (/lib/systemd/system/systemd-modules-load.service; static)
   Active: failed (Result: exit-code) since Fri 2021-07-09 02:10:59 UTC; 2s ago
     Docs: man:systemd-modules-load.service(8)
           man:modules-load.d(5)
  Process: 1198 ExecStart=/lib/systemd/systemd-modules-load (code=exited, status=1/FAILURE)
 Main PID: 1198 (code=exited, status=1/FAILURE)

Jul 09 02:10:59 voluzero systemd-modules-load[1198]: Failed to insert 'snd_soc_wm8960': No such file or directory
Jul 09 02:10:59 voluzero systemd-modules-load[1198]: Failed to insert 'snd_soc_wm8960_soundcard': No such file or...tory
Jul 09 02:10:59 voluzero systemd[1]: systemd-modules-load.service: main process exited, code=exited, status=1/FAILURE
Jul 09 02:10:59 voluzero systemd[1]: Failed to start Load Kernel Modules.
Jul 09 02:10:59 voluzero systemd[1]: Unit systemd-modules-load.service entered failed state.

Adding them though modprobe won’t help neither:

[  133.676462] snd_soc_wm8960: Unknown symbol __sanitizer_cov_trace_pc (err -2)
[  133.682986] snd_soc_wm8960_soundcard: Unknown symbol __sanitizer_cov_trace_pc (err -2)

so if I understand it wright. Leave it like it is and don’t try to update? :slight_smile:

Exactly. It will take me a while to understand the image builder architecture and automate/fix the process from the ground, but that would be the way to go if we really want to bring this up.

I’m already glad that I got it to work! It really was a battle to get it to work.

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:

#!/bin/bash
sudo volumio kernelsource
git clone https://github.com/waveshare/WM8960-Audio-HAT.git
cd WM8960-Audio-HAT
git reset --hard cd5d2e01a80cce929ea64715ed73d1b91cd5ba50
sudo ./install.sh
Moved from Volumio 3 Buster Beta for RPi

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)

Error Log:
http://logs.volumio.org/volumiobuster/7YXhJy2.html

WM8960 Module install script:
(refer to this post)
wm8960.txt (1.1 KB)

Thanks for your efforts @hftsai256, I see you closed that PR, but I left a note anyway :slight_smile:

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? :stuck_out_tongue:
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.


When Volumio decides to moves away from Jessie, we should be able to switch the default branch and archive the old stuff, so others don’t spend time as you did.There is some history at [Proposal] Make build system more modular · Issue #413 · volumio/Build · GitHub if you are interested.

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?

This configuration is normally propagated by the DACS.json file, and should match your definition as per the aplay output…


card 1: wm8960soundcard [wm8960-soundcard], device 0: bcm2835-i2s-wm8960-hifi wm8960-hifi-0 [bcm2835-i2s-wm8960-hifi wm8960-hifi-0]
  Subdevices: 1/1
  Subdevice #0: subdevice #0

From a quick glance at your PR, you might have to update the line you have, as it is for the older v2 version of Volumio.

{ 
"id":"wm8960-soundcard",
"name":"Waveshare - WM8960",
"overlay":"wm8960-soundcard,i2s-mmap",
"alsanum":"1",
"mixer":"",
"modules":"",
"script":"",
"i2c_address":"1a",
"needsreboot":"yes"
},

For the modular Alsa, you need a few more keys in the DAC entry - have a look at Merge ALSA pipeline into buster development by timothyjward · Pull Request #2040 · volumio/Volumio2 · GitHub for more details. Oh and of-course, the back-end code for Buster tree is not master…
EDIT:
Help from Volumio community for a new feature - #29 by ashthespy might also be helpful to figure out the mapping of id, name etc.

Thanks again for the pointers. I’ve figured out the proper json string to wm8960 DAC:

{"id":"wm8960-soundcard",
"name":"Waveshare - WM8960",
"overlay":"wm8960-soundcard,i2s-mmap",
"alsanum":"1",
"alsacard":"wm8960soundcard",
"mixer":"Speaker",
"modules":["i2c-dev","snd-soc-wm8960","snd-soc-wm8960-soundcard"],
"script":"",
"i2c_address":"1a",
"needsreboot":"no"}

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);
  }

[Edit] Volumio2 PR and Build PR are up for discussion.

@hftsai256 Does the upstream wm8960-soundcard overlay not work properly for this board?

I could be wrong, but from a quick look at the commits in wm8960.c, it looks like the clock fixes are now in the upstream codec as well?

I believe it would work, even though the one upstream is slightly different. A quick diff shows:

$ diff -bBw ${rpi-linux}/wm8960-soundcard-overlay.dts ${WM8960-Audio-HAT/wm8960-soundcard.dts
1d0
< // Definitions for Waveshare WM8960 https://github.com/waveshare/WM8960-Audio-HAT
6c5
< 	compatible = "brcm,bcm2835";
---
>     compatible = "brcm,bcm2708";
80a83
>         master = <0>,"=2!3";

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.