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.

Sign up for GitHub

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

Jump to bottom

Broken audio on latest kernel. #171

Closed
nolight132 opened this issue Aug 3, 2023 · 2 comments
Closed

Broken audio on latest kernel. #171

nolight132 opened this issue Aug 3, 2023 · 2 comments

Comments

@nolight132
Copy link

OS: Arch Linux ARM aarch64
Host: Apple MacBook Air (M1, 2020)
Kernel: 6.3.0-asahi-13-1-edge-ARCH

It worked before pacman -Syu on my AirPods Pro.

Here are the logs during boot mentioning audio:
Aug 04 00:19:44 archbook kernel: Secondary: opening PCM device 'Secondary' with no audio route configured (bad settings applied to the sound card) Aug 04 00:19:44 archbook kernel: Secondary: ASoC: error at snd_soc_link_hw_params on Secondary: -22

I hope it helps, but if not than I'm ready to provide more logs, just not sure which are required.
@jannau
Copy link
Member

jannau commented Aug 4, 2023

Those messages have nothing to do with audio over bluetooth. Please describe the error in more detail. Does pairing/connecting the AirPods Pro work? Do you hear noise while playing audio? Do you use a 2.4GHz wlan? Does the noise go away if you disable the wlan?

@nolight132
Copy link
Author

Those messages have nothing to do with audio over bluetooth. Please describe the error in more detail. Does pairing/connecting the AirPods Pro work? Do you hear noise while playing audio? Do you use a 2.4GHz wlan? Does the noise go away if you disable the wlan?

Now that I look at it, it's actually fine with audio-only files, the problem only occurs with video in LibreWolf, the playback just won't start. However, video files in telegram-desktop (.mov) do play but for some reason only through external players, not in the Telegram itself.

Aug 04 12:43:19 archbook mpp[1814]: vcodec_service: open vcodec_service (null) failed
Aug 04 12:43:19 archbook mpp[1814]: hal_h264d_api: mpp_dev_init failed ret: -1

This message is constantly being displayed.

Edit: After realizing the that the problem roots from codecs, I replaced ffmpeg-mmp with ffmpeg and therefore resolved the issue.

jannau pushed a commit that referenced this issue Jul 29, 2024
@TE-N-ShengjiuWang @storulf
pmdomain: imx: gpcv2: Add delay after power up handshake
e8dc41a 
AudioMix BLK-CTRL on i.MX8MP encountered an accessing register issue
after power up.

[    2.181035] Kernel panic - not syncing: Asynchronous SError Interrupt
[    2.181038] CPU: 1 PID: 48 Comm: kworker/u16:2 Not tainted 6.9.0-rc5-next-20240424-00003-g21cec88845c6 #171
[    2.181047] Hardware name: NXP i.MX8MPlus EVK board (DT)
[    2.181050] Workqueue: events_unbound deferred_probe_work_func
[    2.181064] Call trace:
[...]
[    2.181142]  arm64_serror_panic+0x6c/0x78
[    2.181149]  do_serror+0x3c/0x70
[    2.181157]  el1h_64_error_handler+0x30/0x48
[    2.181164]  el1h_64_error+0x64/0x68
[    2.181171]  clk_imx8mp_audiomix_runtime_resume+0x34/0x44
[    2.181183]  __genpd_runtime_resume+0x30/0x80
[    2.181195]  genpd_runtime_resume+0x110/0x244
[    2.181205]  __rpm_callback+0x48/0x1d8
[    2.181213]  rpm_callback+0x68/0x74
[    2.181224]  rpm_resume+0x468/0x6c0
[    2.181234]  __pm_runtime_resume+0x50/0x94
[    2.181243]  pm_runtime_get_suppliers+0x60/0x8c
[    2.181258]  __driver_probe_device+0x48/0x12c
[    2.181268]  driver_probe_device+0xd8/0x15c
[    2.181278]  __device_attach_driver+0xb8/0x134
[    2.181290]  bus_for_each_drv+0x84/0xe0
[    2.181302]  __device_attach+0x9c/0x188
[    2.181312]  device_initial_probe+0x14/0x20
[    2.181323]  bus_probe_device+0xac/0xb0
[    2.181334]  deferred_probe_work_func+0x88/0xc0
[    2.181344]  process_one_work+0x150/0x290
[    2.181357]  worker_thread+0x2f8/0x408
[    2.181370]  kthread+0x110/0x114
[    2.181381]  ret_from_fork+0x10/0x20
[    2.181391] SMP: stopping secondary CPUs

According to comments in power up handshake:

	/* request the ADB400 to power up */
	if (domain->bits.hskreq) {
		regmap_update_bits(domain->regmap, domain->regs->hsk,
				   domain->bits.hskreq, domain->bits.hskreq);

		/*
		 * ret = regmap_read_poll_timeout(domain->regmap, domain->regs->hsk, reg_val,
		 *				  (reg_val & domain->bits.hskack), 0,
		 *				  USEC_PER_MSEC);
		 * Technically we need the commented code to wait handshake. But that needs
		 * the BLK-CTL module BUS clk-en bit being set.
		 *
		 * There is a separate BLK-CTL module and we will have such a driver for it,
		 * that driver will set the BUS clk-en bit and handshake will be triggered
		 * automatically there. Just add a delay and suppose the handshake finish
		 * after that.
		 */
	}

The BLK-CTL module needs to add delay to wait for a handshake request finished.
For some BLK-CTL module (eg. AudioMix on i.MX8MP) doesn't have BUS clk-en
bit, it is better to add delay in this driver, as the BLK-CTL module doesn't
need to care about how it is powered up.

regmap_read_bypassed() is to make sure the above write IO transaction already
reaches target before udelay().

Fixes: 1496dd4 ("clk: imx: imx8mp: Add pm_runtime support for power saving")
Reported-by: Francesco Dolcini <francesco@dolcini.it>
Closes: https://lore.kernel.org/all/66293535.170a0220.21fe.a2e7@mx.google.com/
Suggested-by: Frank Li <frank.li@nxp.com>
Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
Tested-by: Adam Ford <aford173@gmail.com>
Tested-by: Alexander Stein <alexander.stein@ew.tq-group.com>
Link: https://lore.kernel.org/r/1715396125-3724-1-git-send-email-shengjiu.wang@nxp.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@jannau @nolight132