On May 15, 2016 10:17 AM, "bch" <brad.harder%gmail.com@localhost> wrote:
>
> Forgot to reply-all.
>
> ---------- Forwarded message ----------
> From: "bch" <brad.harder%gmail.com@localhost>
> Date: May 15, 2016 10:01 AM
> Subject: Re: Audio - In kernel audio mixing
> To: "Nathanial Sloss" <nat%netbsd.org@localhost>
> Cc:
>
>
> On May 15, 2016 8:29 AM, "Nathanial Sloss" <nat%netbsd.org@localhost> 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?
I was looking for other developer notes or psycho-acoustic material when I remembered seeing this write-up many years ago. So for sake of completeness, counterpoint my own open question:
http://manuals.opensound.com/developer/audio_timing.html
> > 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.