Fix/io inits #438
Open
Fix/io inits #438
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The ::begin() functions previously had various orderings of setting up update responsibility, ISR, DMA and hardware. This fix tries to ensure that even if they execute slowly, e.g. out of FLASHMEM, or are interrupted, they will always execute and give consistent results.
Doesn't have update responsibility, but does use DMA etc.
It was on the wrong branch...
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
As noted on this forum thread, from about here on, there can potentially be an issue with poor ordering of initialisation of audio I/O objects. The thread specifically mentioned the PT8211_2 object, and a change "sneaked in" in PR #436 seems to work OK.
I've been through most of the relevant objects and made them consistent, with the best (I believe) ordering being:
There's no obvious reason why this should be any worse than the previous cases, what I've managed to test to date suggests nothing is broken, and it ought to serve to reduce instances of audio hardware mysteriously not working occasionally.
One caveat - I haven't managed to implement this for the AudioOutputPWM object, because I don't understand the code! I've PMed the most recent author @MarkTillotson for help.