Bug 216548 - Crack when switching to an audio file with different sampling rate
Summary: Crack when switching to an audio file with different sampling rate
Status: RESOLVED UNREPRODUCIBLE
Alias: None
Product: Drivers
Classification: Unclassified
Component: Sound(ALSA) (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: Jaroslav Kysela
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2022-10-02 12:00 UTC by Maeda
Modified: 2022-11-15 06:10 UTC (History)
1 user (show)

See Also:
Kernel Version: 5.19.10
Subsystem:
Regression: No
Bisected commit-id:


Attachments
asoundrc file that uses dmix to workaround the issue (1.04 KB, text/plain)
2022-11-02 07:31 UTC, Maeda
Details

Description Maeda 2022-10-02 12:00:47 UTC
Hello,

Output of alsa-info.sh is here: http://alsa-project.org/db/?f=113b789390149cf106c025f31cd47991f02779f5

I have one (big, annoying) crack that occurs on those special events:

1- Powering up the system (while booting, especially when loading kernel stuffs), probably when "powering up the sound card when snd_rme96 module is loaded".
2- When playing audio files, but only when switching to another file having different sampling rate than the previous one (e.g., playing 44.1KHz file to 96KHz file do a crack when track is changing, same when going from 96KHz to 44.1KHz). No crack if keeping same sample rate file. Note that all files plays well "after the crack occurred".

That is happening when using aplay or another music player.

I am wondering what is the card doing when sampling rate changes (power off, then power on the card???).

I need someone that can look to the source code and help me solving that.

Thanks.
Comment 1 Maeda 2022-10-30 15:47:52 UTC
This is not happening anymore if I set .asoundrc file to use dmix and resample, then all files will be resample to that unique value and the "crack" happens only once after boot.

Let's say this is solved and is probably by design that the sound card powers off and powers on to change sample rate.
Comment 2 Maeda 2022-11-01 11:56:11 UTC
I got an answer from RME directly and they think this should be related to the (ALSA) driver itself.

It is an old product so they cannot verify the behavior but the card should not reset or switch off to change sample frequency as far as they remind how the card works.

All point to the drive now. Please double check how the driver is written and report back here, I can test any fix you can provide.

Only workaround today is on my previous post: resample all audio to the same value to only get one pop/crack at start and no more after.
Comment 3 Takashi Iwai 2022-11-01 12:17:36 UTC
The hardware information about this card is never available publicly, so no one has the exact idea about the driver's behavior.  That is, it's nothing but a guess work, and it means that you'd need to debug it with trial-and-error by yourself.

Does the crack happen only when switching the rate *during* the application playback?  Or if you run aplay with 44.1kHz (with hw or plughw), then aplay with 96kHz, does the same crack happen?  And the crack noise happens constantly?  Or is it a short burst?

If it's a short crack noise and it happens at loading the driver, you can debug it by putting a significant delay (for some seconds) at each initialization step in the driver code together with a debug print at each place, then identify which operation (e.g. register write) triggers the noise.
Comment 4 Maeda 2022-11-01 12:26:06 UTC
That is short crack (playing well after) at the beginning of every new (sample rate) file played from any of the software (aplay, audacity, audacious, etc.). It is exactly the same crack when powering on the PC, while loading kernel/modules stuff very likely when loading the driver.

I am not skilled enough to code this myself I think (and how to handle/load/test the new changes I would have done), but because this is an "old product", would it help to ask RME to publicly provide all needed stuff for you to fix that?

Do you think this is a lot of work to figure out the root cause and provide a patch? I can help the most I can of course (e.g., using IRC to speed up troubleshoot).
Comment 5 Maeda 2022-11-01 14:09:41 UTC
The two important common facts to generate a crack are:

- Loading the driver -to confirm but seems to be-
- Play a file with another sample rate than the previous one -verified-

I am able to confirm the second.
Unloading the driver while OS is running is still a challenge to me (because something is using it, unable to unload), so I am relying on OS boot where the crack is occurring to deduce that it is also one case where crack is occurring. The only (quick) idea I have is to blacklist the soundcore, snd_rme, snd_pcm, snd_timer and restart the system to hear if any crack or not (if no driver load, no crack). That might be the easiest way (for me) to confirm that step.

I was expecting with such detailed information that a very quick relationship can be achieved by someone knowing the driver code. Those two actions surely have common steps ("register write" to take back you terms, etc.) to highlight the root cause in the code.
Comment 6 Maeda 2022-11-01 14:16:04 UTC
For your information, RME just confirmed me ALSA has all information needed for a driver build (at least at the beginning) and nothing today to give me to help on that topic.
Comment 7 Takashi Iwai 2022-11-02 06:42:12 UTC
No, we (ALSA devs) haven't received any.  Maybe the author of the driver development received the information, but it wasn't released publicly.

And, it's a matter that can be reproduced locally, hence it's only you that can test efficiently.  The code sound/pci/rme96.c is a relatively small piece.  Go for debugging.  You can begin with putting a debug print at each step in the PCM functions there, then put ssleep(5); or such to take the delay.  Then you can see at which point the device produces the noise.
Comment 8 Maeda 2022-11-02 07:25:30 UTC
You are right, if only affects me (old hardware), it does not worth spending too much time on this (especially with an existing workaround!).

I can attach my .asoundrc in case of someone needs it one day.

Detailed workaround:
- Power off the amplifier
- Use RMEDigicontrol to set up an Attenuation of -18dB, or use amixer command.
- Use Dmix with any value -default 48Khz- for resample. If using another value than 48KHz, ensure to play a short "silence" file matching your sample rate at boot (using cron and @reboot and aplay command). The "dummy" file can be created with Audacity for example.
- Power on the PC (same case with reboot)
- Only power on the amplifier when reaching the login screen.
No crack should happen after that.

I have no knowledge in C but thanks for the tips, I will try if enough time and motivation. If needed I can still get some help from gentle IRC volunteers to figure out the issue.

Thank you :)
Comment 9 Maeda 2022-11-02 07:31:31 UTC
Created attachment 303119 [details]
asoundrc file that uses dmix to workaround the issue
Comment 10 Maeda 2022-11-15 06:10:16 UTC
No action needed from ALSA end, let's close this bug for now. No need to keep it opened.

Note You need to log in before you can comment on or make changes to this bug.