Forgot to reply-all.
---------- Forwarded message ----------
From: "bch" <brad.har...@gmail.com>
Date: May 15, 2016 10:01 AM
Subject: Re: Audio - In kernel audio mixing
To: "Nathanial Sloss" <n...@netbsd.org>
Cc:


On May 15, 2016 8:29 AM, "Nathanial Sloss" <n...@netbsd.org> wrote:
>
> Hi,
>
> I've been working away at in kernel audio mixing for the past 6 weeks or
so.
>
> I've made archives of two different approaches to in kernel audio mixing
and
> made them available on ftp.NetBSD.org/pub/NetBSD/misc/nat
>
> The first is vaudio-kern.tgz  -  This will do in-kernel audio mixing if
one
> creates a vaudio device for their sound card.
> My hope is that vaudio devices will replace the standard audio devices in
> future.
>
> A vaudio device say vaudio0 vsound0  vmixer0 and vaudioctl0 work just like
> their traditional counterparts except you can open a vaudio0/vsound0
device
> for reading and writing as many times as you like and the audio will be
mixed.
>
> In practice I've found that on the RPI2 I was able to play 100 songs at
once
> utilising about 20% of the cpu and on my laptop 340 (15 % cpu
consumption) or
> so any more than that and blocks were delayed giving a stuttering sound.
>
> I am aware of this problem and I can fix it for SMP systems but not UP as
it
> would require creating additional kernel threads to aid in mixing.
>
> The second is audio-alt.tgz - This is changes to audio.c that allow for in
> kernel-mixing.
>
> However I was only able to play about 60 songs on my laptop before my
computer
> froze because the mixing is done in audio_pint called from the sound cards
> interrupt handler and the mixing of channels could not be done fast
enough for
> more than 60 channels resulting in a massive slowdown.
>
> The first approach vaudio introduces a little addional latency. 10-20ms
or so
> and all streams are converted to 16 bit SLINEAR 44100 Hz.

Is that an automatic, out-of-the-box 10-20ms for any and all streams? 2ms
on a single channel in a duplex stream is obviously noticeable (as
reference for what delay a human can perceive), so 20ms could be considered
relatively large. I don't know what a person would accept as far as
audio/video discrepancy, but have you tried watching a video clip? What was
your feeling of the quality?

> Vaudio utilizes the traditional audio device so for those who want
precision
> greater than 16 bits, the traditional audio device still exists.
>
> The second approach audio-alt introduces no additional latency still
> converting streams to 16 bit SLINEAR.
>
> I believe that the vaudio approach is better and wanted to start a
discussion
> about in kernel-mixing and hopefully which approach (if any) should be
> included in NetBSD in future.
>
> Best regards,
>
> Nat.

Reply via email to