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.