Add support to CoreAudio for changing sample rates on a stream #429
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
We've started using rtAudio in the runtime for our programming language (Cmajor), and we came across issues where the sample rate could be updated on the audio device after our application using rtaudio was up and running. This is a specific problem with MacOS, so using the CoreAudio implementation, and i've put together a fix which works for us, and so have created this pull request to see if you want to integrate this solution.
I've added an additional callback to the RtAudio class, alongside the error callback, which is called when stream properties are updated. I've kept this vague on the basis that there are multiple properties which the client may care about, so this could be extended in future.
Within the RtApiCore implementation, i've generalised an existing property change listener, which was previously used to handle device disconnect events, so that it can also handle sample rate changes. Sample rate changes are bubbled up to the class instance, and the callback is called if the sample rate has been updated.
I did consider using the error callback, either a specific error case, or a warning level, but that felt ugly and likely error prone for existing applications. This implementation will I believe have no changes of behaviour unless a callback is added to the class.
I have tried to stick to your coding standards, apologies if this is not quite right, my editor kept being helpful and doing the wrong thing :)