Skip to content
Snippets Groups Projects

linux-postmarketos-xiaomi-beryllium: microphone doesn't work

    • Closed Issue created by Piotr Kubaj @pkubaj

    Describe your issue

    What's the expected behaviour?

    Being able to use microphone.

    What's the current behaviour?

    Microphone doesn't work

    How to reproduce your issue?

    Try to use microphone, e.g. in a phone call, Phosh sound settings application or a website-based microphone test.

    What device are you using?

    xiaomi-beryllium

    On what postmarketOS version did you encounter the issue?

    • edge (master branch)

    • v24.06

    • I confirm that the issue still is present after running sudo apk upgrade -a

    On what environment did you encounter the issue?

    Environments

    • GNOME Shell on Mobile
    • Phosh
    • Plasma Mobile
    • Sxmo (Wayland/Sway) Please post the output of sxmo_version.sh
    • Other: Please fill out

    How did you get postmarketOS image?

    What's the build date of the image? (in yyyy-mm-dd format)

    Don't remember, I first built 24.01, where things worked fine, then upgraded to 24.06 and just recently upgraded via postmarketos-release-upgrade to edge.

    Additional information

    4 of 11 checklist items completed · Edited
    To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information

    Child items 0

    • No child items are currently assigned. Use child items to break down this issue into smaller parts.

    Activity

    • Piotr Kubaj
      Piotr Kubaj @pkubaj ·
      Author

      dmesg.log

    • Piotr Kubaj changed title from linux-postmarketos-xiaomi-beryllium to linux-postmarketos-xiaomi-beryllium: microphone doesn't work

      changed title from linux-postmarketos-xiaomi-beryllium to linux-postmarketos-xiaomi-beryllium: microphone doesn't work

    • Piotr Kubaj changed the description

      changed the description

    • Robert Eckelmann added audio device-xiaomi-beryllium ui-phosh labels

      added audio device-xiaomi-beryllium ui-phosh labels

    • Frank Oltmanns
      Frank Oltmanns @fraolt ·
      Contributor

      @pkubaj , can you please test if switching to a HiFi profile (e.g. in pavucontrol) during the call fixes the issue. (It does for me, I'm on sxmo, though)

    • Frank Oltmanns
      Frank Oltmanns @fraolt ·
      Contributor

      Looking at the alsa ucm2 configuration files there is a commit efc909bb ("Add q6voice routes in HiFi conf too") by @joelselvaraj .

      Therefore, I ran a diff between beryllium's Hifi.conf and VoiceCall.conf, and apparently the differences between the two are, that

      1. they use different names for the device names in the two profiles,
      2. the HiFi profile has a "Headphones" device,
      3. the HiFi profile has a "Headset" device, and
      4. the VoiceCall's DisableSequence deactivates QUAT_MI2S_RX Voice Mixer VoiceMMode1 and VoiceMMode1 Capture Mixer SLIMBUS_0_TX whereas the HiFi DisableSequencedoes not.

      Unfortunately, in my limited understanding, these differences should not (edit: I was missing the "not" here in my original answer :face_palm: ) matter in our case because:

      1. names shouldn't matter and the new names were introduced for a good and well documented reason by @f-izzo .
      2. my test was without headphones attached
      3. my test was without a headset attached
      4. shouldn't matter, because in both QUAT_MI2S_RX Voice Mixer VoiceMMode1 and VoiceMMode1 Capture Mixer SLIMBUS_0_TX are enabled again in the EnableSequenceof both profiles.

      Obviously, I'm wrong, because the mic works in one profile and not in the other, but currently I don't know where I went wrong.

      Edited by Frank Oltmanns
      • Frank Oltmanns
        Frank Oltmanns @fraolt ·
        Contributor

        This is a log when in a call. The log was created using logread -b 0 -F (on sxmo). The first part is when the call started and callaudiod switched to the voice call profile:

        [Nov 25 08:49:12] authpriv : frank ran command tee -a /sys/power/wake_lock as root from /home/frank 
[Nov 25 08:49:12] authpriv : frank ran command tee -a /sys/power/wake_unlock as root from /home/frank 
[Nov 25 08:49:12] kern kernel: tas2559 5-004c: tas2559_hw_params
[Nov 25 08:49:12] kern kernel: tas2559 5-004c: tas2559_set_sampling_rate: nSamplingRate = 48000 [Hz]
[Nov 25 08:49:12] kern kernel: tas2559 5-004c: Sampling rate for current configuration matches: 48000
[Nov 25 08:49:12] kern kernel: tas2559 5-004c: tas2559_mute
[Nov 25 08:49:12] kern kernel: tas2559 5-004c: tas2559_enable: On
[Nov 25 08:49:12] kern kernel: tas2559 5-004c: tas2559_DevStartup, chl=3
[Nov 25 08:49:12] kern kernel: tas2559 5-004c: TAS2559 load data: Snapshot 5, Blocks = 4, Block Type = 14
[Nov 25 08:49:12] kern kernel: tas2559 5-004c: tas2559_load_block: Type = 14, commands = 93
[Nov 25 08:49:12] kern kernel: tas2559 5-004c: tas2559_DevMute, dev=3, mute=0
[Nov 25 08:49:12] kern kernel: tas2559 5-004c: tas2559_enable: exit
[Nov 25 08:49:12] kern kernel: tas2559 5-004c: tas2559_configuration_get = 4
[Nov 25 08:49:12] kern kernel: tas2559 5-004c: tas2559_configuration_put = 3
[Nov 25 08:49:12] kern kernel: tas2559 5-004c: tas2559_set_config, load new conf configuration_Tuning Mode_48 KHz_s4_3
[Nov 25 08:49:12] kern kernel: tas2559 5-004c: tas2559_load_configuration: 3
[Nov 25 08:49:12] kern kernel: tas2559 5-004c: tas2559_load_configuration, device power on, load new conf[3] configuration_Tuning Mode_48 KHz_s4_3
[Nov 25 08:49:12] kern kernel: tas2559 5-004c: tas2559_load_coefficient, Prev=4, new=3, Pow=1
[Nov 25 08:49:12] kern kernel: tas2559 5-004c: tas2559_DevShutdown, dev=3
[Nov 25 08:49:12] kern kernel: tas2559 5-004c: load PLL: pll block for Configuration configuration_Tuning Mode_48 KHz_s4_3
[Nov 25 08:49:12] kern kernel: tas2559 5-004c: tas2559_load_block: Type = 0, commands = 15
[Nov 25 08:49:12] kern kernel: tas2559 5-004c: load configuration configuration_Tuning Mode_48 KHz_s4_3 conefficient pre block
[Nov 25 08:49:12] kern kernel: tas2559 5-004c: TAS2559 load data: handset, Blocks = 2, Block Type = 4
[Nov 25 08:49:12] kern kernel: tas2559 5-004c: tas2559_load_block: Type = 4, commands = 16
[Nov 25 08:49:12] kern kernel: tas2559 5-004c: load new configuration: configuration_Tuning Mode_48 KHz_s4_3, coeff block data
[Nov 25 08:49:12] kern kernel: tas2559 5-004c: TAS2559 load data: handset, Blocks = 2, Block Type = 3
[Nov 25 08:49:12] kern kernel: tas2559 5-004c: tas2559_load_block: Type = 3, commands = 1049
[Nov 25 08:49:13] kern kernel: tas2559 5-004c: tas2559_DevStartup, chl=1
[Nov 25 08:49:13] kern kernel: tas2559 5-004c: device powered up, load unmute
[Nov 25 08:49:13] kern kernel: tas2559 5-004c: tas2559_DevMute, dev=1, mute=0
[Nov 25 08:49:13] kern kernel: tas2559 5-004c: tas2559_ldac_gain_get, ret = 0, 15
[Nov 25 08:49:13] kern kernel: tas2559 5-004c: tas2559_set_DAC_gain, nGain: 7
[Nov 25 08:49:13] kern kernel: tas2559 5-004c: tas2559_configuration_get = 3
[Nov 25 08:49:13] kern kernel: tas2559 5-004c: tas2559_configuration_get = 3
[Nov 25 08:49:13] kern kernel: wcd934x-codec wcd934x-codec.1.auto: wcd934x_hph_impedance_get: zl=0(ohms), zr=0(ohms)
[Nov 25 08:49:13] kern kernel: wcd934x-codec wcd934x-codec.1.auto: wcd934x_hph_impedance_get: zl=0(ohms), zr=0(ohms)
[Nov 25 08:49:13] kern kernel: wcd934x-codec wcd934x-codec.1.auto: wcd934x_hph_impedance_get: zl=0(ohms), zr=0(ohms)
[Nov 25 08:49:13] kern kernel: wcd934x-codec wcd934x-codec.1.auto: wcd934x_hph_impedance_get: zl=0(ohms), zr=0(ohms)
[Nov 25 08:49:13] kern kernel: tas2559 5-004c: tas2559_ldac_gain_get, ret = 0, 7
[Nov 25 08:49:13] kern kernel: tas2559 5-004c: tas2559_rdac_gain_get, ret = 0, 15
[Nov 25 08:49:14] daemon [2304]: <msg> [modem0/call0] user request to start call 
[Nov 25 08:49:14] daemon [2304]: <msg> [modem0/call0] call state changed: unknown -> dialing (outgoing-started) 
[Nov 25 08:49:14] daemon [2304]: <msg> [modem0/call0] call is started 
[Nov 25 08:49:14] authpriv : frank ran command tee -a /sys/power/wake_lock as root from /home/frank 
[Nov 25 08:49:14] authpriv : frank ran command tee -a /sys/power/wake_unlock as root from /home/frank 
[Nov 25 08:49:14] authpriv : frank ran command tee -a /sys/power/wake_lock as root from /home/frank 
[Nov 25 08:49:15] daemon [2304]: <msg> [modem0] 3GPP packet service state changed (attached -> detached) 
[Nov 25 08:49:20] daemon [2304]: <msg> [modem0/call0] call state changed: dialing -> ringing-out (unknown) 
[Nov 25 08:49:20] authpriv : frank ran command tee -a /sys/power/wake_lock as root from /home/frank 
[Nov 25 08:49:20] authpriv : frank ran command tee -a /sys/power/wake_unlock as root from /home/frank 
[Nov 25 08:49:20] daemon [2304]: <msg> [modem0/call0] call state changed: ringing-out -> active (unknown) 
[Nov 25 08:49:20] authpriv : frank ran command tee -a /sys/power/wake_lock as root from /home/frank 
[Nov 25 08:49:20] authpriv : frank ran command tee -a /sys/power/wake_unlock as root from /home/frank 
[Nov 25 08:49:24] daemon NetworkManager[1979]: <warn>  [1732520964.1203] platform-linux: do-change-link[5]: failure 22 (Invalid argument), setting MTU to requested size is not possible 
[Nov 25 08:49:24] daemon NetworkManager[1979]: <warn>  [1732520964.1205] device (qrtr0): mtu: failure to set MTU. Did you configure the MTU correctly? 
[Nov 25 08:49:54] daemon NetworkManager[1979]: <warn>  [1732520994.1195] platform-linux: do-change-link[5]: failure 22 (Invalid argument), setting MTU to requested size is not possible 
[Nov 25 08:49:54] daemon NetworkManager[1979]: <warn>  [1732520994.1197] device (qrtr0): mtu: failure to set MTU. Did you configure the MTU correctly?

        During this time, the other party could not here me (I was calling an echo service that just mirrors back, when I speak).

        Here I switched to the HiFi with Earpiece profile in pavucontrol and now the other party can here me:

        [Nov 25 08:49:55] kern kernel: q6asm-dai remoteproc-adsp:glink-edge:apr:service@7:dais: command[0x10bdb] not expecting rsp
[Nov 25 08:49:55] kern kernel: tas2559 5-004c: tas2559_mute
[Nov 25 08:49:55] kern kernel: tas2559 5-004c: tas2559_enable: Off
[Nov 25 08:49:55] kern kernel: tas2559 5-004c: tas2559_DevShutdown, dev=1
[Nov 25 08:49:55] kern kernel: tas2559 5-004c: tas2559_enable: exit
[Nov 25 08:49:56] kern kernel: tas2559 5-004c: tas2559_hw_params
[Nov 25 08:49:56] kern kernel: tas2559 5-004c: tas2559_set_sampling_rate: nSamplingRate = 48000 [Hz]
[Nov 25 08:49:56] kern kernel: tas2559 5-004c: Sampling rate for current configuration matches: 48000
[Nov 25 08:49:56] kern kernel: tas2559 5-004c: tas2559_mute
[Nov 25 08:49:56] kern kernel: tas2559 5-004c: tas2559_enable: On
[Nov 25 08:49:56] kern kernel: tas2559 5-004c: tas2559_DevStartup, chl=1
[Nov 25 08:49:56] kern kernel: tas2559 5-004c: tas2559_DevMute, dev=1, mute=0
[Nov 25 08:49:56] kern kernel: tas2559 5-004c: tas2559_enable: exit
[Nov 25 08:49:56] kern kernel: tas2559 5-004c: tas2559_configuration_get = 3
[Nov 25 08:49:56] kern kernel: tas2559 5-004c: tas2559_configuration_get = 3
[Nov 25 08:49:56] kern kernel: wcd934x-codec wcd934x-codec.1.auto: wcd934x_hph_impedance_get: zl=0(ohms), zr=0(ohms)
[Nov 25 08:49:56] kern kernel: wcd934x-codec wcd934x-codec.1.auto: wcd934x_hph_impedance_get: zl=0(ohms), zr=0(ohms)
[Nov 25 08:49:56] kern kernel: wcd934x-codec wcd934x-codec.1.auto: wcd934x_hph_impedance_get: zl=0(ohms), zr=0(ohms)
[Nov 25 08:49:56] kern kernel: wcd934x-codec wcd934x-codec.1.auto: wcd934x_hph_impedance_get: zl=0(ohms), zr=0(ohms)
[Nov 25 08:49:56] kern kernel: tas2559 5-004c: tas2559_ldac_gain_get, ret = 0, 7
[Nov 25 08:49:56] kern kernel: tas2559 5-004c: tas2559_rdac_gain_get, ret = 0, 15
[Nov 25 08:49:56] kern kernel: tas2559 5-004c: tas2559_configuration_get = 3
[Nov 25 08:49:56] kern kernel: tas2559 5-004c: tas2559_configuration_put = 3
[Nov 25 08:49:56] kern kernel: tas2559 5-004c: tas2559_set_config, load new conf configuration_Tuning Mode_48 KHz_s4_3
[Nov 25 08:49:56] kern kernel: tas2559 5-004c: tas2559_load_configuration: 3
[Nov 25 08:49:56] kern kernel: tas2559 5-004c: Configuration 3 is already loaded
[Nov 25 08:49:56] kern kernel: tas2559 5-004c: tas2559_ldac_gain_get, ret = 0, 7
[Nov 25 08:49:56] kern kernel: tas2559 5-004c: tas2559_set_DAC_gain, nGain: 7
[Nov 25 08:49:56] kern kernel: tas2559 5-004c: tas2559_configuration_get = 3
[Nov 25 08:49:56] kern kernel: tas2559 5-004c: tas2559_configuration_get = 3
[Nov 25 08:49:56] kern kernel: wcd934x-codec wcd934x-codec.1.auto: wcd934x_hph_impedance_get: zl=0(ohms), zr=0(ohms)
[Nov 25 08:49:56] kern kernel: wcd934x-codec wcd934x-codec.1.auto: wcd934x_hph_impedance_get: zl=0(ohms), zr=0(ohms)
[Nov 25 08:49:56] kern kernel: wcd934x-codec wcd934x-codec.1.auto: wcd934x_hph_impedance_get: zl=0(ohms), zr=0(ohms)
[Nov 25 08:49:56] kern kernel: wcd934x-codec wcd934x-codec.1.auto: wcd934x_hph_impedance_get: zl=0(ohms), zr=0(ohms)
[Nov 25 08:49:56] kern kernel: tas2559 5-004c: tas2559_ldac_gain_get, ret = 0, 7
[Nov 25 08:49:56] kern kernel: tas2559 5-004c: tas2559_rdac_gain_get, ret = 0, 15
[Nov 25 08:49:56] kern kernel: tas2559 5-004c: tas2559_configuration_get = 3
[Nov 25 08:49:56] kern kernel: tas2559 5-004c: tas2559_configuration_get = 3
[Nov 25 08:49:56] kern kernel: wcd934x-codec wcd934x-codec.1.auto: wcd934x_hph_impedance_get: zl=0(ohms), zr=0(ohms)
[Nov 25 08:49:56] kern kernel: wcd934x-codec wcd934x-codec.1.auto: wcd934x_hph_impedance_get: zl=0(ohms), zr=0(ohms)
[Nov 25 08:49:56] kern kernel: wcd934x-codec wcd934x-codec.1.auto: wcd934x_hph_impedance_get: zl=0(ohms), zr=0(ohms)
[Nov 25 08:49:56] kern kernel: wcd934x-codec wcd934x-codec.1.auto: wcd934x_hph_impedance_get: zl=0(ohms), zr=0(ohms)
[Nov 25 08:49:56] kern kernel: tas2559 5-004c: tas2559_ldac_gain_get, ret = 0, 7
[Nov 25 08:49:56] kern kernel: tas2559 5-004c: tas2559_rdac_gain_get, ret = 0, 15
[Nov 25 08:50:00] authpriv : frank ran command tee -a /sys/power/wake_lock as root from /home/frank 
[Nov 25 08:50:00] authpriv : frank ran command tee -a /sys/power/wake_lock as root from /home/frank 
[Nov 25 08:50:00] authpriv : frank ran command tee -a /sys/power/wake_unlock as root from /home/frank 
[Nov 25 08:50:00] authpriv : frank ran command tee -a /sys/power/wake_unlock as root from /home/frank

        Finally, I hung up:

        [Nov 25 08:50:10] daemon [2304]: <msg> [modem0/call0] user request to hangup call 
[Nov 25 08:50:10] daemon [2304]: <msg> [modem0/call0] call state changed: active -> terminated (terminated) 
[Nov 25 08:50:10] authpriv : frank ran command tee -a /sys/power/wake_lock as root from /home/frank 
[Nov 25 08:50:11] authpriv : frank ran command tee -a /sys/power/wake_unlock as root from /home/frank 
[Nov 25 08:50:11] daemon [2304]: <msg> [modem0] 3GPP packet service state changed (detached -> attached) 
[Nov 25 08:50:11] authpriv : frank ran command tee -a /sys/power/wake_unlock as root from /home/frank 
[Nov 25 08:50:12] daemon [2304]: <msg> [modem0] 3GPP packet service state changed (attached -> detached) 
[Nov 25 08:50:12] daemon [2304]: <msg> [modem0] 3GPP packet service state changed (detached -> attached)
      • Frank Oltmanns
        Frank Oltmanns @fraolt ·
        Contributor

        Note that also q6voiced logs no errors. It happily prints PCM devices were opened. when the call starts and PCM devices were closed. when the call ends.

      • Frank Oltmanns
        Frank Oltmanns @fraolt ·
        Contributor

        I suspected a timing issue, so I converted q6voiced into a cli program, so that I could try opening the stream once I was sure that switching to the call profile was complete.

        Again, no improvement. Even when opening the PCM device when I'm sure that the VoiceCall profile is active, I need to switch to the HiFi profile so that the other party can hear me.

      • Please register or sign in to reply
      • Frank Oltmanns
        Frank Oltmanns @fraolt ·
        Contributor

        One further observation (not a solution). I replaced VoiceCall.conf with the HiFi.conf like this:

        $ cd /usr/share/alsa/ucm2/Xiaomi/beryllium/
$ doas mv VoiceCall.conf VoiceCall.conf.bak
$ doas ln -s HiFi.conf VoiceCall.conf

        Being on pulseaudio, I can then use any of the four profiles available in pavucontrol for calls.

        Note that this starts calls in speaker mode, so priorities need to be changed in order to start in earpiece mode.

      • Frank Oltmanns
        Frank Oltmanns @fraolt ·
        Contributor

        Ok, so instead of linking I copied HiFi.conf to VoiceCall.conf and the slowly changed things back. The culprit is the "Headphones" section. As soon as I remove it, the mic stops working.

        @pkubaj Could you please try out the attached config, if it works for you, too? VoiceCall.conf

        Make a backup of your original file and then copy the attached version to /usr/share/alsa/ucm2/Xiaomi/beryllium/ on your Poco F1.

        After rebooting the phone it should work.

      • Joel Selvaraj
        Joel Selvaraj @joelselvaraj ·
        Reporter

        This is interesting and weird at the same time. Thanks for looking into it. I wonder why leaving the headphones in voicecall breaks phone mic from working. If you can consistently reproduce and fix the bug, kindly open a pull request to https://gitlab.com/sdm845-mainline/alsa-ucm-conf with the updated VoiceCall.conf for beryllium.

      • Frank Oltmanns
        Frank Oltmanns @fraolt ·
        Contributor

        Thank you for your response and especially for your work on sdm845! It seems to me that the actual culprit is a remap section in beryllium.conf.

        From 718d8d1b291486c1cdb26402cb5ef59abed0ddc8 Mon Sep 17 00:00:00 2001
From: Frank Oltmanns <frank@oltmanns.dev>
Date: Tue, 26 Nov 2024 06:38:41 +0100
Subject: [PATCH] beryllium: Remove control merge

The merge/remapping of RX1 and RX2 Digital Volume into HP Digital Volume
breaks VoiceCall.conf; apparently because there is no Headphone section
present. This merge has also already been removed from fajita and
enchilada.

Fixes: https://gitlab.postmarketos.org/postmarketOS/pmaports/-/issues/3322
---
 ucm2/Xiaomi/beryllium/beryllium.conf | 11 -----------
 1 file changed, 11 deletions(-)

diff --git a/ucm2/Xiaomi/beryllium/beryllium.conf b/ucm2/Xiaomi/beryllium/beryllium.conf
index 6914fc7..b4ba620 100644
--- a/ucm2/Xiaomi/beryllium/beryllium.conf
+++ b/ucm2/Xiaomi/beryllium/beryllium.conf
@@ -26,14 +26,3 @@ BootSequence [
 	cset "name='ADC3 Volume' 16"
 	cset "name='DEC7 Volume' 80"
 ]
-
-LibraryConfig.remap.Config {
-
-	ctl.default.map {
-		# Merge two mono controls into one stereo
-		"name='HP Digital Volume'" {
-			"name='RX1 Digital Volume'".vindex.0 0
-			"name='RX2 Digital Volume'".vindex.1 0
-		}
-	}
-}
-- 
2.47.0

        I'll submit a merge request.

      • Frank Oltmanns
        Frank Oltmanns @fraolt ·
        Contributor

        https://gitlab.com/sdm845-mainline/alsa-ucm-conf/-/merge_requests/25

      • Please register or sign in to reply
    • Frank Oltmanns mentioned in commit fraolt/pmaports@bd47e1eb

      mentioned in commit fraolt/pmaports@bd47e1eb

    • Frank Oltmanns mentioned in merge request !5860 (merged)

      mentioned in merge request !5860 (merged)

      • Frank Oltmanns
        Frank Oltmanns @fraolt ·
        Contributor

        Okay, so I did some further digging in this branch and it seems like VoiceCall.conf needs a section with a PlaybackPCM for "hw:${CardId},1".

        So, basically the following patch fixes the bottom mic (but we have an ugly "Dummy" playback device).

        diff --git a/ucm2/Xiaomi/beryllium/VoiceCall.conf b/ucm2/Xiaomi/beryllium/VoiceCall.conf
index 089fe25..fc0b8c3 100644
--- a/ucm2/Xiaomi/beryllium/VoiceCall.conf
+++ b/ucm2/Xiaomi/beryllium/VoiceCall.conf
@@ -81,6 +81,14 @@ SectionDevice."Earpiece" {
        }
 }
 
+SectionDevice."Dummy" {
+       Comment "Dummy"
+
+       Value {
+               PlaybackPCM "hw:${CardId},1"
+       }
+}
+
 SectionDevice."Mic" {
        Comment "Phone Bottom Mic"

        @joelselvaraj, do you have any suggestions how to proceed? Please also note that the two commits from me don't solve anything, so should they be reverted?

        Edited by Frank Oltmanns
      • Joel Selvaraj
        Joel Selvaraj @joelselvaraj ·
        Reporter

        I m against the idea of adding a Dummy device. If the Headphones (with PCM hw:1) need to be present in VoiceCall.conf, I am ok with that. At the worst case, call audio wouldn't work when a headphones is plugged. So why remove Headphones and use a Dummy? Let's just copy Headphones from HiFi into VoiceCall.conf?

        Edited by Joel Selvaraj
      • Frank Oltmanns
        Frank Oltmanns @fraolt ·
        Contributor

        Thank you for your fast response.

        Let me start by saying that I don't have a strong opinion on the naming anymore. I thought that maybe naming it "Headphone" gave the impression to users that, when plugging in headphones, call audio was routed to the headphone. IMO, naming the device "Dummy" does not cause this kind of confusion.

        However, I only received my poco F1 two weeks ago, so I'm only slowly discovering whats working and what is not. I have now for the first time plugged in headphones and a headset and realized that they don't work at all (neither in HiFi nor in VoiceCall).

        In conclusion, naming the device "Headphones" is fine by me. I will copy over the "Headphones" device from HiFi.conf to VoiceCall.conf.

        @f-izzo, I'm not sure, if I then also need to rename the "Headphones" device in HiFi.conf to "Headphones1" (in the spirit of what you did in commit aaa7889f7a6de640b4d78300e118457335ad16c0 ("Fix assert in PulseAudio 17.0 caused by same device name in multiple ucm configs")). I did not see any assertion error messages in the pulseaudio logs when having a "Headphones" section in both files. But then again, I also did not see any error messages when renaming "Mic1" to "Mic" to force the issue you were mentioning in the commit. So I might be looking at the wrong log files. I appreciate any help you can give.

      • Please register or sign in to reply
    • Frank Oltmanns
      Frank Oltmanns @fraolt ·
      Contributor

      Regarding 718d8d1b291486c1cdb26402cb5ef59abed0ddc8 ("beryllium: Remove control merge") and ee78a03529555b750020123fa32c510d629957c6 ("beryllium: Remove mixer element HP Digital"): It seems to me we should probably keep those.

      These patches get rid of a warning in pulseaudio regarding the HP Digital mixer. This was not the intention of the patches, but it's a nice side-effect. :smile:

    • Frank Oltmanns mentioned in commit fraolt/pmaports@4ba80448

      mentioned in commit fraolt/pmaports@4ba80448

    • Frank Oltmanns mentioned in commit fraolt/pmaports@0996b840

      mentioned in commit fraolt/pmaports@0996b840

    • Oliver Smith mentioned in commit fraolt/pmaports@8d49f878

      mentioned in commit fraolt/pmaports@8d49f878

    • Oliver Smith closed with merge request !5860 (merged)

      closed with merge request !5860 (merged)

    • Oliver Smith mentioned in commit c0c821a4

      mentioned in commit c0c821a4

    • Loading
    • Loading
    • Loading
    • Loading
    • Loading
    • Loading
    • Loading
    • Loading
    • Loading
    • Loading
    Please register or sign in to reply