* ucm2: Qualcomm: Radxa Dragon Q6A: keep the headphone route when using HDMI
[not found] <alsa-project/alsa-ucm-conf/pr/906@alsa-project.org>
@ 2026-11-11 11:05 ` GitHub pull_request - opened
0 siblings, 0 replies; only message in thread
From: GitHub pull_request - opened @ 2026-11-11 11:05 UTC (permalink / raw)
To: alsa-devel
alsa-project/alsa-ucm-conf pull request #906 was opened from MarcHT91:
MultiMedia1 (hw:0) feeds the headphones and MultiMedia2 (hw:1) feeds
DisplayPort/HDMI. Each AudioReach back end accepts a single front end, so
connecting MultiMedia2 to RX_CODEC_DMA_RX_0 disconnects MultiMedia1.
The HiFi verb did exactly that ('RX_CODEC_DMA_RX_0 Audio Mixer
MultiMedia2' = 1), and the HDMI device then wrote 0 to the same control,
which on current kernels also clears the back end's link. After
alsaucm -c hw:0 set _verb HiFi set _enadev HDMI
the headphones are disconnected, and a stream started on hw:0 never
advances (hw_ptr stays at 0):
before: RX<-MM1=on RX<-MM2=off DP<-MM2=on
after: RX<-MM1=off RX<-MM2=off DP<-MM2=on
Keep each front end on its own back end: the verb clears the unused
routes and connects MultiMedia1 to the headphones, and the HDMI device
only switches 'DISPLAY_PORT_RX_0 Audio Mixer MultiMedia2'. The zero
writes come before the connections, so the order is also safe on kernels
where writing 0 to a route control drops whatever link the back end has
(fix sent to ASoC: "ASoC: qcom: audioreach: only disconnect the route a
mixer control owns").
Tested on a Radxa Dragon Q6A: verb only, verb + HDMI, verb + Headphones
+ HDMI, HDMI enable/disable: the headphone route stays connected in all
cases.
Fixes: 67628fb4871e ("ucm2: Qualcomm: add Radxa Dragon Q6A")
Request URL : https://github.com/alsa-project/alsa-ucm-conf/pull/906
Patch URL : https://github.com/alsa-project/alsa-ucm-conf/pull/906.patch
Repository URL: https://github.com/alsa-project/alsa-ucm-conf
^ permalink raw reply [flat|nested] only message in thread