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);
Instrument code to count frequency transitions per second.
Pop in code that makes step call the tuner every time.
Record the performance.
Remove the mutex (safe_cond_signal in RtlSdr_tune & safe_cond_wait in the loop body) and record again.
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.
Idea for improving the number of tuning operations per second #8
The current implementation of
RtlSdr_tunesignalss->hop_mto let the tuning thread know to tune the SDR. Why not trymoving controller_thread_fn's mutex wait out of the loop body.stepcall the tuner every time.safe_cond_signalin RtlSdr_tune &safe_cond_waitin the loop body) and record again.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_freqdirectly insideRtlSdr_tune, remember that rtlsdr_set_center_freq will hang Rack & glitch the audio if you call it as fast as you can.