Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

AU Mac Cracks and Pops if you change sample rate #662

Closed
baconpaul opened this issue Feb 25, 2019 · 0 comments
Closed

AU Mac Cracks and Pops if you change sample rate #662

baconpaul opened this issue Feb 25, 2019 · 0 comments
Labels
DSP Issues and feature requests related to sound generation in the synth
Milestone
1.6.0

Comments

@baconpaul
Copy link
Collaborator

Investigating #660 I played around with AU Mac in Logic after @davephillips reported cracking in bitwig linux at 48k jack.

If I change audio sample rate back and forth between 44.1 and 48 in a session enough times, eventually surge will get wedged into a state where it pops only, or pops plus plays.

My original debugging thought it was the timepos hardcoded to 44.1 in the ::Render of aulayer but fixing that doesn't help. (PR to fix that inbound though).

So something in the internal state of the oscillators, envelopes, or wavetables is wrong when we reset sample rate on mac. Sometimes. Not always though. Which is super fun.

My notes

  1. All the sample rates are globals in SurgeStorage.cpp externed in SurgeStorage.h
  2. setSampleRate sets them all then inits the wavetables. A printf shows that the at least the env_linear wave table does init correctly under this change
  3. The 44100 hard coded in unitcoversion.h is not it; that's just used for display in the cm_lforate section of CNumberField where it is matched by another hardcoded 44100.
  4. Not clear this is daves issue, but it seems likely. But lets keep a separate issue for mac debug and test of the switch open also.
@baconpaul baconpaul added the DSP Issues and feature requests related to sound generation in the synth label Feb 25, 2019
baconpaul added a commit to baconpaul/surge that referenced this issue Feb 25, 2019
@baconpaul
Don't hardcode timepos sample rate to 44100 in AU
30145c6 
AU had a hard coded 44100. Rather than use that, cache the last sample
rate we saw when reset and use it to advance timepos in the sample block.
Related to surge-synthesizer#662.
@baconpaul baconpaul mentioned this issue Feb 25, 2019
Merged
baconpaul added a commit that referenced this issue Feb 26, 2019
@baconpaul
Don't hardcode timepos sample rate to 44100 in AU (#664)
121ba9e 
AU had a hard coded 44100. Rather than use that, cache the last sample
rate we saw when reset and use it to advance timepos in the sample block.
Related to #662.
@baconpaul baconpaul added this to the 1.6.0 milestone Feb 26, 2019
@baconpaul baconpaul modified the milestone: 1.6.0 Mar 2, 2019
@esaruoho esaruoho mentioned this issue Mar 26, 2019
Closed
baconpaul added a commit to baconpaul/surge that referenced this issue Apr 1, 2019
@baconpaul
Initialize All Filters
07de83c 
In two places, filters were using uninitialized memory at
creation. In some cases, for some values, in some instances,
this would create a large "pop" as the filter went unstable
with crazy coefficients or history values.

In my headless simulator, without these initialization changes
we get a click and pop within the first 100 instances. With them
there is no unstable run within 20,000 instances.

In theory this
Closes surge-synthesizer#790
Closes surge-synthesizer#753
Closes surge-synthesizer#699
Closes surge-synthesizer#698
Closes surge-synthesizer#662
Closes surge-synthesizer#660
baconpaul added a commit to baconpaul/surge that referenced this issue Jul 10, 2019
@baconpaul
Don't hardcode timepos sample rate to 44100 in AU (surge-synthesizer#664
222f7b6 
)

AU had a hard coded 44100. Rather than use that, cache the last sample
rate we saw when reset and use it to advance timepos in the sample block.
Related to surge-synthesizer#662.

Former-commit-id: df958bfbd6f241548bdafd7f403c86ce6316267a [formerly 121ba9e]
Former-commit-id: c56dc64c9d367cd76bde5d73368592b61462cf36
Former-commit-id: 8f5760dc2cf03911c9fc8fb37a8117b83e16751b
baconpaul added a commit to baconpaul/surge that referenced this issue Jul 10, 2019
@baconpaul
Initialize All Filters
6cb581b 
In two places, filters were using uninitialized memory at
creation. In some cases, for some values, in some instances,
this would create a large "pop" as the filter went unstable
with crazy coefficients or history values.

In my headless simulator, without these initialization changes
we get a click and pop within the first 100 instances. With them
there is no unstable run within 20,000 instances.

In theory this
Closes surge-synthesizer#790
Closes surge-synthesizer#753
Closes surge-synthesizer#699
Closes surge-synthesizer#698
Closes surge-synthesizer#662
Closes surge-synthesizer#660


Former-commit-id: 8e8307f5065169c6651215a1832bdd3cd315b403 [formerly 506ec57]
Former-commit-id: f6fd0b5ce82ee51975a9e12079ff44d6d788405f
Former-commit-id: 025d2371d9ed79ddc4da4540211633bbc416ccbd
@bobobo199733 bobobo199733 mentioned this issue Mar 5, 2024
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
DSP Issues and feature requests related to sound generation in the synth
Projects
None yet
Milestone
1.6.0
Development

No branches or pull requests
1 participant
@baconpaul