On 3 Oct 2021, at 9:13 am, Geraldo Nascimento [off-list ref] wrote:

On Sun, Oct 03, 2021 at 01:43:12AM +0200, Martin Blumenstingl wrote:

quoted

Hello Jerome et al.,

on Amlogic Meson SoCs which use the AIU audio controller we have the
so-called "machine gun noise" (MGN) issue, reproducible for example in
Kodi. So far nobody was able to identify the cause of this issue. My
idea was to at least narrow down the issue so we can categorize it. For
that I wanted to get the SPDIF output from AIU to the HDMI controller
working.

Hi, Martin,

The MGN issue surely must be that one when using ALSA directly
(no dmix, no JACK, no Pulseaudio, no Pipewire, no nothing) and
when the track changes or we pause it, when it resumes we get 
noise instead of sound, correct?

If so, thanks for trying to track this down!

I bring it up because Googling it seems to head straight to a
Neil Armstrong post to linux-amlogic about what works and what
doesn't on linux-meson currently, and only if you dig deeper
you find a couple of reports apparently by the same person
about the "machine gun noise" thing.

It doesn't sound like a machine gun noise to me :)

More like brown noise, but anyway what I'd like to note to
everyone involved is that this one is a major dealbreaker.
Unless using JACK, Pulseaudio, Pipewire (?) or at least dmix
audio will degrade at the second song or when the user first
pauses and then resumes a stream, completely ruining the
experience.

I’m the origin of most reports that Google will eventually discover. I was told elsewhere that this is known as MGN so I’ve described it as such, but that could be wrong. For clarity this is the noise (triggered, and with AVR volume deliberately right down) followed by some navigation in the Kodi GUI to change output:

https://chewitt.libreelec.tv/testing/wp2_audio_noise.mov

In the LibreELEC images I work on where this occurs it’s not something I associate with play/pause (although I can’t definitively rule it out) or second or third songs (not something that happens that often or predictably) but more when there’s a hard transition like starting or stopping playback. I hit it most with simple scrolling around in the Kodi GUI, although that could be because (due to this issue) I limit media playback testing on AIU devices. It’s particularly simple to trigger from the Kodi Settings > System > Audio page, just scroll around it for 10-30 seconds, which is handy because the only way to stop the noise is switching audio source (from anything to anything) on the same page.

CH.

quoted

On Amlogic Meson GXBB/GXL/GXM SoCs a DesignWare HDMI TX controller is
used. This has an SPDIF input but there's currently not driver for it.
On Meson8/8b/8m2 SoCs I am working on a HDMI driver for the TransSwitch
HDMI controller which - just like DesignWare HDMI TX - supports SPDIF
and I2S inputs.
I decided to add SPDIF support to the latter since the code from the
vendor driver is much easier.

It took me a while to figure out why I would not get any audio output
from AIU SPDIF to the HDMI controller - or from there to the sink.
The "fix" for this issue is the RFC patch which is part of this series.
Any feedback would be great as I am still new to the ASoC subsystem.

Another part I am still struggling with is the audio "routing" (due to
lack of a better term - please correct me if this is not the right word
to use for this case). I have the following description in my .dts:
	sound {
		compatible = "amlogic,gx-sound-card";
		model = "M8B-ODROID-C1";

		assigned-clocks = <&clkc CLKID_MPLL0>,
				  <&clkc CLKID_MPLL1>;
		assigned-clock-rates = <294912000>,
				       <270950400>;
		dai-link-0 {
			sound-dai = <&aiu AIU_CPU CPU_I2S_FIFO>;
		};

		dai-link-1 {
			sound-dai = <&aiu AIU_CPU CPU_SPDIF_FIFO>;
		};

		dai-link-2 {
			sound-dai = <&aiu AIU_CPU CPU_I2S_ENCODER>;
			dai-format = "i2s";
			mclk-fs = <256>;

			codec-0 {
				sound-dai = <&aiu AIU_HDMI CTRL_I2S>;
			};
		};

		dai-link-3 {
			sound-dai = <&aiu AIU_CPU CPU_SPDIF_ENCODER>;

			codec-0 {
				sound-dai = <&aiu AIU_HDMI CTRL_PCM>;
			};
		};

		dai-link-4 {
			sound-dai = <&aiu AIU_HDMI CTRL_OUT>;

			codec-0 {
				sound-dai = <&hdmi_tx>;
			};
		};
	};
The driver for &hdmi_tx defines:
	struct hdmi_codec_pdata pdata = {
		.ops			= &txc_48352_hdmi_codec_ops,
		.i2s			= 1,
		.spdif			= 1,
		.max_i2s_channels	= 8,
		.data			= priv,
	};
In hdmi_codec_ops.hw_params I always get fmt->fmt HDMI_I2S unless I
remove all I2S references from the .dts snipped above (only then
HDMI_SPDIF is detected). Based on the selection of the "HDMI Source"
enum in aiu-codec-ctrl I was expecting the format to update as well.
That unfortunately doesn't happen and I don't know how that can be
achieved.

Hm, that sounds weird. I hope you get the answers you are looking for.

Thanks,
Geraldo Nascimento

quoted

Best regards,
Martin


Martin Blumenstingl (1):
 ASoC: meson: aiu: Fix HDMI codec control selection

sound/soc/meson/aiu-codec-ctrl.c  | 108 ++++++++++++++++++++++--------
sound/soc/meson/aiu-encoder-i2s.c |   6 --
2 files changed, 80 insertions(+), 34 deletions(-)

-- 
2.33.0

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel