Omarchy on the Pixel 8 Pro: the speakers work

My Pixel 8 Pro (husky, Tensor G3) runs Omarchy Mobile from slot B, with GrapheneOS on slot A as the way back. Last time I had Wi-Fi, the GPU, 120 Hz and better charging, and I wrote that sound wasn't there yet. Now it is: on the evening of 5 November I heard a 1 kHz test tone come out of the top speaker, and later that evening YouTube played in Chromium through the bottom loudspeaker.

It's all on a test kernel on my phone, not in a release. Here's what it took and what's still missing.

Why sound was hard on this phone

On the Pixel 8 Pro the speakers don't hang off the main CPU directly. The audio goes through Google's audio DSP, the AoC, and from there to two Cirrus Logic amplifiers, one for the top speaker and one for the bottom. So before any sound, that whole chain had to run on our kernel. The Pixel 7 Pro port had already done this for its older chip, and its notes were the map I followed.

Three things got in the way:

• The System MMU reset. The AoC sits behind its own memory unit, and on this chip it needed a reset that the older code didn't do. Without it the DSP never came up properly.
• The amplifiers' chip select. Both amps share one SPI bus. The SPI driver was also driving the controller's own chip-select line for devices that use a GPIO for it, so the two amps talked over each other and only one answered. With that fixed, both probed.
• The right route. I first tried the low-latency playback path, and it hung the DSP every time. The speaker plays from the deep-buffer path (EP6), the same as on the 7 Pro. With that and a clock fix for the amps, the first tone played.

After that came PipeWire. The DSP throws away whatever is written before playback starts, and PipeWire fills the buffer first, so it saw a stuck position and stopped. Two small driver changes fixed that, and Chromium played sound. That was the moment I wrote "I GOT SOUND!!!!" in my notes.

Both speakers, at safe levels

Both the top speaker (the earpiece) and the bottom loudspeaker play music, and the sound stack now starts by itself about 2 seconds after boot.

YouTube in Chromium on the phone this morning, sound on (the speaker icon on the tab), with Bluetooth and Wi-Fi on in the bar.

On levels, I'll be honest: while testing on the 5th I pushed the bottom speaker to the 7 Pro's loudest stage for a few seconds of tone at a time, and played YouTube and music for a good while above the safe stage, on both speakers. Derek's worry was exactly that, so on the 6th I capped everything at the 7 Pro's media stage, the safe one, until the 8 Pro has its own measured limits. The amps' protection firmware is loaded, but I haven't calibrated them or read their voltage and current while playing, so for now nothing goes above that stage.

The heat

With sound working I played a lot of YouTube, and the phone got too hot to hold. There's no hardware video decoder yet, so Chromium decodes on the CPU, and the CPU doesn't go into deep idle. I set thermal limits so it throttles earlier, and a small Chromium extension asks YouTube for H.264 instead of VP9 and AV1, which should be lighter on the CPU. I haven't measured that yet, and it still decodes in software.

The bigger problem is at idle: with the screen off and the cable out, the phone drew about 520 mA when I measured it. A healthy phone is around 30 to 60 mA. I measured it with the sound stack off too, and that changes nothing. As far as I can tell, power domains and deep CPU idle aren't managed yet on this chip, so what the bootloader turned on stays on. Which block draws the current, I haven't shown. My first try at deeper CPU idle, together with a power-domain test, made the phone reset itself about a minute after every boot. I don't know yet which of the two did it, and I got it back over fastboot. This one is open, and it's the thing I want fixed before anyone uses this phone daily.

The volume key stutter

Holding volume up or down made video and audio stutter. The volume key repeats 40 times a second, and each repeat starts a script that runs pactl several times. On a throttled phone that's enough to starve the video. Dropping the key repeat to 8 a second, and loosening my thermal caps a little, fixed it, and holding the key now changes the volume smoothly.

Holding the volume key this morning: the slider moves, the video keeps playing.

Bluetooth, haptics and the torch

These worked earlier in the week on separate test kernels: I paired headphones and played YouTube over Bluetooth, felt the vibration motor buzz, and saw the rear LED light up. The cleaned-up versions for review are in #199 (Bluetooth) and #200 (haptics and the torch). On the combined kernel with both, I've only checked that they probe and come up. I haven't tested them beyond that yet.

What I sent upstream

• #449: the 8 Pro's modem and NV partitions in the backup tool, so they're saved before anything risky.
• #450: the full notes of the audio bring-up, step by step with dates, for whoever picks this up next.
• #199 and #200: Bluetooth, haptics and the torch, reworked after Derek's review.

All four are open. The sound changes themselves are still on my test branch and need cleaning into proper PRs.

What doesn't work yet

• The modem. Same as on the Pixel 7 Pro, no calls or mobile data.
• Hardware video decoding in Chromium.
• Idle power, about 520 mA with the screen off.
• Microphones, USB headsets and Bluetooth calls, not tried yet. Music over Bluetooth worked on an earlier kernel.
• Suspend: the phone went into deep sleep once and never woke up, so I leave it off until there's a safe way to wake it.

Thanks

To Derek Ross (@derekross) for Omarchy Mobile and for keeping me careful with the speakers, to Brett-Michael Green (@greenbrettmichael) for the kernel work this all runs on, to @W4HO-ham for the Pixel 9a Bluetooth work mine followed, and to Alejandro García León (@nesmeck) for the battery and USB rescue work. The Omarchy Mobile page keeps the current state.