Enable snd-aloop module for audio projects

[vTomsonek]

Describe the feature

Hello WildRiser,

First of all, thank you for your amazing work on this kernel! I'm using your release WKSU-13971-android12-5.10.226 (v1.5.11-r4) on my Xiaomi 12 Pro (zeus) and it works great.

I'm working on an advanced audio routing project that requires the ALSA loopback module (snd-aloop.ko).

Would it be possible for you to enable it in the kernel config for a future release? It's a single line change:
CONFIG_SND_ALOOP=m

Having this module would be a huge help and unlock new possibilities for users. Alternatively, if you could just compile this single snd-aloop.ko module against your current kernel source and share it, that would also be fantastic.

Thank you for your time and consideration!

Link to documentation

No response

Screenshots

No response

[fatalcoder524]

1. Why not CONFIG_SND_ALOOP=y as it directly integrates in kernel? (Not sure if it bootloops or something)
2. If we make it as a module and expose it outside. It's gonna be like 100s of artifacts. 1 per kernel version.
3. If you want it as a module one way we could implement is to conditionally copy to your module folder if installed using AnyKernel3 zip script. Which is totally possible!

Just some questions and suggestions. It's not a confirmation of whether @TheWildJames will integrate or something. Also please share the git link of module and maybe some more info so we can take some decisions!

[vTomsonek]

Hello, and thank you so much for the incredibly fast and helpful response!

You are absolutely right, CONFIG_SND_ALOOP=y would be the perfect and cleanest solution for our project. Having it built-in directly into the kernel is exactly what we need.

Our goal is to create a high-quality, low-latency audio bridge between the phone and a PC, specifically for handling voice calls. This is for an office environment, to allow using a high-quality PC headset for mobile calls, eliminating the need for constant cable switching or poor quality Bluetooth solutions.

What we have achieved so far:

1. We have successfully created a KernelSU module that modifies the audio mixer (tinymix) to redirect the incoming call audio (the other person's voice) to a capture device.
2. We can successfully capture this audio on the PC in real-time using scrcpy.

The final and missing piece of the puzzle is routing the PC microphone back to the phone to be used as the in-call microphone. This is why we need the snd-aloop module – to create a virtual ALSA device that can act as this bridge. We would feed the PC microphone audio stream into one end of the loopback device, and then use our script to set the other end of the loopback device as the system's microphone during a call.

Regarding the git link for our module, it's currently a local project we are developing for our specific use-case, so it's not yet on a public repository. However, I would be happy to share the scripts (service.sh, etc.) here if that helps you in your decision-making.

Thank you again for your time and for considering this feature. Integrating this module would be a massive help!

[TheWildJames]

f9edbf7

test: https://github.com/WildKernels/GKI_KernelSU_SUSFS/actions/runs/18614440705

Thanks!

nvm had to do soem changes will add just wait please <3

[vTomsonek]

Hello again,

Thank you for your patience. I've consulted with a kernel expert to make sure our next steps are as precise as possible to solve this issue.

He strongly suggested that building snd-aloop as a module (=m) instead of built-in (=y) would be much better for our use case. This will give us the flexibility to load and unload the module dynamically for debugging and scripting purposes.

Here is the recommended configuration we would need:

CONFIG_SND=y
CONFIG_SND_DRIVERS=y
CONFIG_SND_PCM=y
CONFIG_SND_TIMER=y
CONFIG_SND_DYNAMIC_MINORS=y
CONFIG_SND_PROC_FS=y
CONFIG_SND_ALOOP=m

He also mentioned two potential pitfalls to keep in mind during the build process:

Please ensure that module signature enforcement won't prevent us from loading this unsigned module via KernelSU's insmod.

After flashing, we will verify the build by checking /proc/config.gz on the device to confirm that the final configuration matches the intended one.

If you could provide a new test build that incorporates these suggestions, we would be incredibly grateful and ready to test it immediately.

Thank you once again for your amazing support for the community!

[TheWildJames]

CONFIG_SND=y
CONFIG_SND_DRIVERS=y
CONFIG_SND_PCM=y
CONFIG_SND_TIMER=y
CONFIG_SND_DYNAMIC_MINORS=y
CONFIG_SND_PROC_FS=y

is
CONFIG_SND_ALOOP=y okay so i dont have to pack modules in the artifacts?

[fatalcoder524]

3. If you want it as a module one way we could implement is to conditionally copy to your module folder if installed using AnyKernel3 zip script. Which is totally possible!

@TheWildJames Even I think CONFIG_SND_ALOOP=y is bad. Just do CONFIG_SND_ALOOP=m and copy it to AnyKernel3 zip. and add a line in anykernel.sh.

Possible way to do it: https://github.com/WildKernels/OnePlus_KernelSU_SUSFS/blob/09adffd2c40f9f67271066a65a94d2d8515bc217/.github/actions/action.yml#L579

[TheWildJames]

Just simple copy to ak3 folder? could do that

[fatalcoder524]

Just simple copy to ak3 folder? could do that

Copy and those sed commands .. Those sed commands will insert code in anykernel.sh to copy the files from zip to some folder in system. you could

mkdir /data/adb/lkm
cp send_aloop.ko /data/adb/lkm/send_aloop.ko

something like this

Or just ignore this step and them them tell users to extract from AK3 zip. Your wish.

[vTomsonek]

Wow, thank you both for this detailed discussion!

The final solution proposed by @fatalcoder524 is perfect for me. Building it as a module (=m) and having the AnyKernel3 script automatically copy it to a persistent folder is exactly the clean and flexible implementation I was hoping for.

I'm ready and waiting to test the new build whenever you're ready.

Thank you again for your incredible support!

[TheWildJames]

no problem bud! ill get it added for you and let you know!

[TheWildJames]

@vTomsonek Hello! Hope you are still there!

Sorry about that! Had to work on the main project, now added and got it setup to copy to /data/adb/lkm

Latest ci build should have it ready to test when it is ready unless issues arise!

Thanks for your patience and Enjoy Wild Kernels!

[vTomsonek]

Hello,

First, I want to say a huge thank you for all the work you've done. We have made incredible progress.

I have tested the latest kernel build, and the snd_aloop.ko module was indeed inside the zip file! This is a massive success and proves we are on the right track.

I wanted to give you a full report on our findings, as we've hit a new, final challenge that requires a change in strategy.

What Worked (Success!)

• The snd_aloop.ko file was present in the modules/data/adb/lkm/ folder inside the zip.
• The automatic copying script didn't seem to run (the /data/adb/lkm folder wasn't created on my phone after flashing).
• However, I was able to manually adb push the snd_aloop.ko module to the phone, insmod it, and it worked perfectly! The Loopback card appeared on cat /proc/asound/cards. This is a huge victory.

The New Challenge (The "Two Islands" Problem)
After successfully loading the Loopback card, we hit a final, architectural wall.

Our goal was to make the main phone app use this Loopback card as a microphone during a call. We discovered that the main sound card (Card 0, waipiomtpsndcar) is a completely separate "island" from our new Loopback card (Card 1).

The main mixer (tinymix -D 0) has a list of microphone inputs (TX DEC0 MUX, etc.) that are "hard-wired" to its own hardware. It has no idea that our "Loopback" card even exists, so we cannot simply "select" it as a microphone source. We have created two isolated audio devices with no digital bridge between them.

Our New, Final Request (The "Virtual USB Headset" Plan)
We believe we have found the one true, fully software-based solution.

Instead of trying to build a bridge between two kernel cards, we need to create a virtual USB headset that the Android system itself will recognize and add to the in-call audio selection list (just like it does for a real, physical USB headset).

Our research shows this is possible using the USB Gadget Audio framework (g_audio).

Our new plan is to create a module that:

• Loads our snd_aloop.ko (which we already have, thanks to you!).
• Loads the g_audio.ko module to create a new, fake "USB Audio Gadget".
• Digitally "connects" g_audio to snd_aloop, so that what we feed into the Loopback device comes out of the "virtual microphone" of the fake USB headset.

This seems to be the only way to make the Android Phone app "see" our virtual device and allow us to select it.

Would it be possible for you to compile and add the g_audio.ko module (and its dependencies, like libcomposite.ko) to the kernel package, just as you did for snd_aloop?

We know this is a much more complex request, but it appears to be the final piece of this very complex puzzle.

Thank you again for your incredible support. We are ready to test immediately.

[TheWildJames]

Will work on this shortly, and will provide a link to ci builds or will make a fork and do edits there...

As many user wont need this i will ass a specific build for you, what kernels do you need?

[vTomsonek]

5.10.226-android12-2024-11

[TheWildJames]

thanks!