AIF2 ADC Stereo Capture Route is uninitialised in alsa-ucm-conf

Question

AIF2 ADC Stereo Capture Route is uninitialised in alsa-ucm-conf

broukema opened this issue a year ago · 8 comments

DESCRIPTION:
AIF2 ADC Stereo Capture Route is not initialised in
alsa-ucm-conf. This implies that if its setting is significant, any
accidental change by the user (using any of the various alsa tools)
to a wrong setting will not be corrected by any of the three
PinePhone/*.conf files, leading, in particular, to audio errors during a phone
call. This was discovered by testing variations on the Mobian version
of the PinePhone alsa-ucm-conf files.

CODING ARGUMENT:
All parameters that can significantly affect the audio system should be
either initialised or overridden in configuration files that the user
expects to necessarily work, such as those for phone calls.
In alsa-ucm-conf commit b68aa52 (one beyond v1.2.10):

$ grep -ri "AIF2 ADC Stereo Capture" .
$

shows that AIF2 ADC Stereo Capture Route is not set for any device at all
(PinePhone or other).

HARDWARE ARGUMENT:
For the PinePhone (PP), Megi recommends in https://xnux.eu/devices/feature/audio-pp.html
that AIF2 ADC Stereo Capture Route is set to Mix Mono.

TESTING ARGUMENT:
Experimentation with different stored alsa settings (from

sudo alsactl store -f - > YYYYMMDD_example_alsa_settings

) showed that settings files whose only substantial difference was in the setting
of AIF2 ADC Stereo Capture Route had the effect that audio from the PP was heard on the
remote phone when the value was Mix Mono and was not heard with the value Stereo.
Testing was done with the equivalent of
https://codeberg.org/boud/pinephone_hacks/src/commit/7c7b6660a4446a24747f2c2edbe1d57d863ffb9f/audio_hacks/sort_of_restart_audio
with the settings file
https://codeberg.org/boud/pinephone_hacks/src/commit/7c7b6660a4446a24747f2c2edbe1d57d863ffb9f/audio_hacks/20230806_example_alsa_settings#L271
that has the Mix Mono value selected.

RECOMMENDATIONS:

AIF2 ADC Stereo Capture Route should be initialised or set to something in one of the
.conf files (in the PP case, most likely in VoiceCall.conf), at least for the PinePhone,
to prevent users who experiment and have
difficulty remembering which of the 50 PinePhone alsa parameters should be set in which way from
accidentally sabotaging their otherwise working audio calls;
Based on Megi's 2020 page and my testing, it seems that the correct value should be Mix Mono.

COMMENT:
While setting all 50 of the alsa settings for the PinePHone

$ sudo alsactl store -f - |grep "name " |wc
50     258    1788

in the .conf files is most likely unnecessary, there could be others that are necessary too. Ideally,
someone who really understands how the PP audio system works (including Megi's two diagrams
at https://xnux.eu/devices/feature/audio-pp.html) should be able to make these recommendations.

Some other phones may need this or other parameters initialised too.

Answer 1 · 2023-10-21T23:45:53.000Z

AIF2 ADC Stereo Capture Route is also (currently) uninitialised in Debian trixie:

https://packages.debian.org/source/testing/alsa-ucm-conf
currently `alsa-ucm-conf (1.2.10-1):
- apt-get source alsa-ucm-conf; grep -ri "AIF2 ADC Stereo Capture" . gives

      Reading package lists... Done
      NOTICE: 'alsa-ucm-conf' packaging is maintained in the 'Git' version control system at:
      https://salsa.debian.org/alsa-team/alsa-ucm-conf.git
      Please use:
      git clone https://salsa.debian.org/alsa-team/alsa-ucm-conf.git
      to retrieve the latest (possibly unreleased) updates to the package.
      Need to get 57.2 kB of source archives.
      Get:1 https://repo.mobian-project.org trixie/main alsa-ucm-conf 1.2.10-1mobian1 (diff) [11.2 kB]
      Get:2 https://repo.mobian-project.org trixie/main alsa-ucm-conf 1.2.10-1mobian1 (dsc) [1,183 B]
      Get:3 https://repo.mobian-project.org trixie/main alsa-ucm-conf 1.2.10-1mobian1 (tar) [44.7 kB]
      Fetched 57.2 kB in 1s (52.7 kB/s)        
      dpkg-source: info: extracting alsa-ucm-conf in alsa-ucm-conf-1.2.10
      dpkg-source: info: unpacking alsa-ucm-conf_1.2.10.orig.tar.bz2
      dpkg-source: info: unpacking alsa-ucm-conf_1.2.10-1mobian1.debian.tar.xz
      dpkg-source: info: using patch list from debian/patches/series
      dpkg-source: info: applying 0001-ucm2-add-PineTab-configuration.patch
      dpkg-source: info: applying 0002-ucm2-add-improved-Librem-5-profiles.patch
      dpkg-source: info: applying 0003-ucm2-add-profiles-for-OnePlus-6-6T-Pocophone-F1.patch
      dpkg-source: info: applying 0004-ucm2-add-PinePhone-Pro-configuration.patch

So AIF2 ADC Stereo Capture Route is absent.

Answer 2 · 2023-10-30T10:34:59.000Z

Patches (pull requests) are welcome. You may add this to the verb enable sequence.

Answer 3 · 2023-11-01T01:05:43.000Z

Patches (pull requests) are welcome. You may add this to the verb enable sequence.

Done. Even if this is the wrong value, at least testing the out-of-the-box settings for the PP will become one step closer to being reproducible - reproducibly wrong is better than sometimes right, sometimes wrong.

Answer 4 · 2023-11-04T22:58:11.000Z

The full Mic1 / EnableSequence that works for me for earpiece phone calls, avoiding the question of whether the alsa-ucm-conf official flow diagrams [1] are correct in principle or in practice, is at [2], and this includes AIF2 ADC Stereo Capture Route set to Mix Mono.

(Putting the same long set of parameters in SectionVerb / EnableSequence in VoiceCall.conf and doing a general audio reset gave me a no-audio phone call followed by a normal audio call. My interpretation is that SectionVerb / EnableSequence in VoiceCall.conf is not run on the first call after a general audio reset. The flow diagrams suggest that the no-audio call must have gone through UCM Verb Sequence / Switch verb / transition sequence = present; and that gnome-calls/callaudiod/pipewire/pipewire-pulse calls never go through UCM Device Sequence / Switch device / transition sequence = present. This would explain why this VoiceCall.conf seems to work on every call.)

[1] https://www.alsa-project.org/alsa-doc/alsa-lib/group__ucm__conf.html

[2] https://codeberg.org/boud/pinephone_hacks/src/branch/main/audio_hacks/Allwinner_A64_PinePhone/VoiceCall.conf

Answer 5 · 2023-11-06T17:09:27.000Z

Just for the record, AIF2 ADC Stereo Capture Route is just one of 15 parameters that are uninitialised by the current alsa-ucm-conf three PinePhone/*.conf files:

git clone https://github.com/alsa-project/alsa-ucm-conf
cd alsa-ucm-conf/ucm2/Allwinner/A64/PinePhone
grep -h cset *.conf |sed -e 's/cset .name=.//' -e "s/'.*//g" -e 's/^\s*//' |sort |uniq -c |sort -n -k1,1 |wc

gives

which leaves 50 - 35 = 15 parameters ignored (actually some are "double" parameters that have left+right values adjustable independently). If someone tries to fix things interactively in alsamixer or with amixer on the command line and adjusts any of those 15 parameters in a way that is "wrong", then it appears impossible for alsa-ucm-conf to correct them during a phone call, since they are not listed anywhere.

Related discussion: https://gitlab.com/fuzzy7k/pinephoneucm/-/issues/2

Answer 6 · 2023-11-07T17:31:33.000Z

In case people want to work through and discuss which parameters can be ignored, and what defaults the unwise-to-ignore parameters should have, here is the full set of 15 un-initialised parameters, in alphabetical order, with italics for AIF2 ADC Stereo Capture Route from the title of this issue:

ADC Gain Capture Volume
AIF1 AD0 Stereo Capture Route
AIF1 Slot 0 Digital ADC Capture Switch
AIF2 ADC Mixer AIF1 DA0 Capture Switch
AIF2 ADC Mixer AIF2 DAC Rev Capture Switch
AIF2 ADC Stereo Capture Route
AIF2 Digital ADC Capture Switch
AIF2 Inv Digital ADC Capture Switch
Headphone Jack
Headset Jack
Headset Microphone Jack
Line In Playback Volume
Mic1 Boost Volume
Mic1 Playback Volume
Mic2 Playback Volume

Answer 7 · 2023-11-07T18:35:55.000Z

Apparently (per irc discussion at https://matrix.to/#/#linuxcallaudio:matrix.org ), the three jack parameters (9, 10, 11) are readable by alsa, but it cannot set their values; setting them is handled by the hardware and read by the kernel.

Answer 8 · 2024-01-09T18:39:22.000Z

I'll let someone open a new issue if s/he wants to make proposals for the other un-initialised parameters (especially the other 7 AIF1/AIF2/ADC un-initialised parameters. My specific proposal here has been accepted and merged, so I'm closing it.