Audio - In kernel audio mixing

[Nathanial Sloss <nat%netbsd.org@localhost>]

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.

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.