Yes, the best thing is to override the Csound sample rate with that of the iOS device. It’s the same with Cabbage plugins, the host SR is always king.
CSound Unity IOS build failure
When trying the samples I noticed I had to set the sample rate to 24000 to make they sound like on the editor.
I have an iPad Pro 12.9 inch 3rd gen with iOS 15.2.
But yeah it makes sense to still use the AudioSettings.outputSampleRate.
But I have a feeling that the outputSampleRate returned by Unity is the one set in the Unity project and not the one of the device. I hope to be wrong though!
Feel free to submit a pull request, I will try it here on my iPad.
We have to make sure that the example are sample rate agnostic. This is not so easy when we are reading functions tables. libsndfile will do resampling for opcodes like diskin but when we are reading and writing to function tables there is going to be some potential issues. What we could do is bake a resampler into the methods that write the audio files to function tables?
Exactly, so best to make sure the instruments work with any sampling rate.
Good idea.
But I noticed the issue with the Presets scene, that doesn’t use tables at all!
It’s simple FM + Filter + LFO
The problem will happen whenever Csound sets its own SR, and the host uses another. By modifying the sample rate to 24,000 you were merely trying to match the differences in them. If you simply override the sample rate so both host and Csound use the same the problem should be resolved. This is why I leave out any SR assignment in the template effect and synth .csd’s in Cabbage. We should do the same with all the example we ship with CsoundUnity. 
Yes, but be aware that if we don’t set the SR we have crashes on Android!
@David_Harris I am sending you a guide (still in the works) to setup the development project, maybe it can be useful already
Can we not do the same on Android and use the system SR?
Apparently it has to be set in the csd.
Again, happy to be wrong, but I had nightmares discovering why it was crashing only for some samples.
if we use --sample-rate= it will set the sample rate before compilation. But it is tempting to leave it as it is now, as it currently works well.
We should investigate this on several devices (Android and iOS), and see what it logs:
https://docs.unity3d.com/ScriptReference/AudioConfiguration-sampleRate.html
1 Like
I’ve sent in a pull request, it’s just a simple removal of hard coding the sample rate. Here’s a couple of things I found while testing;
Creating a fresh Unity project in 2021 / 2022 the sample rate is set by default to “0”, which they note in the docs:
If set to 0, Unity uses the sample rate of the system.
Note: This only serves as a reference only, since certain platforms allow you to change the sample rate, such as iOS or Android.
On my iPad it gets set to 24000Hz. Which to me seems like an odd choice. I tested the sequencer test scene and when I ran it on an iPad the samples played back at the 24kHz, sounding “off” as I had the editor running at the same time which was also running with the “0” setting but Unity had chosen 44.1kHz, this is on an old Mac Pro.
Changing the sr value in the csd file never changed the sample rate of the device (Mac or iPad), so as far as I know CSound isn’t taking control of the sample rate, it’s always whatever you set in the Unity Audio settings.
For me and the way I work with audio on projects this is a good thing, I wouldn’t want other samples getting mangled as the sample rate gets changed by another system, the main take away from this for me would be to alert Unity users to not leave the sample rate at 0 and set it to whatever their project needs (in my world 22,050 or 44,100 would seem like good choices), maybe something on the platforms or getting started docs page?
Since Giovanni fixed the float / double issue I haven’t had any problems with any of the builds I’ve used. I’ve tested on these devices
iPhone 11 [A2221] 15.6.1
iPad Air 2 [A1566] 14.4.1
iPhone 6 [A1586] 12.4.2
Massive thank you to you guys, it’s amazing that this project is being supported so well, I can see a lot of uses for CSound and having it run everywhere is amazing!
2 Likes
Great to hear that this project is being useful 
Btw this is an interesting discussion.
The sr and kr on the device is always the one set in the Unity project Audio Settings.
If 0 Unity defaults to the system sample rate.
But that means that it can run differently on mobile devices (that could have different sample rates, so you will have a different result from the editor), and that is the part that needs some smart decisions.
I think the focus for the next release should be giving the user the possibility to set the SR and KR individually for each CsoundUnity instance.
We have a PR waiting since ages which is strictly related, but I think this change needs some solid planning.
I want to add some dropdowns so that the user can specify whether to use the system SR, the csd file SR, or override it with a text field (also a drop down of values that make sense).
I will start once I finish creating some docs for 3.4.1
Suggestions welcome!
Am I right in thinking we have no control over the system SR from within Unity? If that is the case, I can’t see any good reason to let users set specify an SR in the .csd. I would remove all mention of SRs entirely and explain to people that the system will choose the SR, not Csound.
Technically we could change the sample rate:
https://support.unity.com/hc/en-us/articles/206205236-Changing-audio-settings-in-Unity-5-0-with-public-API
but it’s something that the user should choose.
I still think we should give the user the possibility to choose what to do for each CsoundUnity instance.
Some settings could be different when exporting for different platforms.
If the project starts to be big and complex and you want to export to desktop and mobile device, I’m sure you don’t want to tweak all your audio sources inspector. Instead we should provide a solution for this, being able to set a different sr for each platform.
If not specified, it should stay the default set in the AudioSettings, like it is now.
The pr though is showing something that can be really useful: tweaking the pitch of the audio source and the sample rate of the csd, you can save lots of cpu processing, since OnAudioFilterRead can run at a much slower pace.
Exactly, that’s why you don’t want to go near the SR at all. Leave it out completely and never think about it again. 
Until someone changes the system SR and everything gets messed up. Assigning a SR in your Csound header section is just asking for problems. It’s like letting your car choose your final destination. 
Anyway, if you wish to add those options, go for it. That’s Ok with me. But I’ll continue to advise users to never ever set the SR in the Csound header
Ok yes I understand your point
I will think more about it, adding this option can have bad consequences indeed 