Update the FMOD audio system, DSP system #1032
Conversation
…OpenAL), implement concurrent sound limit, only update FMOD system once per frame
…cally update DSP parameters that were changed, rename FmodAudioManager/Sound -> FMODAudioManager/Sound
Codecov Report
@@ Coverage Diff @@
## master #1032 +/- ##
==========================================
+ Coverage 15.67% 15.76% +0.08%
==========================================
Files 3715 3742 +27
Lines 358334 357896 -438
==========================================
+ Hits 56177 56409 +232
+ Misses 302157 301487 -670
Continue to review full report at Codecov.
|
The 32-bit and 64-bit libraries have the same name. Also correct the search paths on Windows.
|
Nice work! As a heads up there was some work on getting DSPs working with OpenAl using EFX in #667. The comments contain a lot of information on trying to map the FMOD parameters to OpenAl. It would be really nice to have the DSPs not be FMOD centric (e.g., with their names and parameters). However, I also understand finding a common set of names and parameters that maps well to multiple/any audio backends is likely a fool's errand. |
|
Thanks. Yeah, I agree that it would be better to have the filters and parameters not be tied to a specific audio library. However it's not quite clear how to do that without imposing limits on the filters that can be taken advantage of in one audio library vs another. |
|
It'd be good to have a core set of filters that will work with every API. |
|
I am not sure if I like this or not, but we could do something like generic DSP classes that specialized, backend-specific DSP classes could inherit from to add additional features/parameters/etc. So, something like ChorusDSP and ChorusFmodDSP. |
panda/src/audio/config_audio.cxx
Outdated
| @@ -99,6 +114,11 @@ ConfigVariableEnum<FmodSpeakerMode> fmod_speaker_mode | |||
| PRC_DESC("Sets the speaker configuration that the FMOD sound system will use. " | |||
| "Options: raw, mono, stereo, quad, surround, 5.1 and 7.1. ")); | |||
There was a problem hiding this comment.
Does this text need "7.1.4" to be added in the list?
|
The filters could be handled similar to how the different physics libraries are organized: No generic classes, and each filter can expose the parameters that are available for their implementation. #667 mentions shortcomings of a unification, there is a tradeoff for configurability (e. g. parameters missing for the same effect) and the output may not be the same on a given input for each backend (which may not be the case depending on the used audio backend). Also, from a technical view, the question would arise why one backend would be chosen over the other when the offered features would be the same. A generalization could be done at a higher level, e. g. in |
|
I think you make a good point. The design of Panda's audio system is that the implementations for different back-ends are plug-and-play. You can just choose one and not really have to think about it, the API is the same. This works fine for basic things such as loading sounds, playing them, changing the volume, etc, but as you get into features that are specific to a particular back-end, how to expose these features under a unified API becomes a problem. For instance, FMOD has a wide variety of DSP filters and a feature-rich sound spatialization system (including geometry occlusion, reverb zones, etc). SoLoud and OpenAL have a smaller number of DSP filters with different parameters, and more primitive spatialization systems. If a Panda user wants to use FMOD for their project, they should be aware of that and should be able to take advantage of FMOD specific features. Same goes for OpenAL and theoretically SoLoud. If they can't, then there's no reason to have different options, aside from licensing. A universal API for basic sound loading and playback is fine, but I think there should be back-end specific APIs for back-end specific features. |
|
I like the idea of a high-level, common, shared API for the basic stuff with more direct access for more complicated/advanced things. |
…-core # Conflicts: # makepanda/makepanda.py
Fixes dangling pointer segfault when calling `set_active()` or `stop_all_sounds()`
|
Is there a downside of having a base audio class that implements the common API and then specific subclasses for each audio library? That seems like a pretty straightforward solution. |
…the parameters thanks to rdb)
|
Do we have two terms, |
| { | ||
| NormalizeDSP *norm_conf = DCAST(NormalizeDSP, dsp_conf); | ||
| dsp->setParameterFloat(FMOD_DSP_NORMALIZE_FADETIME, norm_conf->get_fade_time()); | ||
| dsp->setParameterFloat(FMOD_DSP_NORMALIZE_THRESHHOLD, norm_conf->get_threshold()); |
There was a problem hiding this comment.
This seems to error out
In file included from panda/src/audiotraits/fmod_audio_composite1.cxx:3:
panda/src/audiotraits/fmodAudioManager.cxx:989:30: error: use of undeclared
identifier 'FMOD_DSP_NORMALIZE_THRESHHOLD'; did you mean
'FMOD_DSP_NORMALIZE_THRESHOLD'?
dsp->setParameterFloat(FMOD_DSP_NORMALIZE_THRESHHOLD, norm_conf->g...
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
FMOD_DSP_NORMALIZE_THRESHOLD
Should be revised to FMOD_DSP_NORMALIZE_THRESHOLD?
There was a problem hiding this comment.
Is this on the latest version of the FMOD Engine? If so, it must've been renamed to that, because the version of FMOD I have has FMOD_DSP_NORMALIZE_THRESHHOLD.
There was a problem hiding this comment.
Yeah must be a latest version thing
There was a problem hiding this comment.
Can you let me know which version of API you used so I can implement this in my custom panda3d version?
|
What's the status on this PR? It would probably be really useful to have the FMOD update split out from the DSP system changes |
|
Still interested in splitting this, or should someone else take over the work? Would be nice to have the FMOD update in 1.11. |
This PR updates the FMOD audio implementation to use the modern FMOD Core API, makes general improvements and fixes to the FMOD implementation, and implements a new interface for creating and applying DSP filters.
More specific change list:
set_play_rate()on a MIDI sequence changes the tempo instead of the frequency, keeping the pitch unchangedupdate()method.Systemonce per frameset_speaker_mix()takes a single speaker ID and mix value instead of a mix value for all speakers, so speaker mix values can be changed one at a time instead of all at once.FilterPropertieswith a cleaner and more flexible system, described belowInfo about DSP system:
DSP, each with specific parameters that have documentation and can be set with Python propertiesSFXReverbDSPhas preset configurations for different types of environments, such as city, hallway, underwater, etc.At the moment the DSP filters, parameters, and units come directly from FMOD since there isn't another audio implementation that supports DSP filters. There does appear to be a mapping to SoLoud for some of the filters, however.
Let me know what you think and if there's anything that should be done differently. Thanks!
Checklist
I have done my best to ensure that…