0

I am currently working on a project with a soundcard which is driven bij a ~12 Mhz clock and ~24Mhz clock to play both 44.1 and 48khz audio. I switch these clocks with a GPIO. This means I do not want any resampling to happen. My question is: Is there any way to disable resampling from kernel space?

I know how to disable it from userspace with the asoundrc.conf, but I would prefer to do it from kernel space since I do not want any user to ever be able to change this config file and thus enable/disable resampling, not even root.

Thanks

0

1 Answer 1

1

ALSA doesn't resample by default, in particular the kernel drivers don't resample.

So, there is no way to disable resampling in kernel space.

ALSA does resampling by plugins (in user space, rate or plug). ALSA by default offers plug over the non-resampling hw, and I guess there is probably a way to configure ALSA to don't do this by default, but it would probably affect all sound cards.

but I would prefer to do it from kernel space since I do not want any user to ever be able to change this config file and thus enable/disable resampling, not even root.

They just have to use the correct device to avoid resampling, no need to change their configuration. Also, it's a user's decision, and not your decision.

Finally, Pulseaudio does resampling all over the place, and quite a few users will run Pulseaudio on top of ALSA.


Although it is a plugin ALSA does tell this plugin to resample by default.

No, it doesn't. The plugin rate is made specifically to resample, and the plug plugin uses rate among with other plugins. The idea that somehow "ALSA tells plugins to resample" is simply wrong.

I need to know where the kernel decides which bitrate will be outputed.

All ALSA kernel drivers specify this.

Lastly, it is not a user decision it is a Hi-Fi streaming device.

But it's the user's decision to build any plugin chain that he wants. Including resampling. If I want to resample, and you somehow would prevent me from doing that (which you actually can't), I'd get really angry as a user.

I have a swithcing clock which needs to get activated. This also means I need to tell ALSA the sysfrequency of the codec has changed.

And that's fine, you do this in the kernel by looking at the bitrate you get. You don't have to worry about resampling.

Your answer does not really help me....

I think you misunderstood some fundamental concepts, and I hoped to make them a bit more clear. If you still insist to somehow "disable resampling for ALSA in the kernel": I wish you all the best, but I can only strongly recommend to try to understand how it works, then you will see that this doesn't make sense.


You are talking about user space, which is irrelevent for my use case.

You were talking about resampling, which is irrelevant for kernel space. Resampling only happens in user space.

It is not possible to tell ALSA to switch a GPIO whenever the frequency changes,

Of course it is. The kernel module advertises supported bitrates. You set GPIO based on the bitrate you get when audio is sent to the kernel module. That is if your GPIO selects 12 MHz to play 44.1kHz audio and 24 MHz to play 48kHz audio, and you are not in the reverse situation where your 12/24 MHz are changes outside of your control, and you must then adapt audio playback accordingly.

If you are in the latter situation, then there is no good solution. ALSA doesn't expect a HW audio output to change its bitrate in the middle of audio playing.

this means I also need to tell all drivers in kernel space the frequency has changed (MCASP, sound codec, PCM)

So are you in the reverse situation? Because that's the only situation I can think of where this requirement would make sense.

Then I guess the best you can do if you insist on no resampling is to error out of the current audio stream, advertise the new bitrate as the only bitrate, and rely on userspace to restart audio. Which should be doable, since it is an embedded system and you control userspace completely (and all this information should have been part of the question in the first place).

But a good description of the actual problem and circumstances in the question would really help.

7
  • While perfectly agreeing with you that the kernel won't resample, I am not sure you can write that "ALSA doesn't resample by default" Since Alsa "default" virtual device usually links to a dmix plugin which resamples when needed. (Well… used to AFAIR)
    – MC68020
    Nov 5, 2022 at 14:14
  • Compared to Pulseaudio (which does resample by default), ALSA just doesn't - you can choose resampling or not by choosing the right device. If you have a better way to word it, I am happy to use it.
    – dirkt
    Nov 5, 2022 at 16:37
  • I will not use pulseaudio. Although it is a plugin ALSA does tell this plugin to resample by default. I need to know where the kernel decides which bitrate will be outputed. In other words the first function tthat gets called when playing a song. Lastly, it is not a user decision it is a Hi-Fi streaming device. And the use case says so. I have a swithcing clock which needs to get activated. This also means I need to tell ALSA the sysfrequency of the codec has changed. Your answer does not really help me....
    – Lars
    Nov 8, 2022 at 10:55
  • This is an embedded board. Not a desktop. There will not even be an ability to build plugins. I know how ALSA works. I am talking about kernel space. You are talking about user space, which is irrelevent for my use case. I need to write a custom driver for the kernel. It is not possible to tell ALSA to switch a GPIO whenever the frequency changes, this means I also need to tell all drivers in kernel space the frequency has changed (MCASP, sound codec, PCM) from 44.1Khz to 48Khz which is needed to get a bit perfect playback which is the main focus as it is a HiFi streamer.
    – Lars
    Nov 8, 2022 at 15:02
  • 1
    Great answer from you dirkt! (and Kudos++ for the effort). @user547785 would probably benefit from diving into for example the envy24 Alsa driver github.com/torvalds/linux/tree/master/sound/pci/ice1712 to understand how changing the sampling frequency can be achieved (without, of course, no resampling facility implied)
    – MC68020
    Nov 9, 2022 at 10:45

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .