[alsa-devel] Possibility of routing at the kernel level
Hi all,
I am currently using the ALSA loopback driver to create a "virtual" sound card to abstract underlying real sound cards. I capture from the loopback in user-space, and then subsequently playback to a real sound card.
The issue with this is that there is a significant latency introduced (~100ms) due to the number of transitions of the stream from user to kernel space. I am seeking a way to avoid this.
My question is this: is there any way of routing PCM substreams at the kernel level, so that we can avoid the need to pipe audio back up to user-space with the loopback capturer? If there is no current solution that would achieve this, I would proposition to design and implement a system that uses a top-level ALSA driver, which then routes dynamically to one or many subscribed lower-level "audio path" drivers. The system would also have the option to loopback upon itself.
Does anyone see any reason that I couldn't (or shouldn't) attempt such a solution? All feedback is welcome.
Regards, Mark
Hi all,
Following my initial proposition on Friday for kernel-space audio routing, we at Fiberdyne Systems have since published our initial source for such a solution, which we are calling ALSA Virtual Driver, or simply AVIRT.
Please find the source here for your perusal: https://github.com/fiberdyne/avirt
Currently we use module parameters for the kernel module, however, we will be porting configuration to another system, such as configfs/sysfs.
We are completely open to suggestions and constructive criticism.
Regards, Mark
On Fri, Aug 24, 2018 at 4:27 PM Mark Farrugia mark.farrugia@fiberdyne.com.au wrote:
Hi all,
I am currently using the ALSA loopback driver to create a "virtual" sound card to abstract underlying real sound cards. I capture from the loopback in user-space, and then subsequently playback to a real sound card.
The issue with this is that there is a significant latency introduced (~100ms) due to the number of transitions of the stream from user to kernel space. I am seeking a way to avoid this.
My question is this: is there any way of routing PCM substreams at the kernel level, so that we can avoid the need to pipe audio back up to user-space with the loopback capturer? If there is no current solution that would achieve this, I would proposition to design and implement a system that uses a top-level ALSA driver, which then routes dynamically to one or many subscribed lower-level "audio path" drivers. The system would also have the option to loopback upon itself.
Does anyone see any reason that I couldn't (or shouldn't) attempt such a solution? All feedback is welcome.
Regards, Mark
On Mon, 27 Aug 2018 07:57:00 +0200, Mark Farrugia wrote:
Hi all,
Following my initial proposition on Friday for kernel-space audio routing, we at Fiberdyne Systems have since published our initial source for such a solution, which we are calling ALSA Virtual Driver, or simply AVIRT.
Please find the source here for your perusal: https://github.com/fiberdyne/avirt
Currently we use module parameters for the kernel module, however, we will be porting configuration to another system, such as configfs/sysfs.
We are completely open to suggestions and constructive criticism.
Did you try snd-aloop driver? I'm not advocating it (as it doesn't mean a better latency), but it's often an option.
thanks,
Takashi
Regards, Mark
On Fri, Aug 24, 2018 at 4:27 PM Mark Farrugia mark.farrugia@fiberdyne.com.au wrote:
Hi all,
I am currently using the ALSA loopback driver to create a "virtual" sound card to abstract underlying real sound cards. I capture from the loopback in user-space, and then subsequently playback to a real sound card.
The issue with this is that there is a significant latency introduced (~100ms) due to the number of transitions of the stream from user to kernel space. I am seeking a way to avoid this.
My question is this: is there any way of routing PCM substreams at the kernel level, so that we can avoid the need to pipe audio back up to user-space with the loopback capturer? If there is no current solution that would achieve this, I would proposition to design and implement a system that uses a top-level ALSA driver, which then routes dynamically to one or many subscribed lower-level "audio path" drivers. The system would also have the option to loopback upon itself.
Does anyone see any reason that I couldn't (or shouldn't) attempt such a solution? All feedback is welcome.
Regards, Mark
Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
On Mon, Sep 3, 2018 at 11:01 PM Takashi Iwai tiwai@suse.de wrote:
On Mon, 27 Aug 2018 07:57:00 +0200, Mark Farrugia wrote:
Hi all,
Following my initial proposition on Friday for kernel-space audio routing, we at Fiberdyne Systems have since published our initial source for such a solution, which we are calling ALSA Virtual Driver, or simply AVIRT.
Please find the source here for your perusal: https://github.com/fiberdyne/avirt
Currently we use module parameters for the kernel module, however, we will be porting configuration to another system, such as configfs/sysfs.
We are completely open to suggestions and constructive criticism.
Did you try snd-aloop driver? I'm not advocating it (as it doesn't mean a better latency), but it's often an option.
thanks,
Takashi
We have tried snd-aloop, and this would otherwise be our adopted solution, if not for the following issues: 1. The latency involved when looping back to user-space. We would prefer to avoid unnecessary latency altogether if possible. 2. We wish to hold each input in a different SMACK security context - aloop does not give a PCM device per input, but rather one PCM device, with a substream per input. This is an issue since SMACK can only apply one label per PCM device. 3. We want to dynamically construct the sound card PCM devices based on user configuration.
participants (2)
-
Mark Farrugia -
Takashi Iwai