Table of Contents
Multithreaded demodulation
By default, demodulation work for all devices is done in a single thread, which is fine in most situations. When using multiple devices (especially with high sample rates) this may saturate the CPU core on which the demodulation thread is running. This will show up as choppy audio (dropouts). Multithreaded demodulation might help in this case.
To enable it, toggle the multiple_demod_threads global boolean option:
multiple_demod_threads = true;
Note: This feature is not available when running the program on a Raspberry
Pi with GPU support enabled (ie. with PLATFORM=rpiv1 or rpiv2) - the
program will refuse to start and throw an error:
Using multiple_demod_threads not supported with BCM VideoCore for FFT.
You have to recompile the program with PLATFORM=armv7-generic to make use
this feature. See Compilation section for details.
Using multiple threads for output
By default, producing output for all channels and all devices is performed in a
single thread. This is usually fine for 1 or 2 devices. When using more devices
or many outputs it might be beneficial to split the work into multiple threads.
To enable this, toggle the multiple_output_threads global boolean option:
multiple_output_threads = true`
This will spawn a separate output thread for each configured device.
- Overview
- Installation
- Configuration essentials
- Grammar basics
- General configuration file structure
- Configuring devices
- Configuring channels
- Configuring outputs
- Configuring optional features
- Disabling configuration sections
- Changing PID file location
- Manual squelch setting
- CTCSS
- NFM deemphasis
- Audio filters in MP3 outputs
- Notch filter
- Limiting channel bandwidth
- Icecast metadata updates in scan mode
- Logging activity of scanned frequencies
- Channel usage statistics
- Tweaking sampling rate and FFT size
- Mixers
- Multithreaded operation
- Running
- Troubleshooting
- Configuring auxiliary software to work with RTLSDR-Airband