openStream() only established the TCP/TLS connection; it never checked
the HTTP status code. A 4xx/5xx response (wrong stream path, station
temporarily down, etc.) still returned a valid client handle, so
streamWhileEnabled() entered its pump loop, immediately read 0 bytes
(no body), and returned -- skipping the kReconnectDelay branch
entirely, which only fired when openStream() itself returned nullptr.
run()'s outer loop then retried immediately: a full TCP+TLS handshake
in a tight loop bounded only by network RTT, not the intended 5s
backoff -- observed live at roughly 2 attempts/second.
This mattered beyond wasted reconnects: a concurrent full FM band scan
(POST /api/tuner/scan/full, which legitimately takes 70-135s) lost its
HTTP connection outright while this loop was running, before this fix.
After adding the status-code check and routing non-2xx through the
same reconnect delay as a failed connection, the same scan completed
cleanly twice in a row under the same conditions.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
POST /api/streaming's JSON parser only accepted "http://" URLs,
rejecting any "https://" URL with invalid_json before ever attempting
a connection. Nearly every real internet radio stream today is HTTPS-
only, so this made the feature fail for essentially any station a
user would actually try.
Two changes were needed together: the parser now accepts both http://
and https://, and web_radio_stream.cpp's esp_http_client now attaches
ESP-IDF's built-in CA certificate bundle (crt_bundle_attach) so the
TLS handshake actually verifies -- CONFIG_MBEDTLS_CERTIFICATE_BUNDLE
was already enabled in sdkconfig but never wired up here. Requires
adding mbedtls to main's PRIV_REQUIRES (esp_crt_bundle.h lives there).
Confirmed live: an https:// stream URL now gets accepted by the API
and produces a real HTTP response (404, from a guessed-wrong path) --
before this fix it never reached the network at all.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
New endpoint accepts chunked, header-less, 16-bit LE stereo PCM @ 48 kHz
in the request body and writes it straight to the shared I2S sink for as
long as the connection stays open. Chosen deliberately unencoded (no
MP3/AAC/Opus decode) to keep this path as simple and low-risk as
possible — the companion app controls the encoding on its side.
Extracted the I2S TX channel that used to be owned outright by
web_radio_stream.cpp into main/esp32_i2s_sink.cpp, shared by both
producers with a simple tryAcquire()/release() exclusivity guard — web
radio streaming and a phone PCM stream would otherwise fight over the
same physical wire. web_radio_stream.cpp now acquires/releases around
each streamWhileEnabled() cycle instead of owning the channel itself.
net::PhoneStreamSink is a plain function-pointer struct (not a class
hierarchy) threaded through NetBootstrap::start() -> SetupWebServer::start()
-> HttpRouteContext, so components/net stays free of I2S driver headers;
main/phone_stream.cpp supplies the concrete functions (bound to
esp32_i2s_sink) and does the int16->ADAU 32-bit-slot conversion, batched
per chunk rather than per sample for the same reason as the web radio
stutter fix (6974095/7e65394 lineage).
Verified by build only — not confirmed live yet (board disconnected this
session); the actual phone app that will exercise this endpoint doesn't
exist yet either.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0178rASQ6ZETPMUamvpoR2KR
writeFrame() called i2s_channel_write() once per decoded PCM sample (up to
1152 separate driver calls per MP3 frame), each with its own locking/DMA
bookkeeping overhead. Now accumulates a whole frame into one buffer and
writes it in a single call.
The I2S TX channel also used the ESP-IDF default DMA config (6 descriptors
x 240 frames = ~30 ms of buffering at 48 kHz), leaving almost no headroom
against network jitter in this single-task fetch+decode+play pipeline.
Widened to 12 x 480 (~120 ms) so a brief HTTP stall doesn't immediately
starve the DMA and audibly crackle.
Both are static/architectural fixes verified by build only — not confirmed
live yet (board disconnected this session).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0178rASQ6ZETPMUamvpoR2KR
Streaming (main feature this session):
- New WebRadioConfig/WebRadioJson core types, ISecureStore-backed persistence
- New webradio::WebRadioService (thread-safe live config) + GET/POST /api/streaming
- web_radio_stream task now runtime-toggleable (no reboot), no hardcoded URL
- Content-Type diagnostic: warns clearly when a URL is a webpage, not an audio stream
Boot cleanup:
- Removed boot-time auto FM/DAB tune, auto-beep, and the (now-concluded) Si4684
crystal IBIAS/CTUN empirical sweep from main.cpp — tuning/beep are on-demand
via the existing REST API only
Web UI:
- Modernized styling (cards, gradients, toggle switches, light/dark theme)
- New Stream tab wired to /api/streaming
Fixes found via real idf.py build (not just clangd):
- Restored wrongly-removed si4684/Si4684Tuner.hpp include in main.cpp
- Fixed MP3Decode() argument types in web_radio_stream.cpp (unsigned char**/int*)
Quality-gate fixes:
- Host-test stub headers (esp_log.h, freertos/*) so TunerService.cpp's
scanForStation logging/pacing compiles for station_service_test /
integration_service_test instead of running stale binaries
- Added WifiScanner and WebRadioService manual sections; filled in missing
Doxygen docs on BluetoothService, i2s_sdata_probe, test_firmware, Bt1035At
- Ignore clangd's .cache/ index directory
Also includes prior uncommitted work carried in the tree: Wi-Fi/Bluetooth
device scan REST API and UI (WifiScanner, BT scan), SigmaStudio TCP bridge,
and the current ADAU1701 SigmaStudio DSP program export.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
micheleandClaude Sonnet 5