OG PinePhone microphone failed but recovered after booting to SD then eMMC
DESCRIPTION:
The microphone on a Mobian/trixie OG PP eMMC system failed to record any sound, even after a few reboots and an apt upgrade and reboot. Opening up the PP including unscrewing the mid-cover and resealing, and rebooting, did not recover the microphone. After that, rebooting into an older Mobian/trixie SD card system did recover the microphone. After that, rebooting to the eMMC system gave normal microphone usage. What action caused the microphone recovery?
CONTEXT:
I initially found this bug because I believed that I had my PP audio phone call issues completely solved (see my list of PP bugs and workarounds), but a series of phone calls had ineffective conversation. I eventually did some testing and discovered that outgoing audio failed in the calls, as in earlier bugs. Finally, I found that the microphone (in most, but not all, trials) failed to record audio, independently of the gnome-calls/callaudio system.
SYSTEM:
- PinePhone v1.2b Mobian/trixie
- modem: FLOSS firmware 0.7.2
- modem: ADSP 30.006.30.006
- uptime before the reboots mentioned in this report was about 26 days
Original eMMC system, during which the microphone failed:
pipewire 0.3.85-1I did sudo aptitude update && sudo aptitude safe-upgrade which updated 418 packages, giving me my current eMMC system, again with many microphone fails, and every now and then a success followed by more failures:
$ uname -a
Linux mobian 6.1-sunxi64 #1 SMP Tue Dec 12 18:38:04 UTC 2023 aarch64 GNU/Linux
$ dpkg -l |grep -Ei "alsa|pipewire|wireplumber|callaudio|linux-image"
ii alsa-ucm-conf 1.2.10-1mobian1 all ALSA Use Case Manager configuration files
ii alsa-utils 1.2.10-1 arm64 Utilities for configuring and using ALSA
ii callaudiod 0.1.9-1-VOLTAGE-multi arm64 Call audio routing daemon
ii gstreamer1.0-pipewire:arm64 1.0.0-1 arm64 GStreamer 1.0 plugin for the PipeWire multimedia server
ii libasound2:arm64 1.2.10-3 arm64 shared library for ALSA applications
ii libasound2-data 1.2.10-3 all Configuration files and profiles for ALSA drivers
ii libasound2-dev:arm64 1.2.10-3 arm64 shared library for ALSA applications -- development files
ii libasound2-plugins:arm64 1.2.7.1-1+b1 arm64 ALSA library additional plugins
ii libatopology2:arm64 1.2.10-3 arm64 shared library for handling ALSA topology definitions
ii libcallaudio-0-1:arm64 0.1.9-1-VOLTAGE-multi arm64 Library for audio routing during voice calls
ii libcallaudio-dev:arm64 0.1.9-1-VOLTAGE-multi arm64 Development files for libcallaudio
ii libcallaudio-tools 0.1.9-1-VOLTAGE-multi arm64 Helper tools for libcallaudio
ii libpipewire-0.3-0:arm64 1.0.0-1 arm64 libraries for the PipeWire multimedia server
ii libpipewire-0.3-modules:arm64 1.0.0-1 arm64 libraries for the PipeWire multimedia server - modules
ii libspa-0.2-bluetooth:arm64 1.0.0-1 arm64 libraries for the PipeWire multimedia server - bluetooth plugins
ii libspa-0.2-jack:arm64 1.0.0-1 arm64 libraries for the PipeWire multimedia server - JACK client
ii libspa-0.2-libcamera:arm64 1.0.0-1 arm64 libraries for the PipeWire multimedia server - libcamera plugin
ii libspa-0.2-modules:arm64 1.0.0-1 arm64 libraries for the PipeWire multimedia server Simple Plugin API - modules
ii libwireplumber-0.4-0:arm64 0.4.17-1 arm64 Shared libraries for WirePlumber
ii linux-image-5.10-sunxi64 5.10.56+sunxi64-9 arm64 Linux 5.10 for Allwinner A64 devices
ii linux-image-6.1-sunxi64 6.1.67+sunxi64-1 arm64 Linux 6.1 for sunxi64 devices
ii pipewire:arm64 1.0.0-1 arm64 audio and video processing engine multimedia server
ii pipewire-alsa:arm64 1.0.0-1 arm64 PipeWire ALSA plugin
ii pipewire-audio 1.0.0-1 all recommended set of PipeWire packages for a standard audio desktop use
ii pipewire-audio-client-libraries 1.0.0-1 all transitional package for pipewire-alsa and pipewire-jack
ii pipewire-bin 1.0.0-1 arm64 PipeWire multimedia server - programs
ii pipewire-jack:arm64 1.0.0-1 arm64 PipeWire JACK plugin
ii pipewire-pulse 1.0.0-1 arm64 PipeWire PulseAudio daemon
ii wireplumber 0.4.17-1 arm64 modular session / policy manager for PipeWire- The
0.1.9-1-VOLTAGE-multiversion ofcallaudiodis a minor hack that does extra outputs for printing battery voltages tojournalctlfiles. -
alsa-ucm-confis modified by using this VoiceCall.conf that forces a complete set of viable ALSA parameters during earpiece/microphone voice calls.
microSD system:
$ uname -a
Linux mobian 6.1-sunxi64 #1 SMP Fri Oct 13 12:38:23 UTC 2023 aarch64 GNU/Linux
$ dpkg -l |grep -Ei "alsa|pipewire|wireplumber|callaudio|linux-image"
ii alsa-ucm-conf 1.2.10-1mobian1 all ALSA Use Case Manager configuration files
ii alsa-utils 1.2.10-1 arm64 Utilities for configuring and using ALSA
ii callaudiod 0.1.9-1 arm64 Call audio routing daemon
ii gstreamer1.0-pipewire:arm64 0.3.84-1 arm64 GStreamer 1.0 plugin for the PipeWire multimedia server
ii libasound2:arm64 1.2.10-1 arm64 shared library for ALSA applications
ii libasound2-data 1.2.10-1 all Configuration files and profiles for ALSA drivers
ii libasound2-plugins:arm64 1.2.7.1-1+b1 arm64 ALSA library additional plugins
ii libatopology2:arm64 1.2.10-1 arm64 shared library for handling ALSA topology definitions
ii libcallaudio-0-1:arm64 0.1.9-1 arm64 Library for audio routing during voice calls
ii libpipewire-0.3-0:arm64 0.3.84-1 arm64 libraries for the PipeWire multimedia server
ii libpipewire-0.3-modules:arm64 0.3.84-1 arm64 libraries for the PipeWire multimedia server - modules
ii libspa-0.2-bluetooth:arm64 0.3.84-1 arm64 libraries for the PipeWire multimedia server - bluetooth plugins
ii libspa-0.2-libcamera:arm64 0.3.84-1 arm64 libraries for the PipeWire multimedia server - libcamera plugin
ii libspa-0.2-modules:arm64 0.3.84-1 arm64 libraries for the PipeWire multimedia server Simple Plugin API - modules
ii libwireplumber-0.4-0:arm64 0.4.15-1 arm64 Shared libraries for WirePlumber
ii linux-image-6.1-sunxi64 6.1.57+sunxi64-1 arm64 Linux 6.1 for sunxi64 devices
ii pipewire:arm64 0.3.84-1 arm64 audio and video processing engine multimedia server
ii pipewire-alsa:arm64 0.3.84-1 arm64 PipeWire ALSA plugin
ii pipewire-audio 0.3.84-1 all recommended set of PipeWire packages for a standard audio desktop use
ii pipewire-bin 0.3.84-1 arm64 PipeWire multimedia server - programs
ii pipewire-libcamera 0.3.84-1 all transitional package for libspa-0.2-libcamera
ii pipewire-pulse 0.3.84-1 arm64 PipeWire PulseAudio daemon
ii wireplumber 0.4.15-1 arm64 modular session / policy manager for PipeWireANALYSIS:
Example of the microphone failing to record:
$ arecord -f U8 -c1 -r8000 file.wav # gives a file mostly filled with the hex value 80; playing the file on a desktop machine gives no sound
$ sudo alsactl store -f - |grep -nE -A2 "Mic1" && amixer
144: name 'Mic1 Playback Volume'
145- value 5
146- comment {
--
158: name 'Mic1 Boost Volume'
159- value 0
160- comment {
--
524: name 'Mic1 Playback Switch'
525- value.0 true
526- value.1 true
--
579: name 'Mic1 Capture Switch'
580- value.0 true
581- value.1 true
Simple mixer control 'Master',0
Capabilities: pvolume pswitch pswitch-joined
Playback channels: Front Left - Front Right
Limits: Playback 0 - 65536
Mono:
Front Left: Playback 32768 [50%] [on]
Front Right: Playback 32768 [50%] [on]
Simple mixer control 'Capture',0
Capabilities: cvolume cswitch cswitch-joined
Capture channels: Front Left - Front Right
Limits: Capture 0 - 65536
Front Left: Capture 55706 [85%] [on]
Front Right: Capture 55706 [85%] [on]A simple test for microphone effectiveness is to do
arecord -vv -f dat /dev/nullI did this on the eMMC system with the microphone not working; the output was:
ALSA <-> PipeWire PCM I/O Plugin
Its setup is:
stream : CAPTURE
access : RW_INTERLEAVED
format : S16_LE
subformat : STD
channels : 2
rate : 48000
exact rate : 48000 (48000/1)
msbits : 16
buffer_size : 24000
period_size : 6000
period_time : 125000
tstamp_mode : NONE
tstamp_type : MONOTONIC
period_step : 1
avail_min : 6000
period_event : 0
start_threshold : 1
stop_threshold : 24000
silence_threshold: 0
silence_size : 0
boundary : 67XXXXXXXXXXXXXXX00
Recording WAVE '/dev/null' : Signed 16 bit Little Endian, Rate 48000 Hz, Stereo
###############################+ | 61%where tapping or making other sounds had no effect on the length of the horizontal # bar or the 61% next to it. Trying to vary any of the alsamixer parameters related to the microphone did not make the bar respond to noises. Changing the vertical bar in the master 'capture' window of alsamixer had an effect in changing bar length and the number, but even at 100%, there was no reaction to sounds made near the microphone.
WHAT RESTORED THE MICROPHONE:
- open up back cover
- fully unscrew middle cover
- slightly lift up the green circuitboard at the bottom
- have a look
- fully reseal the whole PP
- boot to eMMC again
- try the
arecordtest; this again gave microphone failure - sleep (human sleep)
- reboot to the SD card
- the
arecordtest passes - reboot SDcard a few times (there were some warnings about the system being slow and some inode failures; this gave me a reboot as the only reasonable action)
- reboot to the eMMC
- the
arecordtest for the microphone now works - Audio calls work normally.
ANALYSIS OF SNAPSHOTS:
During phone calls when the microphone failed versus calls when the microphone was working, I took snapshots of many parameters. This shows some comparisons:
- exzPJU = microphone failed
- zOs7LW = microphone OK
Compare output of sudo alsa store -f - > ...
--- 20231222/tmp.ezxPJU.alsa_store.full 2023-12-23 19:49:55.000000000 +0100
+++ 20231224/OK/tmp.zOs7LW.alsa_store.full 2023-12-24 16:24:13.000000000 +0100
@@ -240,7 +240,7 @@
control.18 {
iface MIXER
name 'Earpiece Playback Volume'
- value 21
+ value 19
comment {
access 'read write'
type INTEGERInterpretation: insignificant difference.
Compare
gdbus introspect --session --recurse --object-path /org/mobian_project/CallAudio --dest org.mobian_project.CallAudio > ${TMPBASE}.callaudio$ md5sum 20231222/tmp.ezxPJU.callaudio 20231224/OK/tmp.zOs7LW.callaudio
37759442ff2520bd06ba344a2bf98469 20231222/tmp.ezxPJU.callaudio
37759442ff2520bd06ba344a2bf98469 20231224/OK/tmp.zOs7LW.callaudio tail 20231222/tmp.ezxPJU.callaudio
out b success);
MuteMic(in b mute,
out b success);
signals:
properties:
readonly u AudioMode = 1;
readonly u SpeakerState = 0;
readonly u MicState = 1;
};
};Interpretation: absolutely no difference and the settings are as expected.
Compare the output of
amixer > ${TMPBASE}.amixer.key.params
amixer -c 0 sget 'Mic1' >> ${TMPBASE}.amixer.key.params
amixer -c 0 sget 'Line Out' >> ${TMPBASE}.amixer.key.params
amixer -c 0 sget 'DAC' >> ${TMPBASE}.amixer.key.params--- 20231222/tmp.ezxPJU.amixer.key.params 2023-12-23 19:49:55.000000000 +0100
+++ 20231224/OK/tmp.zOs7LW.amixer.key.params 2023-12-24 16:24:13.000000000 +0100
@@ -3,14 +3,14 @@
Playback channels: Front Left - Front Right
Limits: Playback 0 - 65536
Mono:
- Front Left: Playback 36498 [56%] [on]
- Front Right: Playback 36498 [56%] [on]
+ Front Left: Playback 32768 [50%] [on]
+ Front Right: Playback 32768 [50%] [on]
Simple mixer control 'Capture',0
Capabilities: cvolume cswitch cswitch-joined
Capture channels: Front Left - Front Right
Limits: Capture 0 - 65536
- Front Left: Capture 55706 [85%] [on]
- Front Right: Capture 55706 [85%] [on]
+ Front Left: Capture 55760 [85%] [on]
+ Front Right: Capture 55760 [85%] [on]
Simple mixer control 'Mic1',0
Capabilities: pvolume pvolume-joined pswitch cswitch
Playback channels: Front Left - Front RightInterpretation: negligible difference.
Wireplumber:
wpctl status | sed -e 's/\(pid\|cookie\):[0-9]*/\1:XXXX/' > ...--- 20231222/tmp.ezxPJU.wpctl.status.clean 2023-12-25 14:29:23.615040532 +0100
+++ 20231224/OK/tmp.zOs7LW.wpctl.status.clean 2023-12-25 14:29:55.550974792 +0100
@@ -4,26 +4,27 @@
34. WirePlumber [1.0.0, mobian@mobian, pid:XXXX]
35. WirePlumber [export] [1.0.0, mobian@mobian, pid:XXXX]
56. CallAudio [1.0.0, mobian@mobian, pid:XXXX]
- 57. chatty [1.0.0, mobian@mobian, pid:XXXX]
- 58. gsd-power [1.0.0, mobian@mobian, pid:XXXX]
+ 57. Phone Shell Volume Control [1.0.0, mobian@mobian, pid:XXXX]
+ 58. GNOME Volume Control Media Keys [1.0.0, mobian@mobian, pid:XXXX]
59. xdg-desktop-portal [1.0.0, mobian@mobian, pid:XXXX]
- 60. wpctl [1.0.0, mobian@mobian, pid:XXXX]
- 61. GNOME Volume Control Media Keys [1.0.0, mobian@mobian, pid:XXXX]
- 62. Phone Shell Volume Control [1.0.0, mobian@mobian, pid:XXXX]
- 63. Chats [1.0.0, mobian@mobian, pid:XXXX]
- 64. feedbackd [1.0.0, mobian@mobian, pid:XXXX]
+ 60. xdg-desktop-portal-wlr [1.0.0, mobian@mobian, pid:XXXX]
+ 61. chatty [1.0.0, mobian@mobian, pid:XXXX]
+ 62. Chats [1.0.0, mobian@mobian, pid:XXXX]
+ 63. feedbackd [1.0.0, mobian@mobian, pid:XXXX]
+ 64. gsd-power [1.0.0, mobian@mobian, pid:XXXX]
+ 65. wpctl [1.0.0, mobian@mobian, pid:XXXX]
Audio
├─ Devices:
│ 46. Built-in Audio [alsa]
│
├─ Sinks:
- │ * 50. Built-in Audio Headphones + Internal Earpiece + Internal speaker [vol: 0.56]
+ │ * 54. Built-in Audio Headphones + Internal Earpiece + Internal speaker [vol: 0.50]
│
├─ Sink endpoints:
│
├─ Sources:
- │ * 33. Built-in Audio Headset Microphone + Internal Microphone [vol: 0.85]
+ │ * 55. Built-in Audio Headset Microphone + Internal Microphone [vol: 0.85]
│
├─ Source endpoints:
│Identical parts at the end:
Settings
└─ Default Configured Node Names:
0. Audio/Sink alsa_output.platform-sound.Voice_Call__hw_PinePhone_0__sink
1. Audio/Source alsa_input.platform-sound.Voice_Call__hw_PinePhone_0__sourceInterpretation:
- Could the different ordering of the processes prevent the microphone working?
-
xdg-desktop-portal-wlris present in the mic working case and absent in the mic non-working case - is this relevant?
DISCUSSION:
Discussion on #pinephone:matrix.org suggested that I should record this even though it seems like an irreproducible bug. I have only vague speculations as to which package or system or configuration is responsible, although it clearly happened on a Mobian/trixie system. I'm posting this here so that it's searchable in case others have similar experiences.
(Just to be clear: this is not a bug in pinephone-support itself.)
SPECULATION:
- Was running for 26 days without a reboot a cause of the bug, e.g. a
dbusproblem? - Since the
arecordtest first output line isALSA <-> PipeWire PCM I/O Plugin,pipewirerelated packages could be suspected.- Was the order of launching processes – see the
wpctl statuscomparison above – incorrect? -
Since(Update: see below -xdg-desktop-portal-wlris present in the mic working case forwpctl statusand absent in the mic non-working case, could this be the explanation?xdg-desktop-portal-wlrwas also present inwpctl statusoutput in the following iteration of the bug when the mic was not working.)
- Was the order of launching processes – see the
Edited by Boud Roukema