latest 2019-04-08-raspbian-stretch issue

[labomb]

My phat beat has been working fine on the prior release of stretch (2018-11-13-raspbian-stretch), but there appears to be an issue with the latest version.

It's a new install, ran 'sudo curl -sS get.pimoroni.com/phatbeat | bash' without issue, and the speaker-test from the command line works great. But in the desktop environment , the audio device is disabled (the task bar speaker icon has a red 'X', and the volume control is disabled). When clicking on the speaker icon, it shows snd_rpi_hifiberry_dac with a green checkmark, but when I attempt to open device settings via the task bar or via Audio Device Settings in Preferences, a popup window appears with the error "No ALSA Devices Found".

Not sure if this is a pulseaudio vs alsa issue, but any suggestions would be welcome.

[Gadgetoid]

What do you see if you aplay -l and aplay -L in terminal?

Edit: Have set up the latest release and managed to replicate this. I believe the cross over the speaker is normal, since the i2s device has no volume control. You should still get audio through pHAT BEAT?

[labomb]

Here is the the output for each command:

pi@rpi-r:~ $ aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: sndrpihifiberry [snd_rpi_hifiberry_dac], device 0: HifiBerry DAC HiFi pcm5102a-hifi-0 []
  Subdevices: 0/1
  Subdevice #0: subdevice #0

pi@rpi-r:~ $ aplay -L
null
    Discard all samples (playback) or generate zero samples (capture)
pivumeter
softvol_and_pivumeter
default
    Playback/recording through the PulseAudio sound server
sysdefault:CARD=sndrpihifiberry
    snd_rpi_hifiberry_dac,
    Default Audio Device
dmix:CARD=sndrpihifiberry,DEV=0
    snd_rpi_hifiberry_dac,
    Direct sample mixing device
dsnoop:CARD=sndrpihifiberry,DEV=0
    snd_rpi_hifiberry_dac,
    Direct sample snooping device
hw:CARD=sndrpihifiberry,DEV=0
    snd_rpi_hifiberry_dac,
    Direct hardware device without any conversions
plughw:CARD=sndrpihifiberry,DEV=0
    snd_rpi_hifiberry_dac,
    Hardware device with all software conversions

After a bit more research, I've determined that the problem is with pulseaudio. More specifically, the problem is with pulseaudio when connecting to the pi via VNC... which was not a problem prior to the April '19 release of stretch.

Initially, I discovered the following errors in syslog:

Apr 16 15:40:51 rpi-r pulseaudio[967]: Using device: phat-beat
Apr 16 15:40:51 rpi-r pulseaudio[967]: [pulseaudio] server-lookup.c: Unable to contact D-Bus: org.freedesktop.DBus.Error.NotSupported: Unable to autolaunch a dbus-daemon without a $DISPLAY for X11
Apr 16 15:40:51 rpi-r pulseaudio[967]: [pulseaudio] main.c: Unable to contact D-Bus: org.freedesktop.DBus.Error.NotSupported: Unable to autolaunch a dbus-daemon without a $DISPLAY for X11

I was able to address this by adding:

Environment=DISPLAY=:0

to the [Service] section in file: /etc/systemd/system/pulseaudio.service.

Now I see the following errors:

Apr 16 15:46:19 rpi-r pulseaudio[949]: Using device: phat-beat
Apr 16 15:46:19 rpi-r pulseaudio[949]: [pulseaudio] server-lookup.c: Unable to contact D-Bus: org.freedesktop.DBus.Error.Spawn.ExecFailed: /usr/bin/dbus-launch terminated abnormally with the following error: No protocol specified
Apr 16 15:46:19 rpi-r pulseaudio[949]: [pulseaudio] server-lookup.c: Autolaunch error: X11 initialization failed.
Apr 16 15:46:19 rpi-r pulseaudio[949]: [pulseaudio] main.c: Unable to contact D-Bus: org.freedesktop.DBus.Error.Spawn.ExecFailed: /usr/bin/dbus-launch terminated abnormally with the following error: No protocol specified
Apr 16 15:46:19 rpi-r pulseaudio[949]: [pulseaudio] main.c: Autolaunch error: X11 initialization failed.

From what I've uncovered so far, this should be fixed by insuring that this:

load-module module-native-protocol-unix auth-anonymous=1 socket=/tmp/pulseaudio.socket

is in file: /etc/pulse/default.pa

and that this:

default-server = unix:/tmp/pulseaudio.socket

is in file: /etc/pulse/client.conf.

The problem is, these are already in place with the default files. So at the moment, I'm stuck.

It appears that the phatbeat script is only uninstalling and then reinstalling pulseaudio. Since stretch is no longer distributed with pulseaudio installed by default, the net effect of the script is to do a new install of pulseaudio on a newly installed pi. Unfortunately, this disables audio in the desktop environment if accessing via VNC with the newest release (I've confirmed that it works fine if I access via x11 using a local x-server, and I suspect that it would be fine if a monitor/keyboard/mouse are plugged into the pi as well).

Update: I did run through a new install again, and did notice this time around that the phatbeat script does indeed modify the default.pa and client.conf files as I detailed above (I didn't think that the socket modifications were in the default configuration files... mystery solved!).

Is pulseaudio required for the phatbeat? Thanks...

[Gadgetoid]

pulseaudio was required for earlier versions of pHAT BEAT where ALSA alone would end up running the PCM clock without sending any data- causing the speakers to just sit and heat up. We added a hardware system to prevent this on subsequent versions though, so it's very likely you can run without pulse.

[kampff]

pulseaudio was required for earlier versions of pHAT BEAT where ALSA alone would end up running the PCM clock without sending any data- causing the speakers to just sit and heat up. We added a hardware system to prevent this on subsequent versions though, so it's very likely you can run without pulse.

Can I ask what hardware system was added? (and anything else useful you might remember about this problem). We think we are encountering something similar with our custom MAX98357A board.

[Gadgetoid]

We added this on a later revision of pHAT Beat but I can’t remember which one exactly.

We used a transistor/resistor/capacitor setup which charged the cap as the left/right clock line wiggled and pulled the enable for the DAC via the transistor. Something like that, anyway.

The problem was - IIRC - specifically the PCM clock running without the LRClock. I’m not sure if there’s a more correct way to work around this.