Evaluating FMOD -- some basic questions

FMOD Engine
,
1

Hi friends,

Some quick questions as we are evaluating FMOD. Its price model seems reasonable, and it’s nice to feel a professional community here in the forums. My background is realtime A/V and 3D graphics for iOS, OSX, and Windows for decades now.

  1. With FMOD’s scope and time on the pond, I presume it’s as mature and optimized as it’s going to get in terms of efficiency. Our usage will be only playing a single channel at a time (a long stream or file) with occasional crossover (4 channels max) and basically not use Studio. And so we are looking for power efficiency, reliable and proper (QAed) background audio support on mobile, and decoder ruggedness. For example, we can appreciate ffmpeg for being a tank – but on mobile it has the fuel economy of a tank.

  2. When looking at a DSP with output only (for audio visualization purposes), it’s not clear how to optimize for that. I didn’t see anything in the docs and the example just copies the PCM. I would think setting the number of DSP output channels to 0 or something would be understood by the DSP engine to just send the same audio buffer to the next DSP in the pipeline. These days the unnecessary copying is less of an issue, but we’re not in the habit of wasting cycles or memory bandwidth but on mobile this adds up.

  3. One item to confirm is that the read-only PCM monitor (the DSP described above) will occur in the case on iOS when playing an AAC stream. With Mathew’s help, I understand that FMOD turns over the stream for hardware processing on iOS. So the question is, will a PCM monitor still work in that scenario? I still have PTSD from how opaque AVFoundation is to deal with and how many gotchas are in that thing. Separately, we would likely adding aac codec support for non-iOS platforms.

  4. Most of our backend is a Go (golang) runtime in an embedded dylib that pushes a UI to Unity (and hopefully Unreal someday). So we’re looking at potentially doing audio control from Go (rather than from Unity). So if we were to invest the time and effort to do proper Go bindings around FMOD (via cgo), is this something anyone else might be interested in? Given FMOD’s maturity and position, Go bindings seems like real value, esp considering that runner ups on Go (portAudio, ffmpeg) fall short of commercial grade. If you’ve never gotten into Go, then as a C and C++ person of maaany years, I only have positive things to say.

Thanks,
Drew

2
  1. FMOD is quite efficient, but we are always re-evaluating based on user feedback and often find ways to make fast code even faster.
  2. To optimize a DSP for no output, return FMOD_ERR_DSP_SILENCE from the process callback.
  3. We use hardware on mobile to decode AAC, but we do get access to the final result, so you can monitor it just the same as any other codec.
  4. This is more a question for the community, but so far I’ve seen limited demand.
1 Like
3

Thanks boss!

4
  1. To optimize a DSP for no output, return FMOD_ERR_DSP_SILENCE from the process callback.

Sorry, I should have been clearer.

Not looking to inject silence into the pipeline, just looking to save the DSP from copying from the input buf to the output buf for an audio monitor only (and does not alter any of the audio). Something that tells the DSP to pass the DSP input to the next dsp (rather than expect the audio to be copied).

Point being to prevent unnecessary memory copying.

5

Ah apologies, I understand the question now. We don’t have an optimization to do what you are asking at present, you’d need to copy the inbuffer to the outbuffer for that. We have plans to improve the DSP API in a future major version of Studio, so I’ve added that to the list.

6

Lovely Mathew, thank you.

Looks like FMOD is our path based on the above and the FMOD pricing model is equitable.

We’d been using AVPro and regard it as a wonderful suite for AV playback in-app, but (efficient) multi-platform background audio support and audio monitors are required for what we’re doing. Looking forward showing the FMOD crew and the community here what we’re making as we approach alpha in the summer.

Best,
Drew