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

[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.

[foobers]

I can confirm, that, after setting 'reset', the playback from internet audio streams in Firefox still works after reboot (at present) in Debian oldstable (Cinnamon).

But not recording in 'gnome-sound-recorder', where the 'low pitch' is back again - this obviously comes from a wrong rate setting for input - or for other audio applications in general - as also shows, when playing the recorded file in Mplayer afterwards. To get correct audio recording rate, I needed to switch off 'reset' in Envy24 again.

But, a short wile after (after writing this comment), recording would be borked again, this time, without any success, of resetting the sampling rate the played back audio file.

Or so it seemed, since, after 'fiddling', trying to play back another, previously known-good record, was correctly played in Sound Recorder, Mplayer and VLC. So, it's obviously really a bad input sampling rate (or at least wrong sampling rate, relayed from Firefox to Sound Recorder), causing this problem (not covering the video playback issues in certain situations, as mentioned below).

'gnome-sound-recorder' has two aspects: recording and playback - and playing the recorded audio right after recording from within it, had the same low pitch, as Mplayer. Could it be, that Firefox still has another (44100Hz) setting locked, and the recorder, as well as Mplayer try using 48000Hz for playback, maybe (while 'reset' is set) - since the recorded file shows 44100Hz sampling rate information?

For Mint (Cinnamon), I can confirm, that set 'reset' option seems to be set out-of-the box, since I haven't altered it before and only now installed 'Envy24 control utility', to check this.

But there, the low pitch was also showing, when playing back the same internet audio stream.

I coult only get appropriate playback rate and sound, after closing all sound applications (including 'sound' control), checking both 'locked' and 'reset' options in Envy24, switching forth 'Master clock' to 48kHz and back to 44,1kHz, opening 'Sound' control again switching forth to digital S/PDIF output and back to analog output for the audio card. Only then I would get sound of normal pitch/rate. I haven't checked recording there.

Anyway, it seems to be a real mess, without a safe way of getting reliable recording/playback results - unless fiddling about and crossing fingers each time, prior to recording anything - and then, there still seems to be no guarantee, to get the expected results.

EDIT:
After another few tries, it seems, that the initial internet audio stream might actually be 48kHz, at least, that's what 'Actual rate' in Envy24 shows ('reset' flag set only), after starting the stream, regardless, whether 'Master clock' is set to anything else:

https://fm4.orf.at

Only then, playback sounds correct - but I can't seem to get any reliable recording results, it seems to (almost) always record at low pitch/wrong rate. And setting 'locked' flag in Envy24 too, will prevent playback in Firefox from even starting (and seems not recommended by the documentation anyway).

I'm stumped here.