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.

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

EXPERIMENT: Don't wait on hopping mutex to improve tuner granularity. #39

Open
wizardishungry opened this issue Apr 3, 2018 · 0 comments
Labels
enhancement New feature or request good first issue Good for newcomers question Further information is requested

Comments

@wizardishungry
Copy link
Member

wizardishungry commented Apr 3, 2018

Idea for improving the number of tuning operations per second #8

The current implementation of RtlSdr_tune signals s->hop_m to let the tuning thread know to tune the SDR. Why not try moving controller_thread_fn's mutex wait out of the loop body.

safe_cond_wait(&s->hop, &s->hop_m);
  1. Instrument code to count frequency transitions per second.
  2. Pop in code that makes step call the tuner every time.
  3. Record the performance.
  4. Remove the mutex (safe_cond_signal in RtlSdr_tune & safe_cond_wait in the loop body) and record again.
  5. Report back here.

In the shipping version of the code, the tuning thread should keep track of what it tuned to and only tune again (ie call optimal_settings & rtlsdr_set_center_freq) if the frequency has changed.

If we're thinking of calling optimal_settings & rtlsdr_set_center_freq directly inside RtlSdr_tune, remember that rtlsdr_set_center_freq will hang Rack & glitch the audio if you call it as fast as you can.

@wizardishungry wizardishungry added enhancement New feature or request good first issue Good for newcomers question Further information is requested labels Apr 3, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request good first issue Good for newcomers question Further information is requested
Projects
None yet
Development

No branches or pull requests

1 participant