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

  • From: Pete Goodeve <pete.goodeve@xxxxxxxxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Sun, 7 Feb 2016 15:31:08 -0800

On Sun, Feb 07, 2016 at 08:56:21AM +0100, Adrien Destugues wrote:

On Sat, Feb 06, 2016 at 06:16:09PM -0800, Pete Goodeve wrote:

I'm sorry to say that I've never used the mixer for *anything* but driving
HDA audio output.  Simply because I've never been ABLE to!

Maybe I'm missing something basic, but I've never, for instance, been
able to connect the mixer output to anything *but* HDA.  I can use
Cortex to disconnect it from that and (apparently) reconnect it to,
say, SoundRecorder, but when I try to run I just get a "busy" error
message.

Yes, doing this from Cortex is not working currently. You could,
however, instanciate a separate mixer node from a C++ app. The Game Kit
used to do that, in order to mix its own sources and provide a single
output per app to the media kit. I removed this some years ago because
of problems with hybrid builds (instanciating a gcc2 mixer from a gcc4
compiled app didn't quite work).

Just for interest, I went back to BeOS, to see what the state of things
was there.  I don't actually have any audio there (card died long ago),
but that doesn't prevent me trying to connect other things.

And indeed, I could start SoundPlay and SoundRecorder; in Cortex
disconnect SP from the mixer and reconnect to SR.  SR would happily
record the signal from SP.  I could (usually) disconnect and reconnect
as often as i wanted and regain the transfer.  Certainly lots of bugs,
though.  Sometimes things would just lock up, and I had to use the
three-fingers.   A big restriction was that the output of the mixer
itself is not disconnectable -- permanently attached to "None Out"
in my case.  The Transport Window sort of worked (it doesn't seem
to in Haiku) to start and stop the stream, though the button state
shown didn't seem to match the actual state of the app.

What is your process for mixing then? Which other tools should we be
looking at for inspiration?
I actually do explicit mixing fairly seldom.  I just feed everything to
the mixer and do level adjustment elsewhere  The MusicWeaver Synth
module has its own volume control, and Csound has various ways of
adjusting level.  I have to go into Media and set levels initially, but
the system seems to do a pretty good job of remembering things.

I don't really have enough experience with other OSs to suggest
what we might need.  I don't like ALSA in Linux all that much, but
at least it lets you make arbitrary connections via the command line.
[If there is a GUI for it I've never come across it.]

One major limitation of our current scheme is that it is strictly
one-output-feeds-one-input.  There should at least be some way
of forking the mixer's output so that I can listen and record what
I'm hearing.  I guess that would just need a small mod to the mixer.

If we actually could chain arbitrary modules together, it would open
up a lot of opportunities. 

So IMO, the audio chain is badly in need of an overhaul!  Not sure
what my opinion on float-only is.  I can see that if you need wildly
different fader settings, float might have better characteristics,
but as it has to be integer for the soundcard, I'm not sure there'd
really be a  gain.  I should say, though, that the sources I mostly use
-- Csound and fluidsynth -- both generate float values.

A plain float has only 24-bit for the mantissa, which is less than an
int32. It makes some math simpler as you don't have to worry about
overflows/clipping: just do a bunch of operations, and when you're done,
normalize to fit the required -1:1 range.

But if what you're after is "wildly different fader settings", you would
get results just as good (or possibly even better) with int32 and making
good use of the extra 8 least significant bits.

Makes sense, I guess.

        -- Pete --

Other related posts:

  1. Home
  2. haiku-development
  3. Archive
  4. 02-2016