CSND adpcm state address hardcoded
PabloMK7 opened this issue · 6 comments
This part of the code is hardcoded to get the adpcm state from the position before the data buffer. While this may be "useful" in some case, in others where the data is being read from a file (bcwav in this case) it is not useful at all. If it wasn't hardcoded it would be possible to just load the file to memory and process the data there, however since the data buffers for different channels are next to each other, it's not possible to use that approach.
Note that while it's not recommended to use csnd to play music, it is very useful for sound effects.
CSND shouldn't be used anymore, and we don't plan adding any features to it at all.
There's no reason to choose CSND over NDSP for the purposes of playing sound effects. NDSP gives you 24 independently mixed sound channels (just like CSND), and way more control over what is played and how.
It's the only workaround if ndsp is not available.
In any case, why have something that partly works and not just remove it at all?
NDSP is basically always available. I'd say CSND is more restrictive in that regard since it's a service that almost nothing in the system has access to (except for very few system titles and definitely not actual 3DS applications).
In fact, we have previously thought about removing it but we've not taken any decision (at least yet).
It has its use cases. It's the only one which would reliably work from a different (background) process alongside a game/homebrew.
libctru's APT implementation cannot be used to write anything other than a normal application. Only applets (e.g. libapplets) use CSND. And even so, it does not look like the OP wants to write a custom applet, or a sysmodule. Everyone else should use NDSP.
What profi200 said, that's why I want to use it. DSP service is being used by the game and it's not a good idea to use it. csnd in the other hand works flawlessly.