• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: IOAudioMixerEngine.cpp
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: IOAudioMixerEngine.cpp


  • Subject: Re: IOAudioMixerEngine.cpp
  • From: Jeff Moore <email@hidden>
  • Date: Wed, 7 Aug 2002 16:04:46 -0700

On Wednesday, August 7, 2002, at 02:38 PM, Nathan Aschbacher wrote:

Okay so I'm trying to clarify something.

It looks as though that IOAudioMixerEngine.cpp implements the
IOAudioFamily's main mixing function called "mixOutputSamples".

Yup. This is true. This function does the floating point mix from the HAL client's buffer into the main mix bus at the time indicated by the HAL in the call to performClentIO.

Am I to understand that this is where the CPU spends it's time mixing audio
buffers for use by the rest of the audio pipeline. If so it seems very
minimalist doing primarily 4 sequential additions and some clean-up work. I
don't understand why this function has such a high CPU burden given that it
doesn't do much and what it does do is almost the fastest operation that the
FPU can do. Which I guess is what makes me skeptical out whether or not
this is the right place to be looking to override a function to prevent the
main CPU from having to continually mix the audio buffers itself.

Doubtful. I have measured the performance of this routine and it is very fast. It takes on the order of 20-30 microseconds to mix a 128 stereo sample frames.

That said, I'm sure that there is room for improvement in the code by hand coding the assembly like we did with the float to int conversion.

If I were to re-implement this "mixOutputSamples" function I could
effectively write my own lowest level mixer using the hardware on a
dedicated audio card to reach into the sourceBuf and the MixBuf and do the
additions on the buffer segments itself.

It could be done, but it wouldn't surprise me if the bus traffic ended up washing out any gains in speed (more primary interrupts would be a bad thing). This is because you're talking about a round trip. It is possible that if the trip was one way, things might be faster.

Now there's a whole other host of
problems with data types and format that I think I'll have to deal with if
this is possible, but I'd really just first like to know if I override the
IOAudioEngine::mixOutputSamples function in the PCI audio driver will that
in effect give me early access to the audio data before the CPU starts
working to manipulate it.

That's where the mix is done for multiple clients. The mix is bypassed when there is only one client, so you won't necessarily see any improvement in the single client case.

Plus, this is the last place where the samples get touched. All the really time consuming processing is in the HAL client's DSP code, and has taken place long before performClientIO is called.

IMHO, you're going to need some pretty special hardware to outperform the CPU at doing the mix/clip operation or your going to need to plug into the signal chain at a much higher level.

--

Jeff Moore
Core Audio
Apple
_______________________________________________
coreaudio-api mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/coreaudio-api
Do not post admin requests to the list. They will be ignored.

References: 
 >IOAudioMixerEngine.cpp (From: Nathan Aschbacher <email@hidden>)

  • Prev by Date: Re: IOAudioMixerEngine.cpp
  • Next by Date: Re: Serial MIDI driver
  • Previous by thread: Calling Carbon Plugins From MachO App
  • Next by thread: Re: IOAudioMixerEngine.cpp
  • Index(es):
    • Date
    • Thread