tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Fwd: Re: Audio - In kernel audio mixing



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?

> 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.



Home | Main Index | Thread Index | Old Index