On May 15, 2016 10:17 AM, "bch" <brad.har...@gmail.com> wrote: > > 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?
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.
