ARM Unstable - No sound with Pinephone after Update

Does anyone else have no audio on the original pinephone after updating today? or was just me?

It depends what you updated and which branch. In Daily builds we have:

one of the sections I see in the upstream config is this, which was not present in the Mobian ones:

SectionDefaults [
	# Switch playback off.
	cset "name='Earpiece Playback Switch' off"
	cset "name='Headphone Playback Switch' off"
	cset "name='Line In Playback Switch' off"
	cset "name='Line Out Playback Switch' off"
	cset "name='Mic1 Playback Switch' off"
	cset "name='Mic2 Playback Switch' off"

	# Switch capture off.
	cset "name='Line In Capture Switch' off"
	cset "name='Mic1 Capture Switch' off"
	cset "name='Mic2 Capture Switch' off"
	cset "name='Mixer Capture Switch' off"
	cset "name='Mixer Reversed Capture Switch' off"

Oh wait, I just noticed that I’m on arm-unstable branch… I don’t even remember when I switched… probably trying to check the CPUidle thingy but that isn’t even on he 6.1 kernel so I guess that is a Fail on my side.

I have an somewhat old Phosh image from last year that I have been updating using pamac weekly, so maybe I’m missing something on the config.

@philm, would the config you shared be relevant to Phosh arm-unstable?

Huh? Looks like very broken defaults. Can we get this changed?

maybe i misunderstood you, but cpuidle should be working on this release with the 6.1 kernel.

@varikonniemi you are right it is using psci_idle as cpuidle driver. I mean to say that by the time I switched to arm-unstable it was broken, so I switched branches to enabled it but it wasn’t present on the unstable branch either at that time. Anyways, I will switch back to stable and test the audio.

Trying to downgrade from arm-unstable to arm-stable end up breaking quite a lot of dependencies so I kept arm-unstable branch.

@philm I can confirm those settings caused the audio to stop working on the original pinephone and the issue got fixed after removing them from /usr/share/alsa/ucm2/conf.d/simple-card/PinePhone.conf .

Well FOSS development is a beautiful thing. More or less it was in work in progress since a year. When merged upstream projects like PMOS noticed some is broken. Seems a version during development was tested but never the final thing with current environment. This results then in funny comments and broken systems to end users.

Also a fun fact is which kernel is used: Megi, Mobian, Pine64, Mainline. If you use Pipewire or PulseAudio, even pure Alsa.

As I see it, upstream Alsa developers suggested a lot of things they know might work and the documentation was more or less applied.

For me it seems it was never really tested. Also you see a history in 3 branches.

So someone has to follow the bread crumms once again and redo the history and verify every setting change and why it was made. Some say it is now to loud, others have no audio at all. For me it is kinda a mess and the typical many cooks might waste the food thing …

brings us to a very important point: why on earth after all this time has not pinephone migrated to a pure Linux kernel? One would think the most used and successful Linux phone would have the manpower to upstream the needed patches to allow it to use mainline kernel, but it seems nothing is enough.

Well you have too many distributions using several versions of the kernel with different patches. So there is:

  • pine64 kernel which mostly has activity for PinePhonePro
  • the more or less reference kernel by Megi, which is more or less the defacto standard, which ships some patches which can’t get upstreamed as they don’t follow upstream code guidelines. Megi has no time to upstream things but you can always feel free to do that when keeping his credit
  • then there is the Mobian kernel, which partly ships with some of the Megi patch-set. However it is not complete and might have some issues.

Then there are too many distros for the phone:

Distro Kernel
Manjaro Megi
Arch Megi
Fedora Megi
Mobian Own
Gentoo Megi
KaliLinux Mobian
NemoMobile (Manjaro) Megi
NixOS Megi
Slackware Own
UbPorts Pine64

So there you have it why it is not upstreamed. All kernels ship with downstream patch-sets on top of the mainline kernel. So if Pine64 claims the PinePhone is supported by Mainline kernel, well not fully. So how to get it upstreamed? Well. Pine64 could pay Linaro to do it. The community did a great job so far but the interest shift to the PinePhonePro already …

More Info about Mainline Kernel for PinePhonePro: Anjan's Homepage -by now PMOS uses Megi for PPP too :small_airplane: Here some outdated stats: See how many additional patches the Mobian Kernel ships on 6.1 series: debian/patches · mobian-6.1 · Mobian Team / devices / kernels / sunxi64-linux · GitLab

Just out of curiosity, do you happen to know how much do they charge for the upstream service? I mean, the pinephone is an awesome tool specially for crazy devs like me that do virtualization and a of lot of thin client stuff.

If it weren’t because of my lack of time, I would gladly do it myself :stuck_out_tongue:

Hard to guess. I assume between 200.000 $ and 300.000 $ for a period of 4 - 6 months …

That’s the order of magnitude to expect indeed (skilled manpower is expensive!), so I would not expect an individual to be able to field this.

Don’t know why that should help, but someone suggested to delete those files to get audio back. However the left channel might be way too loud: ~/.config/pulse and ~/.local/state/wireplumber Also it depends if you use pipewire or pulseaudio.

For now I decided to readd the last working config files into alsa-ucm-pinephone package and added an alpm hook which makes sure to restore the symlink to the working configs on updates of the file. Let me know if that works for you guys. When there is a proper solution I’ll remove that of course.

Fair enough, it also make me reevaluate how much I charge to do my job but yeah, I’m aware it would be expensive, I was curious tho :stuck_out_tongue:

Anyways, thanks for the info @philm ! :smiley:

Sure, that works for me. I already modified the config files myself, also updated a while ago and the audio is working without issues so far.