[haiku-development] Re: Considering the audio Mixer formats
- From: Dario Casalinuovo <b.vitruvio@xxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Sat, 6 Feb 2016 16:28:46 +0100
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.
I'm sure to have seen our multi audio node to accept only floating point
audio BTW.
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.
Ok, then I'm going to be convinced that we can't live with it. But this
automatically imply that professional audio will need much more specific
support.
Best Regards,
Dario
On Sat, Feb 6, 2016 at 4:18 PM, Adrien Destugues <pulkomandy@xxxxxxxxxxxxx>
wrote:
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.
--
Saluti,
Dario
« Nullius addictus iurare in verba magistri, quo me cumque rapit tempestas,
deferor hospes. »
Other related posts:
