[haiku-development] Re: Considering the audio Mixer formats
- From: "Adrien Destugues" <pulkomandy@xxxxxxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Sat, 06 Feb 2016 16:00:44 +0000
6 février 2016 16:43 "Dario Casalinuovo" <b.vitruvio@xxxxxxxxx> a écrit:
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.
Why not provide a standard node for doing this? Why shouldn't it be the mixer
node?
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.
Floating point math is not a magical thing to increase precision. Actually, the
"float" format has only 24 bits of mantissa, so if you are after precision, you
are better off using 32-bit integers.
What floating point formats give you is a larger range (because you can use big
exponent), and ability to represent decimal numbers. This allows you to not
need to compromise too much between the dynamic and precision of your signals.
Basically, you can have your signal range between -1 and 1, then you mix 12
signals together, and you have a signal that ranges between -12 and 12. But
there is no risk of saturating anything because you have a lot of dynamic (you
can have very big float numbers) and your precision is always 24-bits no matter
what (you just change the exponent to remember that your numbers are bigger).
There is a problem with this, however: some algorithms do rely on having
everything in the -1:1 range, so for these you still have to normalize your
inputs. In the end, it is much simpler and faster to work with 32-bit samples.
The extra 8 bits (really, have a look at professional hardware, nothing goes
past 24bits because it would be useless) can be used for extra precision and
are, usually, more than enough for all needs. But, if you really want to do
floating point audio, our mixer supports it as well, it is not a problem. I
don't see any use in restricting to a single format?
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 :-)
I gave examples of what I'm doing with it and I did not notice any problems. So
"see for yourself" doesn't work, sorry.
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.
I still fail to see what the problem is. The mixer code is quite simple, and
the current algorithms target a low latency. I can see the need for an
high-quality algorithm, probably for non-realtime uses (because high quality
algorithms tend to add latency). And I still don't see what format conversions
have to do with this. They cost us a simple normalization operation per sample
(one multiplication, one addition), which is not where the problems are coming
from (even the linear interpolation algorigthm, which is the simplest thing you
could come up with, needs more math than that).
--
Adrien.
Other related posts:
