Why does the Snapcast Player provider forcefully downsample to 48kHz/16bit?

[rwjack]

It says so in the docs: https://www.music-assistant.io/player-support/snapcast/

Lossless audio quality with options for 48 kHz /16bits PCM

---

And I've seen it in snapserver logs:

2025-05-15 13-10-16.842 [Info] (ControlRequest) Stream.AddStream(tcp://0.0.0.0:5045?sampleformat=48000:16:2&idle_threshold=60000&name=Music Assistant - hifilivingroom)
2025-05-15 13-10-16.842 [Info] (PcmStream) PcmStream: Music Assistant - hifilivingroom, sampleFormat: 48000:16:2
2025-05-15 13-10-16.842 [Info] (TcpStream) TcpStream host: 0.0.0.0, port: 5045, is server: 1
2025-05-15 13-10-16.842 [Info] (FlacEnc) Init - compression level: 2

---

Song I'm trying to play is 88.2kHz 24bit:

---

Why can't we chose at what sample rate streams are added to Snapcast?

[OzGav]

@SantiagoSotoC

[SantiagoSotoC]

It has to be tested, attempts to support a higher bit rate did not work.

[rwjack]

That's odd. I know that I can have streams within Snapcast that do have a higher bitrate.

...
2025-05-15 13-09-59.346 [Info] (PcmStream) PcmStream: TTS, sampleFormat: 96000:24:2
2025-05-15 13-09-59.346 [Info] (TcpStream) TcpStream host: 0.0.0.0, port: 4952, is server: 1
...

Let me know if there's something I can test on my end to give you more info.

[rwjack]

Found this as related: snapcast/snapcast#1248

[rwjack]

This might be relevant: snapcast/snapcast#665 (comment)

[SantiagoSotoC]

We have tried that, but sending data in that format only sounds static.
We don't know if it's a problem with ffmpeg or snapcast.

I know that with gstreremer works but that implies a lot of changes in music assistant and adding a huge dependency for just that use case.

[rwjack]

Just to understand, the gstreamer dependency is required for MA, or for the Snapcast server? I'm using my own Snapcast server, so if it's possible I could make the change on my end?

[SantiagoSotoC]

Gstreremer would be an "audio player". You would have to modify the snapcast provider in music assistant to use gstreremer instead of ffmpeg.

You can't do it on your own, you have to modify the code.

[rwjack]

Thanks for clarifying. So it's either use GStreamer in MA, or have Snapcast fix the bug with ffmpeg. Obviously it makes more sense to have this resolved in Snapcast.

[SantiagoSotoC]

No doubt, it makes more sense to fix it in ffmpeg or snapcast, but there are several of us who tried to configure ffmpeg to be compatible with snapcast in other configurations and we could not achieve more than noise similar to static.

[SantiagoSotoC]

Search a little more ffmpeg is incompatible with the format that snapcast works, there is no way to make it work, gstreamer has a format called S24_32LE which is the one that works with snapcast. That format does not exist in ffmpeg, what does work is 32 bits and other sample rates. It could be implemented but many snapcast clients like snapweb or snapdroid do not support 32 bits. It would only work in the native linux client.

[wormhoudt]

Tried to address this here. Fingers crossed.

snapcast/snapcast#1518

[rwjack]

I read through the whole thing - and I was like: this is goated

but then I realized it's just an issue. Could you try feeding claude the issue and see what it comes up with - code wise?

[wormhoudt]

Ok. So again full disclosure, I am a lifelong developer but I havent written C or C++ in like 25 years. So while this seems like a focused simple change architecturally to me, I can't really vet the quality of the actual code. But here it is from Claude's plan mode pointed at the repo.

Proposed Code Changes for Packed s24le Support

Problem Summary

SnapCast internally represents 24-bit audio as S24_32LE (24 bits in the lower 3 bytes of a 32-bit word). This is hardcoded in common/sample_format.cpp:82-83:

if (bits_ == 24)
    sample_size_ = 4;

ffmpeg cannot output S24_32LE — it supports s24le (packed 3 bytes/sample) and s32le (4 bytes/sample), but not the 24-in-32 padded format. This is why Music Assistant's SnapCast provider is locked to 48000:16:2.

Solution Overview

Add a new opt-in URI parameter packed_s24=true that tells the stream reader to expect packed 3-byte s24le input and expand it to S24_32LE on ingest. ~38 lines of new code across 3 files, zero behavioral change when the parameter isn't set.

tcp://0.0.0.0?port=4953&sampleformat=192000:24:2&codec=flac&packed_s24=true&name=HiRes

Since AsioStream is the base class for TCP, Pipe, File, and Process streams, this automatically works for all byte-stream input types.

---

File 1: server/streamreader/pcm_stream.hpp

Add URI constant (after line 95, alongside existing constants):

static constexpr auto kUriPackedS24 = "packed_s24";

Add two protected members (after silent_chunk_ at line 266):

/// If true, input stream delivers packed 3-byte s24le samples
bool packed_s24_ = false;
/// Wire read buffer for packed s24le data (3 bytes per sample)
std::vector<char> packed_buf_;

---

File 2: server/streamreader/pcm_stream.cpp

Parse the parameter and allocate the wire buffer. Insert after line 68 (silent_chunk_ initialization):

packed_s24_ = (uri_.getQuery(kUriPackedS24, "false") == "true");
if (packed_s24_)
{
    if (sampleFormat_.bits() != 24)
    {
        LOG(WARNING, LOG_TAG) << "packed_s24 is only valid for 24-bit sample formats, ignoring\n";
        packed_s24_ = false;
    }
    else
    {
        // Wire: 3 bytes/sample, internal: 4 bytes/sample (S24_32LE)
        size_t wire_size = chunk_->getFrameCount() * sampleFormat_.channels() * 3;
        packed_buf_.resize(wire_size);
        LOG(INFO, LOG_TAG) << "Packed s24le input enabled, wire read size: " << wire_size
                           << " bytes, internal chunk size: " << chunk_->payloadSize << " bytes\n";
    }
}

---

File 3: server/streamreader/asio_stream.hpp

Two changes inside do_read():

Change 1 — Conditional read target. Replace lines 191-192:

// Before:
boost::asio::async_read(*stream_, boost::asio::buffer(chunk_->payload, chunk_->payloadSize),

// After:
char* read_buf = packed_s24_ ? packed_buf_.data() : chunk_->payload;
size_t read_size = packed_s24_ ? packed_buf_.size() : chunk_->payloadSize;
boost::asio::async_read(*stream_, boost::asio::buffer(read_buf, read_size),

Change 2 — Expand packed s24le to S24_32LE. Insert after lastException_.clear(); (line 209), before the isSilent check:

// Expand packed s24le (3 bytes/sample) to S24_32LE (4 bytes/sample, sign-extended)
if (packed_s24_)
{
    const auto samples = chunk_->getSampleCount();
    const auto* src = reinterpret_cast<const uint8_t*>(packed_buf_.data());
    auto* dst = reinterpret_cast<uint8_t*>(chunk_->payload);
    // Iterate backwards: safe for in-place expansion (dst offset >= src offset)
    for (int32_t i = static_cast<int32_t>(samples) - 1; i >= 0; --i)
    {
        const uint8_t b0 = src[i * 3 + 0]; // LSB
        const uint8_t b1 = src[i * 3 + 1];
        const uint8_t b2 = src[i * 3 + 2]; // MSB of 24-bit value
        dst[i * 4 + 0] = b0;
        dst[i * 4 + 1] = b1;
        dst[i * 4 + 2] = b2;
        dst[i * 4 + 3] = (b2 & 0x80) ? 0xFF : 0x00; // sign-extend
    }
}

---

Design Notes

• Sign extension: The 4th byte is sign-extended (0xFF for negative, 0x00 for positive). This matches what PulseAudio's PA_SAMPLE_S24_32LE expects, what the resampler's << 8 shift requires, and what makes the FLAC encoder's clip operation a no-op for valid values.
• Backward iteration: Canonical safe pattern for expand operations — dst[4*i] is always at a higher offset than src[3*i], so even with a shared buffer this would be safe.
• Nothing downstream changes: SampleFormat, all encoders (FLAC, PCM, Opus, Vorbis), all decoders, the resampler, and all client-side players see normal S24_32LE data. The conversion is fully isolated to the ingest layer.
• Performance: For worst case (192kHz stereo, 20ms chunk = 7,680 samples), the loop is trivial compared to FLAC encoding. No optimization needed.

Summary

File	Change	Lines
server/streamreader/pcm_stream.hpp	Add constant + 2 members	+3
server/streamreader/pcm_stream.cpp	Parse URI param, allocate buffer	+15
server/streamreader/asio_stream.hpp	Conditional read buffer + expansion loop	+20
Total		~38 lines

[rwjack]

okay, cool, ask it to do a PR over on the snapcast repo and link it to your issue. The choice ultimately rests on the maintainers over there, but I don't see a reason why they wouldn't accept this. 38 lines is what separates us from enjoying HiFi music on MA.

If implemented, It's cool that end users won't even need to make any snapserver changes, because MA talks to the control server directly, and by default it would be able to create a new stream with the packed_s24 parameter set to true.

[rwjack]

Y'all want to see something cool?

https://github.com/rwjack/snapcast/tree/feature/tcp-packed-s24le

snapcast/snapcast#1532

I made some manual changes to MA to test it out (I also run snapcast outside of MA):

docker exec -i <YOUR MA CONTAINER> python - <<'PY'
from pathlib import Path
import glob

base = Path(glob.glob("/app/venv/lib/python*/site-packages/music_assistant/providers/snapcast")[0])

# constants.py -> 96k/24 + S24LE
c = base / "constants.py"
s = c.read_text()
s = s.replace("content_type=ContentType.PCM_S16LE", "content_type=ContentType.PCM_S24LE")
s = s.replace("sample_rate=48000", "sample_rate=96000", 1)
s = s.replace("bit_depth=16", "bit_depth=24", 1)
c.write_text(s)

# ma_stream.py -> dynamic stream URI with packed_s24le
m = base / "ma_stream.py"
s = m.read_text()
s = s.replace("sampleformat=48000:16:2", "sampleformat=96000:24:2&packed_s24le=true")
m.write_text(s)

print("Patched:", base)
PY

docker restart <YOUR MA CONTAINER>

docker logs --tail=200 <YOUR MA CONTAINER>

[rwjack]

And to confirm on the other end, ladies and gentlemen, WE GOT EM!

[rwjack]

hi @SantiagoSotoC, can you test this out on your end and do the implementation for MA? (So I don't have to patch my MA container every time HA restarts 😓)