Is the only available builtin way of telling FMOD what samplerate to use to play a sound when initialized with NOSOUND flag just ‘setSoftwareFormat’ ?
(was looking among available DSP types, but there doesn’t seem to be one :/)
– I’m capturing decoder output via custom DSP, but the samplerate of media might differ from system output, which is a problem when NOSOUND outputtype is used as well –
Thank you !
Have you had a look at
Thank you, but I’m not sure I’m following, I should have probably described this more:
- If I play 44.1 kHz media on a 48 kHz output directly via playSound with normal/common system I get correct playback
- If I play the same with a NRT system with simplest capture DSP added which just passes its read callback buffer to the output
(it’s being played by entirely different/unity’s sytem via its pcmreadcallback - if I use readData to feed unity pcmreadcallback with NRT system the output sounds as expected, too), I get playback which is not upmixed to 48 kHz - so pitched down
(I can e.g. compensate by setting pitch of the channel to the ‘output samplerate/media’ ratio, but this is not ideal as it accumulates buffer over time)
I should have probably mentioned that I’m using setFileSystem and filesystem callback/s too to feed FMOD sound with encoded data - maybe that plays a role
(but the same file system callbacks are used with RT version, so I’m not entirely sure /)
So if anything I would need something like DSP_SETSAMPLERATE_FUNC, I am not sure how getting samplerate would help me, but maybe I’m missing something!
I hope it makes more sense now
[ just a small followup: NOSOUND, and NOSOUND_NRT systems behave the same with attached passthru DSP - i.e. they keep original media samplerate when played on 48 kHz output - so N/RT part is consistent, just NO/SOUND part seems to be ignoring output rate - which is logical in its own way : just the original question with ‘setSoftwareFormat’ stands -
seems like it will have to be done that way ~/ ]
setSoftwareFormat is always the way to set the rate that the system runs at. NoSound/WavWriter will always accept the system rate, other output plugins may request a downmix.
The NoSound/WavWriter system is running at system rate
– if I use sound.readData with it, the audio output is correct (sound is not being played)
but since no channel is being active in this case this, it’s a bit uncomfortable to work with, so I tried to add simple capture DSP to forward its output, and play it, so
– if I use minimal capture DSP to forward PCM data, the audio is downmixed to media rate on the final output
If I create a system with setSoftwareFormat with media rate instead, it works correctly with the capture DSP, too.
– hence my initial question and searching for a way to tell FMOD to upmix the signal from media rate to something else, if possible
I’m not sure this is correct/intended behavior, but if yes I was looking for ‘upmix’ DSP, which probably doesn’t exist - since because setSoftwareFormat needs to be called before init I’d have to create a new system for media if its rate differs from system rate, which is bit uncomfortable, but not impossible ) - to work with.
AH! looking at
DSP_GETSAMPLERATE_FUNC - setting rate in a callback would make sense but I see no way of using it mainly because DSP_STATE_FUNCTIONS members are not public in the c# wrapper, and manually exposing DSP_GETSAMPLERATE_FUNC and setting it to custom callback didn’t seem to do anything though (callback is not being called)
may I bump this ?
Still would like to know what’s the correct approach/behavior with this
DSP_STATE_FUNCTIONS cannot be set, but instead should be called to access them. Although there are a couple of issues in the way when trying to do this in the C# wrapper. As you mentioned the
DSP_STATE_FUNCTIONS members need to be public, and the struct itself needs to be marshaled from the DSP State.
You can then access these through the
DSP_STATE which is available in any of the DSP Callbacks.
Once you have the state you can access the
FMOD.DSP_STATE_FUNCTIONS functions = (FMOD.DSP_STATE_FUNCTIONS)Marshal.PtrToStructure(dsp_state.functions, typeof(FMOD.DSP_STATE_FUNCTIONS));
functions.getsamplerate(ref dsp_state, ref rate);
You will need to make the functions public yourself for now, but I have added a task to fix this in an upcoming release.
We have plans to improve the usability of the DSP Plugin API in C# by doing more of the Marshaling in the wrapper, but this is a longer term task.
getting the samplerate from DSP_STATE_FUNCTION is not a problem
( if a system is created with system ( e.g. 48000 ) rate, the DSP_STATE (correctly) returns 48000 )
the problem is the final audio is still being played in wrong rate - pitched down - as if upmix from 44100 (media rate) to 48000 was missing somewhere
… I just verbatim copy out the buffer in DSP_READCALLBACK
if I use readData on an opened sound with the same (48000) system, the playback is correct however
Do you want me to create reproduction project ?
Getting a reproduction would be the best bet at this point.
It’s done, I referenced this thread in the email
Thank you for having a look and for your community support
[I just hope I didn’t perform something extremely dumb ), - but since readData works correctly and systems are identical otherwise, reaching out to forums seemed like a good idea ]
Thanks very much for the repro, made things much clearer.
When you open a sound through
ReadData, it does not get added to the DSP graph and the sample rate is the sample rate of the data in the file (in this case 44100).
Whereas when using a Capture DSP, when the sound is created in FMOD it is converted to the system sample rate. At that point there isn’t a way to get the source files sample rate, and it doesn’t matter because it is now the same as the system’s. So then the issue was when you were trying to create an AudioClip with a samplerate of 44100 instead of 48000.
AHH! Brilliant ! Thank you very much for having a look !
I should have been more careful - I’m so glad that you could figure it out without problems
Thanks a TON - I can proceed now with standalone completely independent decoder, which is great !
Cheers & thanks for awesome community support !