Inappropriate Envy24 rate locking/XRUNS for playback and/or recording

[GitHub issues - opened]

alsa-project/alsa-tools issue #11 was opened from foobers:

On Debian 'oldstable', there's a rate-locking and 'low pitch' problem with following setup (same on Mint/Unstable):

- dedicated audio card:
Multimedia audio controller: VIA Technologies Inc. ICE1712 [Envy24] PCI Multi-Channel I/O Controller (rev 02) based

- integrated audio in graphics card:
Audio device: Advanced Micro Devices, Inc. [AMD/ATI] Device xxxx

- onboard audio chip:
Audio device: Advanced Micro Devices, Inc. [AMD/ATI] xxx (Intel HDA) (xxxx)

Initially, in 'alsamixer', there are two values shown for 'Multi Track Internal Clock': '[44100]' and 'Default [41000]' for the dedicated AC. In alsamixer, it's only possible, to change the first value, but without any noticable effect (only using 'Envy24 Control' or 'Mudita24' seem to have).

Now, using the audio card, sometimes, right from the start, playback of internet audio streams (in Firefox) seems to have a wrong sampling rate set (i. e. probably 48 kHz), resulting in audibly lower 'pitch' and sound distortion. 

Even worse, playback isn't always affected from start, but recordings from 'gnome-sound-recorder' will be in either case. This can result in several hours of recorded audio being borked, since there's no controlling of the outcome, until recording is stopped, which is very undesirable, especially in ad-hoc recording situations.

I was able to track down the problem being linked to 'Master clock', 'Rate state' settings 'Locked' and 'Reset' in 'Envy24 Control Utility': checking and unchecking / switching forth to 48kHz and back to 44100Hz, helped resetting both playback and recording sampling rate to 44100Hz, to perform regular audio recordings with 'gnome-sound-recorder'.

The rate locking problem can also occur, after playing MP4 videos with Mplayer (media info: sampling rate 44100Hz); then, audio files (media info: bit rate 112Kbit/s, sampling rate 44100Hz), previously kown-good audio records will be played at a noticably lower 'pitch', also recording (with gnome-recorder) now will record at a lower pitch, i. e wrong rate.

In alsamixer, there are now two different values shown for 'Multi Track Internal Clock': '[44100]' and 'Default [48000]'.

Also, when trying to play a regular film DVD with VLC now, it very likely shows short dropouts of black screen and audio, at steady intervals of ~2s, requiring performing a logoff and login, to reset rates again.

Interestingly (and unexpectedly), setting 'Master clock' to 'S/PDIF in', seemed to internally freeze the clock / source to 'S/PDIF', in effect preventing any more sound output or recording from the device; trying to switch back to 44110Hz or 48000Hz would fail and the could only be reset, after until doing a complete reboot.

I've seen references, pointing to the rate locking issue, which suggest, that unchecking 'locked' and 'reset' for 'Rate state' in 'Envy24' would be the key here - only, on my system, those values didn't seem to be initially checked (at least not visually):

https://discourse.ardour.org/t/all-sound-is-low-pitched/82149

So the solution here would seem to be, to ensure unset 'Rate state' options at boot time; in contrast to this suggestion, the documentation says, 'locked' might cause 'errors' and 'XRUNS', and 'reset' only would be the recommended setting by default, to allow applications alter the clock sample rate to their needs, resetting them to the selected 'Master clock' default afterwards:

https://wiki.archlinux.org/title/Envy24control#Rate_State

While this seems to make sense, 'reset' not being set appropriatly, might also explain some of the weird behavior described above, namely, when some application sets and locks 48kHz for playback and/or input channels, which then don't match the input and/or output of another application, started after that.

The effect of VLC/MPlayer showing 'dropouts' may also have its cause in the mentioned 'XRUNS', in this case, supposedly buffer underruns, when applying an 48kHz sampling rate to video files with 44,1kHz audio streams, or buffer overflows, when applying 44,1kHz sampling to files with 48kHz audio streams:

https://unix.stackexchange.com/questions/199498/what-are-xruns

What (combination) of 'Rate state' settings (if any) would be a 'bullet-proof' remedy here, I cannot tell, since my settings obviously both empty. So, either this was a false visual feedback, or 'reset' does not work as intended.

So far, I can't confirm, if these settings differ in Mint, where the problem shows, too, as said (or if the defaults have been altered). Currently I can't try perma-setting 'reset' only (the recommended default), but I think it didn't work out before for recording.

Issue URL     : https://github.com/alsa-project/alsa-tools/issues/11
Repository URL: https://github.com/alsa-project/alsa-tools