[haiku-development] Re: Considering the audio Mixer formats
- From: "Adrien Destugues" <pulkomandy@xxxxxxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Sat, 06 Feb 2016 15:18:49 +0000
BeAPI programs usually use our encoders to obtain data in the specified
format. I think the great
majority of apps, doesn't deal with the current storage format and just get
as a pratice habit
buffers in floating point format. For example MediaPlayer do so, and right
now (look at the audio
producer) doesn't support anything than floating point.
MediaPlayer does the conversion itself already. As far as I know, most of the
time the ffmpeg decoder will output in some integer format, but it depends on
the codec used in the media file.
And this is only for things coming from decoded data, apps producing sound by
themselves are a different matter. This includes pretty much any audio app
(Sawteeth, BeSting, SynC Modular, and many more), but also any game or anything
using the Game Kit. Especially in the latter case (games and game kit), integer
audio is a lot more common than you seem to think.
At some point the conversion to float will happen anyway, as the soundcard
will accept data only in
this format. The real change would be to avoid the mixer dealing with any
other format and optimize
everything taking advantage of modern FPUs.
I may have missed something, but last time I looked at the HDA specs, the sound
card was expecting 32bit int audio, not floating point.
Solutions 2 and 3 would be both fine with me. However, regarding your
comment on things supposedly
being overly complex... please note that you're not really removing any
complexity here, you're
just moving it elsewhere.
What I see is that in pratice node tends to implement only B_AUDIO_FLOAT and
in professional word
it's just the standard. If our nodes could take care of just one format, the
entire ecosystem could
benefit of it.
The hardware uses 24 or 32 bit integer, not floats, even in professional
devices. I can see the point in working with floats to limit some problems
(saturation, etc) internally, but at the input and output you will always need
to convert to integers at some point in the chain.
If our Media Kit was restricted to just one format, it would be one more reason
to not use it and people would roll their own thing if they want to work in
another format. Basically, if you connect tzo nodes internally written to use
32bit integers (which is more than enough for good quality output), if the only
way they can communicate is using floats, they would need to resample (2
times), leading to a loss of precision because not all 32-bit integer values
can be accurately represented as floats.
The goal of the format negociation is to allow a chain of nodes to agree on
formats and minimize the number of conversions. It is not up to us to lock
everyone into a single format, especially when we already have so many things
working in other formats, including the hardware.
--
Adrien.
Other related posts:
