# DSP Plugin DataDrop Decoding **URL:** \ **Category:** FMOD Engine\ **Tags:** cpp, plugin-api\ **Created:** [June 10, 2025, 6:56pm UTC](https://qa.fmod.com/t/dsp-plugin-datadrop-decoding/23029 "2025-06-10T18:56:31Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![Capraise](https://avatars.discourse-cdn.com/v4/letter/c/41988e/32.png) [@Capraise](https://qa.fmod.com/u/Capraise)\ **Post date:** [June 10, 2025, 6:56pm UTC](https://qa.fmod.com/t/dsp-plugin-datadrop-decoding/23029/1 "2025-06-10T18:56:31Z")
I’m struggling again with my rnbo wrapper and would like to add the capability to populate buffers through the fmod studio authoring. After looking through the documentation, the best way to do that is through dspsetparamdata with the FMOD\_DSP\_PARAMETER\_DATA\_TYPE\_USER flag, I think. I have however two questions: 1. RNBO expects raw pcm values. When using the default datadrop interface it sends the whole file to the plugin, of course. Is there a clever way to decode the data received in the callback through the fmod api? (Like it’s probably done for the convolution plugin.) If not I’d have to decode this myself using a lightweight, third-party library like miniaudio. My question here is basically how this is solved in the stock convolution plugin. 2. Is it possible to retrieve the filename as this is not passed to the plugin? (Also in the convolution plugin the filename gets displayed) else I’d have to do a workaround to assign the buffers with a default name. Thanks a lot in advance! ---
**Author:** ![Capraise](https://avatars.discourse-cdn.com/v4/letter/c/41988e/32.png) [@Capraise](https://qa.fmod.com/u/Capraise)\ **Post date:** [June 11, 2025, 8:47pm UTC](https://qa.fmod.com/t/dsp-plugin-datadrop-decoding/23029/2 "2025-06-11T20:47:50Z")
Solved it for now with dr\_wav and dr\_mp3, which works really well (: The second question isn’t relevant anymore - i found a direct way internally, that works also great. ---
**Author:** ![Capraise](https://avatars.discourse-cdn.com/v4/letter/c/41988e/32.png) [@Capraise](https://qa.fmod.com/u/Capraise)\ **Post date:** [June 30, 2025, 2:35pm UTC](https://qa.fmod.com/t/dsp-plugin-datadrop-decoding/23029/3 "2025-06-30T14:35:56Z")
Also somehow related to this. When building the banks, the audio files are included raw, which is great and makes the current solution work luckily. However, it would also be great if the assets could be compressed the same way as when they’re included normally or again how it’s done with the convolution plugin, where the file-size is somehow reduced by half compared to raw WAV. It’s probably not possible as there is some proprietary code involved, or it can also very well be that I’m missing something. I appreciate any answer :). ---
**Author:** ![jeff\_fmod](https://yyz2.discourse-cdn.com/flex036/user_avatar/qa.fmod.com/jeff_fmod/32/1766_2.png) [@jeff\_fmod](https://qa.fmod.com/u/jeff_fmod)\ **Post date:** [July 1, 2025, 5:18am UTC](https://qa.fmod.com/t/dsp-plugin-datadrop-decoding/23029/4 "2025-07-01T05:18:49Z")
Our convolution reverb culls anything too quiet to make an audible difference during the convolution operation, which is what the dark grey section of the [Impulse Response Graphic](https://fmod.com/docs/2.02/studio/effect-reference.html#convolution-reverb) represents. That is a pretty targeted optimization for impulse responses, and I’m not sure we could apply it more generally to other DataDrop scenarios. Perhaps if we were to identify the dropped data as an audio file we could encode it with the rest of the audio assets instead of passing back raw bytes? ---
**Author:** ![Capraise](https://avatars.discourse-cdn.com/v4/letter/c/41988e/32.png) [@Capraise](https://qa.fmod.com/u/Capraise)\ **Post date:** [July 1, 2025, 5:47am UTC](https://qa.fmod.com/t/dsp-plugin-datadrop-decoding/23029/5 "2025-07-01T05:47:39Z")
Ah, that makes sense, thanks for the clarification. But yes, that would be phenomenal. But that would probably involve quite some changes so that the channel count and sample-rate would also be reported in the callback. One can dream (: Thanks again!