Skip to content

Fix DAB+ audio sample rate issues using ffmpeg resampling#419

Open
dom-robinson wants to merge 7 commits intojketterl:developfrom
dom-robinson:feature/dab-audio-fix
Open

Fix DAB+ audio sample rate issues using ffmpeg resampling#419
dom-robinson wants to merge 7 commits intojketterl:developfrom
dom-robinson:feature/dab-audio-fix

Conversation

@dom-robinson
Copy link
Copy Markdown

Hi folks - I was frustrated at the inabilyt to listen to 32k (and other non-48kHz DAB stations (the majority of DAB+ stations).

I fixed my local system and figure i would share the solution as a PR incase it is of wider value.

Description
This PR addresses an issue where DAB+ audio streams with sample rates other than 48kHz (common with 32kHz DAB+ broadcasts) would play at the incorrect speed ("chipmunk effect") in the web client, as OpenWebRX expects a consistent 48kHz input.

Changes
Pipeline Update (owrx/dab/dablin.py): Modified the dablin command execution to pipe its output through ffmpeg. This forces an explicit resample to 48kHz (f32le) before passing the data to the OpenWebRX audio chain.

Dependencies (docker/scripts/install-dependencies.sh): Added sox to the dependency list (useful for audio debugging/transcoding) and relies on ffmpeg for the runtime pipeline (which is typically available or easily added).

Evaluation
Verified on a Docker deployment (Raspberry Pi / ARM64). Stations that previously played with speed artifacts now play correctly.

Related Issues
Fixes audio synchronization for non-48kHz DAB stations.

DevBench added 6 commits February 3, 2026 22:59
…l#419)

- owrx/dab/dablin.py: pipe dablin output through ffmpeg to resample to 48kHz
- docker/scripts/install-dependencies.sh: add sox to static packages
- Dockerfile.hotfix: optional hotfix image with dablin from source + ffmpeg/sox

Upstream PR: jketterl#419
…nput fix

- Default: dablin -w so ffmpeg reads rate and channels from WAV header;
  all DAB+ services (24/32/48 kHz, mono/stereo) play at correct speed.
- Fallback: OPENWEBRX_DAB_USE_WAV=0 uses PCM path with
  OPENWEBRX_DAB_INPUT_RATE (24000|32000|48000).
- Fix: treat dablin output as stereo (-ac 2); mono caused consistently
  slow playback.
- Optional OPENWEBRX_DAB_CAPTURE_RAW=1 for raw PCM capture (PCM path).
- README-FORK.md: document env vars and behaviour.
@dom-robinson
Copy link
Copy Markdown
Author

Improvement (tested on dom-robinson/openwebrx feature/dab-audio-fix):

  1. All sample rates (24/32/48 kHz) – Default is now dablin -w (WAV output) so ffmpeg reads sample rate and channel count from the WAV header. No configuration needed; 24 kHz, 32 kHz, and 48 kHz DAB+ services all play at the correct speed.

  2. Stereo input – Treating dablin output as stereo (-ac 2) in the PCM path fixed consistently slow playback that occurred when using mono. (If your deployment uses the PCM path, use -ac 2 for the ffmpeg input.)

  3. Fallback – If WAV causes issues in some environments, set OPENWEBRX_DAB_USE_WAV=0 and use OPENWEBRX_DAB_INPUT_RATE=24000|32000|48000 as before. Optional OPENWEBRX_DAB_CAPTURE_RAW=1 tees raw PCM for analysis.

  4. Larger buffermbuffer increased to 4 MB to reduce dropouts.

Changes are in dom-robinson/openwebrx branch feature/dab-audio-fix (commit 5206e5b and later). Happy to open a follow-up PR against jketterl/openwebrx with these improvements if that would be useful.

- waterfall_add: call add_canvas() before canvas_context check so first canvas is created and waterfall can start
- Keep defensive null checks for divlog, scale_setup, init_canvas_container, networkSpeedMeasurement, add_canvas (for missing DOM)
@jketterl
Copy link
Copy Markdown
Owner

Sorry, but I'm not merging this in its current state, for multiple reasons.

First of all, what's with all the frontend changes? You're not explaining any of them, they should not be necessary for this.

Second, the dependency management is all over the place. You're installing sox but using ffmpeg. You haven't set up a dependency test nor a dependency correlation for DAB.

And lastly, csdr has its own resampler (based on libresample) so there should be no need to pull in an external dependency just for resampling.

@dom-robinson
Copy link
Copy Markdown
Author

Fair enough.

Sox was left over from an initial experiment.

Front end tweaks were simply smoothing behaviour.

csdr wasn't working.

But I admit this was a feature hack in. Perhaps put it down to a feature request to fix the sample rate support.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants