[haiku-development] Re: Considering the audio Mixer formats

  • From: Dario Casalinuovo <b.vitruvio@xxxxxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Sat, 6 Feb 2016 16:42:48 +0100


What's your plan for mixing the output of the game kit with the output
from the media kit then? That sounds like a job for the system mixer to me,
and the system mixer is a media node.


What I mean is that not necessarily every need of the game_kit should be
handled by the media_kit. I.E. doesn't harm if the game_kit had it's own
node doing the appropriate conversions.


Have you looked at the current mixer code? Precisely because it does
1-pass format conversion and resampling, there is not any added latency
when compared to just resampling.



Also, floating point math is slower than integer math, so the float
formats would be the ones slowing everyone down.


The main reason for doing floating point math is related to precision, that
in professional audio might be very important.


But that would be noticeable only on a very old 133MHz machine, unless you
are dealing with hundreds of media nodes in realtime?


Shouldn't we reach this point?


The Mixer is already used by all and every sounds produced in the Media
Kit. Playing Doom, watching a Video with MediaPlayer, composing music in
Sawteeth or Sequitur + SynC Modular are things I've already done with it.
I'm sure Peete Goodeve can show you what he does with the Music Weaver as
well.


Try to use the actual mixer in an audio recording program and see yourself
:-)



The Mixer also has a plug-in system where you can replace the resampling
algorithm. A few years ago, I added the linear interpolation we currently
use as default, and there is still the older (and faster) drop/repeat
sample one (with a very noticeable quality drop when you use it). There are
of course even better algorithms available, with the drawback that they
increase latency a little more (but we are talking maybe a dozen of samples
or so). It's easy to add more resampling algorithms without having to
remove support for different input and output formats, as the format
conversion is already a solved problem.


This might be a solution, we can supply a run mode targeted for real time
audio.

Other related posts: