Possibility of routing at the kernel level

Possibility of routing at the kernel level

[Mark Farrugia]

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

Re: Possibility of routing at the kernel level

[Mark Farrugia]

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

Re: Possibility of routing at the kernel level

[Takashi Iwai]

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
> 

Re: Possibility of routing at the kernel level

[Mark Farrugia]

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.