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