[haiku-development] Re: Considering the audio Mixer formats
- From: Dario Casalinuovo <b.vitruvio@xxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Sat, 6 Feb 2016 20:41:58 +0100
Before all thanks to all for replying I'm having my own reflections on the
argument and that's very fine.
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.
Besides anything, floating point math is known to be generally more
flexible and have simpler math that means simpler algorithms, it's just the
way pro audio out there represent the data. We should consider this besides
any preference or technical implementation. Personally I've always used
floating point math, probably because my first steps on serious audio were
on jack.
I still fail to see what the problem is. The mixer code is quite simple,
and the current algorithms target a low latency.
What I've been hypotizing is if we can reach better performances or fine
tune them if we have to handle only one format.
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).
I agree completely on a second thought, that the idea of using only
floating point was not a good one.
But let's move the discussion a level higher and see where the problem is.
I want to start first with a question, what are the major needs of realtime
audio?
1 - Low latency
2 - Avoid data conversions
The low latency doesn't depend strictly and inexorably from the mixing
algorithm quality/speed itself, but more on which elements are put to be
mixed. If I put a chain of nodes that plays audio into the Haiku's mixer, I
can reasonably suppose that under normal conditions it will adapt itself to
match the best choice. What might begin to be a problem, is when different
framerates and formats are put into the mixing thread. At this point the
mixer have to make a choice and there will be different trade-offs
depending on the situation.
What instead the audio user want, is the assurance that through the chain
we doesn't incur into any format conversion.
The way jack do it, is the easiest, limit the whole chain to just one
framerate and one format. As you might imagine this is nothing so special
itself, and have also it's own drawbacks: jack is simply unusable for any
average/consumer task. We are exactly the opposite, we can support a lot of
things in a matter of two lines of code, but can't easily enforce a certain
mode to run when we need real time audio.
I've some idea on how to fix this "by design" but I think we can discuss it
when it will be time.
--
Best Regards,
Dario
Other related posts:
