Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

xiaomi-vince: static noise when idle and popping noise when starting/stopping audio (q6asm_dai) #173

Open
spongy-deluxe opened this issue Feb 8, 2024 · 5 comments

Comments

@spongy-deluxe
Copy link

spongy-deluxe commented Feb 8, 2024

Hi,

I am using postmarket OS edge (phosh) with the msm8953-mainline kernel of the linux-6.7.2/main branch.

The issues I am facing are:

  • static noise as soon as I have plugged in and switched to my headphones
    • The noise pattern depends on which parts of the device are powered (WiFi, screen etc.)
    • It seems to be some inductive coupling (or floating OpAmp input)
  • a loud pop sound when I start/stop sound playback (my ears still hurt 😢 )
    • After the pop sound the playback starts/stops perfectly

In some situations after wildly enabling/disabling or plugging/unplugging headphones and starting/stopping playback, the static noise is gone.

I assume the noise stems from some output not being turned off properly. Longnoserob suggested it could be an erroneously configured power-saving feature or option.

After investigating a bit further, I found out that almost always error messages appear in dmesg that look like this:

[70807.344061] q6asm-dai c200000.remoteproc:smd-edge:apr:service@7:dais: command[0x10dac] not expecting rsp
[70807.344107] q6asm-dai c200000.remoteproc:smd-edge:apr:service@7:dais: command[0x10dac] not expecting rsp
[70807.344123] q6asm-dai c200000.remoteproc:smd-edge:apr:service@7:dais: command[0x10dac] not expecting rsp
[70807.344313] q6asm-dai c200000.remoteproc:smd-edge:apr:service@7:dais: command[0x10dac] not expecting rsp
[70812.881674] q6asm-dai c200000.remoteproc:smd-edge:apr:service@7:dais: command[0x10bdb] not expecting rsp
[70843.282577] q6asm-dai c200000.remoteproc:smd-edge:apr:service@7:dais: command[0x10bdb] not expecting rsp
[70896.027385] q6asm-dai c200000.remoteproc:smd-edge:apr:service@7:dais: command[0x10dac] not expecting rsp
[70896.027432] q6asm-dai c200000.remoteproc:smd-edge:apr:service@7:dais: command[0x10dac] not expecting rsp
[70896.027449] q6asm-dai c200000.remoteproc:smd-edge:apr:service@7:dais: command[0x10dac] not expecting rsp
[70896.027464] q6asm-dai c200000.remoteproc:smd-edge:apr:service@7:dais: command[0x10dac] not expecting rsp
[70901.294569] q6asm-dai c200000.remoteproc:smd-edge:apr:service@7:dais: command[0x10bdb] not expecting rsp

Again when pushing buttons randomly, sometimes these messages stop appearing (while the problem persists).

I wondered whether the alsa ucm configuration could be the culprit, but I have just started investigating and the current configuration looked very similar to what xml2ucm produces from an Android mixer_paths.xml file.

Does anyone have an idea what could cause these problems?

Regards,
spongy

EDIT:

There seem to exist specialized audio chips which suppress "clicks and pops".
For example analog devices says the following on their website:

Click-Pop Suppressors
Analog Devices provides integrated audio click-and-pop suppressors for devices, such as codecs that have integrated headphone amplifiers but lack a clickless and/or popless startup or shutdown.

That sounds pretty much like the cure to my problem and the Xiaomi Vince uses a wcd_codec which is compatible to qcom,pm8916-wcd-analog-codec.

The datasheet of the msm-8953 recommends three audio configurations:

  • PM8953 codec
  • PM8953 + WSA8810/WSA8815
  • WCD9326/WCD9335 + WSA8810/WSA8815

The datasheet of the WCD9335 features two protection mechanisms: click-and-pop and overcurrent.
The device tree features interrupts(?) for both protection mechanisms:

  • cdc_hphr_ocp_int: headphone right over-current protection interrupt <0x1 0xf1 0x1 IRQ_TYPE_NONE>
  • cdc_hphl_ocp_det: headphone left over-current protection detection/interrupt <0x1 0xf1 0x2 IRQ_TYPE_NONE>
  • cdc_hphr_cnp_int: headphone right click-and-pop interrupt <0x1 0xf1 0x4 IRQ_TYPE_NONE>
  • cdc_hphl_cnp_int: headphone left click-and-pop interrupt <0x1 0xf1 0x5 IRQ_TYPE_NONE>

So perhaps the click-and-pop protection mechanism is not enabled on my device.


On Xiaomi vince several kernel modules are loaded, so that I believe that the audio chip is controlled via these:

q6asm_dai              24576  1
q6routing             385024  2 q6asm_dai
q6voice_dai            20480  1
q6afe_clocks           12288  1
q6afe_dai              77824  1
q6voice                16384  1 q6voice_dai
q6adm                  16384  1 q6routing
q6asm                  32768  1 q6asm_dai
q6afe                  20480  4 q6voice,q6afe_dai,q6afe_clocks,q6adm
q6cvp                  12288  1 q6voice
q6cvs                  12288  0
q6mvm                  12288  1 q6voice
snd_q6dsp_common       45056  4 q6asm,q6afe_dai,q6afe_clocks,q6adm
q6voice_common         16384  4 q6cvp,q6voice,q6mvm,q6cvs
q6core                 12288  3 q6asm,q6afe,q6adm
apr                    20480  8 q6asm,q6cvp,q6core,q6mvm,q6afe,q6cvs,q6voice_common,q6adm
pdr_interface          24576  1 apr
qrtr_smd               16384  0
venus_dec              32768  0
venus_enc              28672  0
snd_soc_apq8016_sbc    12288  0
snd_soc_qcom_common    12288  1 snd_soc_apq8016_sbc
qrtr                   28672  47 qrtr_smd
qcom_camss            245760  16
snd_soc_msm8916_analog    49152  1

snd_soc_msm8916_analog is the real audio driver which is used for the pm8953 power management chip. This chip also provides the audio dac.


References:

Further references:

@Kiciuk
Copy link

Kiciuk commented Feb 10, 2024

Im somehow aware of weird noises when headphones are plugged in but some noise/cracks when inserting jack itself appears to be quite normal and happens on my pc and other devices.
For vince and analog audio frontend(so everything outside of speaker) it uses PM8953 so WCD9335(standalone codec chip) is not related either WSA is.

@spongy-deluxe
Copy link
Author

spongy-deluxe commented Feb 10, 2024

Yes, the noises when plugging unplugging are most likely just the short-circuited contacts. But this really seems to be related to either power management or a bug.

Thanks for clarifying that only the PM8953 is related to this issue. It is indeed hard for me to understand the architecture and the device tree.

The kernel documentation also has a section about Audio Pops:
https://www.kernel.org/doc/html/latest/sound/soc/pops-clicks.html


After searching for a solution, one workaround did work. Pulseaudio seems to suspend the audio sinks if they are idle.

Comment the line in /etc/pulse/default.pa and /etc/pulse/system.pa:

load-module module-suspend-on-idle 

so that

#load-module module-suspend-on-idle 

Afterwards reload the audio with alsaucm reload && killall -9 pulseaudio.

This prevents pulseaudio from suspending the sink so that it will output silence. This is probably not the perfect solution yet as power-saving might be prevented. This solves only the static noise issue but the pops seem to persist.


Pulseaudio seems to shutdown automatically when a sink is paused for a short time.

I set in /etc/pulse/daemon.conf exit-idle-time = -1 and it prevents the pulseaudio shutdown when idle.

It had no impact on the pop noises when starting/stopping playback.


When I run killall -9 pulseaudio && pulseaudio -vvv the following shows up as soon as I press on the play button in an audio player.

D: [pulseaudio] module-udev-detect.c: /dev/snd/controlC0 is accessible: yes
D: [pulseaudio] module-udev-detect.c: Resuming all sinks and sources of card alsa_card.platform-c051000.sound-card.
D: [pulseaudio] module-udev-detect.c: /dev/snd/controlC0 is accessible: yes
D: [pulseaudio] module-udev-detect.c: Resuming all sinks and sources of card alsa_card.platform-c051000.sound-card.

@barni2000
Copy link
Member

Pop Noise could be caused by volumes i will experimenting with the UCM configs more.

@spongy-deluxe
Copy link
Author

Well I think I have to correct one thing:

Commenting the line in /etc/pulse/default.pa and /etc/pulse/system.pa:

load-module module-suspend-on-idle 

so that

#load-module module-suspend-on-idle 

does have an effect on the pops. At least I could pull out my headphones, plug them in or start a playback without hearing a super loud pop. It seems to be greatly reduced to what I would call normal. (It might just be a feeling but perhaps the power consumption did increase)

@barni2000
Copy link
Member

I have pop noise without ucm also so i thinking about using more simlpe-amplifier and audio widgets.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants