[PATCH] ASoC: simple-card: Fill in driver name
alsa-ucm groups by driver name so fill that in as well. Otherwise the presented information is redundant and doesn't reflect the used driver. We can't just use 'asoc-simple-card' since the driver name is restricted to 15 characters.
Before:
# cat /proc/asound/cards 0 [Devkit ]: Librem_5_Devkit - Librem 5 Devkit Librem 5 Devkit After:
0 [Devkit ]: simple-card - Librem 5 Devkit Librem 5 Devkit
Signed-off-by: Guido Günther agx@sigxcpu.org --- This came out of a discussion about adding alsa-ucm profiles for the Librem 5 Devkit at https://github.com/alsa-project/alsa-ucm-conf/pull/102
sound/soc/generic/simple-card.c | 1 + 1 file changed, 1 insertion(+)
diff --git a/sound/soc/generic/simple-card.c b/sound/soc/generic/simple-card.c index 0015f534d42d..a3a7990b5cb6 100644 --- a/sound/soc/generic/simple-card.c +++ b/sound/soc/generic/simple-card.c @@ -621,6 +621,7 @@ static int asoc_simple_probe(struct platform_device *pdev) card->owner = THIS_MODULE; card->dev = dev; card->probe = simple_soc_probe; + card->driver_name = "simple-card";
li = devm_kzalloc(dev, sizeof(*li), GFP_KERNEL); if (!li)
On Tue, 22 Jun 2021 10:27:09 +0200, Guido Günther wrote:
alsa-ucm groups by driver name so fill that in as well. Otherwise the presented information is redundant and doesn't reflect the used driver. We can't just use 'asoc-simple-card' since the driver name is restricted to 15 characters.
Before:
[...]
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next
Thanks!
[1/1] ASoC: simple-card: Fill in driver name commit: 907f0a3051869a61499905377212500155bd28ec
All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying to this mail.
Thanks, Mark
On Tuesday, 22 June 2021 10:27:09 CEST Guido Günther wrote:
alsa-ucm groups by driver name so fill that in as well. Otherwise the presented information is redundant and doesn't reflect the used driver. We can't just use 'asoc-simple-card' since the driver name is restricted to 15 characters.
Before:
# cat /proc/asound/cards 0 [Devkit ]: Librem_5_Devkit - Librem 5 Devkit Librem 5 Devkit After:
0 [Devkit ]: simple-card - Librem 5 Devkit Librem 5 Devkit
Signed-off-by: Guido Günther agx@sigxcpu.org
This came out of a discussion about adding alsa-ucm profiles for the Librem 5 Devkit at https://github.com/alsa-project/alsa-ucm-conf/pull/102
sound/soc/generic/simple-card.c | 1 + 1 file changed, 1 insertion(+)
diff --git a/sound/soc/generic/simple-card.c b/sound/soc/generic/simple-card.c index 0015f534d42d..a3a7990b5cb6 100644 --- a/sound/soc/generic/simple-card.c +++ b/sound/soc/generic/simple-card.c @@ -621,6 +621,7 @@ static int asoc_simple_probe(struct platform_device *pdev) card->owner = THIS_MODULE; card->dev = dev; card->probe = simple_soc_probe;
card->driver_name = "simple-card";
li = devm_kzalloc(dev, sizeof(*li), GFP_KERNEL); if (!li)
Unfortunately this change broke multichannel audio on my Rock64 device running Debian. My Rock64 is connected to my AVR (Pioneer SC-1224) via a HDMI cable.
Before/without this change, pulseaudio correctly identifies my AVR and gives me hdmi-stereo/hdmi-surround/hdmi-surround71 output profiles via the HDMI card and iec958-stereo/iec958-ac3-surround-51 on my SPDIF card. After/with this change, I only have a stereo-fallback output profile on both HDMI and SPDIF card. I reported this to Debian at https://bugs.debian.org/995923 I have verified that reverting this commit on a self-built 5.14.10 brought back multichannel audio.
On LibreELEC's current nightly builds (version 11) with kernel 5.14 on a(nother) Rock64 device (also connected via HDMI cable), I hear no sound at all. Previous nightly builds (version 11) with I _assume_ kernel < 5.14, worked fine. As I didn't keep previous nightly builds, I can't verify that. I reported that at https://github.com/LibreELEC/LibreELEC.tv/issues/5734 I have NOT verified whether reverting this commit would also restore audio with LibreELEC as I'm not familiar with their build system.
This is the first time I'm reporting an issue to the upstream Linux kernel, so I hope I did it correctly (DL-ed mbox file and did Reply-to-All). If not, apologies and I hope you'll point me to the correct place/way. (I don't know if others need to be notified too as it is part of 5.14 releases)
Cheers, Diederik
On 10. 10. 21 9:47, Diederik de Haas wrote:
On Tuesday, 22 June 2021 10:27:09 CEST Guido Günther wrote:
alsa-ucm groups by driver name so fill that in as well. Otherwise the presented information is redundant and doesn't reflect the used driver. We can't just use 'asoc-simple-card' since the driver name is restricted to 15 characters.
Before:
# cat /proc/asound/cards 0 [Devkit ]: Librem_5_Devkit - Librem 5 Devkit Librem 5 Devkit After:
0 [Devkit ]: simple-card - Librem 5 Devkit Librem 5 Devkit
Signed-off-by: Guido Günther agx@sigxcpu.org
This came out of a discussion about adding alsa-ucm profiles for the Librem 5 Devkit at https://github.com/alsa-project/alsa-ucm-conf/pull/102
sound/soc/generic/simple-card.c | 1 + 1 file changed, 1 insertion(+)
diff --git a/sound/soc/generic/simple-card.c b/sound/soc/generic/simple-card.c index 0015f534d42d..a3a7990b5cb6 100644 --- a/sound/soc/generic/simple-card.c +++ b/sound/soc/generic/simple-card.c @@ -621,6 +621,7 @@ static int asoc_simple_probe(struct platform_device *pdev) card->owner = THIS_MODULE; card->dev = dev; card->probe = simple_soc_probe;
card->driver_name = "simple-card";
li = devm_kzalloc(dev, sizeof(*li), GFP_KERNEL); if (!li)
Unfortunately this change broke multichannel audio on my Rock64 device running Debian. My Rock64 is connected to my AVR (Pioneer SC-1224) via a HDMI cable.
This looks like an user space configuration problem. You should check, if a PA profile or an UCM configuration is used (in the PA debug log).
Jaroslav
On Sunday, 10 October 2021 10:40:09 CEST Jaroslav Kysela wrote:
Unfortunately this change broke multichannel audio on my Rock64 device running Debian. My Rock64 is connected to my AVR (Pioneer SC-1224) via a HDMI cable.
This looks like an user space configuration problem.
I have placed ALSA card definitions (I think) from LibreELEC on my system from https://github.com/LibreELEC/LibreELEC.tv/tree/master/projects/Rockchip/ filesystem/usr/share/alsa/cards
I have just prepended "LE-" and appended ".bak" to those files and rebooted and that resulted in only "output:stereo-fallback" profiles. Just like in what I considered 'failures' that I tracked down to this commit.
So it appears that LE's card definitions *gave* me multichannel output, whereas I wouldn't have had it otherwise. It also explains why the sound issue occurs with LE too.
Note that I took/used LE's work as 'inspiration' to improve things on Debian. Their work seems very good to me and one of their card definitions was also referenced from (kernel) commit 25572fb5aa986bdbb35d06c0fb52a9b9d9b3b2c9 titled "arm64: dts: rockchip: enable HDMI sound nodes for rk3328-rock64"
if a PA profile or an UCM configuration is used (in the PA debug log).
While I don't consider myself clueless wrt Linux (running Sid for 10+ years), I am clueless wrt how ALSA/PA/audio-in-general works (on Linux). When I do 'journalctl -b -u pulseaudio --since="2021-10-10 12:00:00"' I get a lot of output and also several 'errors', but I have no clue how to interpret that. I also get that when AFAIC (from a user standpoint) everything 'works'. So I'd need some help with that.
I could attach output of (several runs of) "journalctl" and f.e. the output of 'alsa-info', but I haven't yet as it may not be appropriate and may also no longer be considered a kernel problem (and the 'To:' list is (far) larger then I'm used to). So I'd need some guidance with that too.
Regards, Diederik
Hi, On Sun, Oct 10, 2021 at 12:40:00PM +0200, Diederik de Haas wrote:
On Sunday, 10 October 2021 10:40:09 CEST Jaroslav Kysela wrote:
Unfortunately this change broke multichannel audio on my Rock64 device running Debian. My Rock64 is connected to my AVR (Pioneer SC-1224) via a HDMI cable.
This looks like an user space configuration problem.
I have placed ALSA card definitions (I think) from LibreELEC on my system from https://github.com/LibreELEC/LibreELEC.tv/tree/master/projects/Rockchip/ filesystem/usr/share/alsa/cards
You likely have the paths wrong, see how `simple-card` ends up in the config file path:
https://github.com/alsa-project/alsa-ucm-conf/pull/102/files
Cheers, -- Guido
On 10. 10. 21 12:40, Diederik de Haas wrote:
On Sunday, 10 October 2021 10:40:09 CEST Jaroslav Kysela wrote:
Unfortunately this change broke multichannel audio on my Rock64 device running Debian. My Rock64 is connected to my AVR (Pioneer SC-1224) via a HDMI cable.
This looks like an user space configuration problem.
I have placed ALSA card definitions (I think) from LibreELEC on my system from https://github.com/LibreELEC/LibreELEC.tv/tree/master/projects/Rockchip/ filesystem/usr/share/alsa/cards
Apparently, the alsa-lib configuration is used in this case.
It seems that there are four sound cards (Analog/HDMI/I2S/SPDIF) created for your hardware. The alsa-lib configuration is a bit weird - an obfuscation for the simple-card driver use. The simple way to resolve this is to create a proper UCM configuration.
If you need further assistance, create an issue for alsa-lib or alsa-ucm-conf on github and with an output from the 'alsa-info.sh' script.
Jaroslav
On 2021-10-11 19:16, Jaroslav Kysela wrote:
On 10. 10. 21 12:40, Diederik de Haas wrote:
On Sunday, 10 October 2021 10:40:09 CEST Jaroslav Kysela wrote:
Unfortunately this change broke multichannel audio on my Rock64 device running Debian. My Rock64 is connected to my AVR (Pioneer SC-1224) via a HDMI cable.
This looks like an user space configuration problem.
I have placed ALSA card definitions (I think) from LibreELEC on my system from https://github.com/LibreELEC/LibreELEC.tv/tree/master/projects/Rockchip/ filesystem/usr/share/alsa/cards
Apparently, the alsa-lib configuration is used in this case.
It seems that there are four sound cards (Analog/HDMI/I2S/SPDIF) created for your hardware. The alsa-lib configuration is a bit weird - an obfuscation for the simple-card driver use. The simple way to resolve this is to create a proper UCM configuration.
If you need further assistance, create an issue for alsa-lib or alsa-ucm-conf on github and with an output from the 'alsa-info.sh' script.
Will do.
FTR: It's now working again for me on a kernel with this patch included: https://github.com/LibreELEC/LibreELEC.tv/issues/5734#issuecomment-940088156
I have no idea whether this is a proper solution or another 'workaround', but it's working for me again :)
Thanks for your help.
Diederik
On 11. 10. 21 23:48, didi.debian@cknow.org wrote:
On 2021-10-11 19:16, Jaroslav Kysela wrote:
On 10. 10. 21 12:40, Diederik de Haas wrote:
On Sunday, 10 October 2021 10:40:09 CEST Jaroslav Kysela wrote:
Unfortunately this change broke multichannel audio on my Rock64 device running Debian. My Rock64 is connected to my AVR (Pioneer SC-1224) via a HDMI cable.
This looks like an user space configuration problem.
I have placed ALSA card definitions (I think) from LibreELEC on my system from https://github.com/LibreELEC/LibreELEC.tv/tree/master/projects/Rockchip/ filesystem/usr/share/alsa/cards
Apparently, the alsa-lib configuration is used in this case.
It seems that there are four sound cards (Analog/HDMI/I2S/SPDIF) created for your hardware. The alsa-lib configuration is a bit weird - an obfuscation for the simple-card driver use. The simple way to resolve this is to create a proper UCM configuration.
If you need further assistance, create an issue for alsa-lib or alsa-ucm-conf on github and with an output from the 'alsa-info.sh' script.
Will do.
FTR: It's now working again for me on a kernel with this patch included: https://github.com/LibreELEC/LibreELEC.tv/issues/5734#issuecomment-940088156
I have no idea whether this is a proper solution or another 'workaround', but it's working for me again :)
The patch bellow resolved your issue - alsa-lib configuration fix. But it's not an universal solution and there may be clashes with other simple-card drivers in future.
https://github.com/LibreELEC/LibreELEC.tv/pull/5749/commits/f681a48a664bd0f0...
Jaroslav
participants (4)
-
didi.debian＠cknow.org -
Diederik de Haas
-
Guido Günther -
Jaroslav Kysela -
Mark Brown