What decides the output sample rate? I ask for 48 kHz and get 44.1

[vdatanet 1643]

Emby 4.9.5.0, hitting the HTTP API directly with curl. I'm asking rather than reporting, because two routes behave differently and I suspect at least one of them is me holding it wrong.

Route 1 — /Audio/{Id}/stream.wav with AudioSampleRate=48000. The parameter clearly does something, but not what I asked for. From the transcode log, with a 96 kHz/24 FLAC as the source:

ffmpeg … -i "…/track.flac" -map 0:0 -vn -sn -c:a:0 pcm_s16le -ar:a:0 44100 -ac:a:0 2 …

Stream #0:0: Audio: flac, 96000 Hz, stereo, s32 (24 bit) ← input

Stream #0:0: Audio: pcm_s16le …, 44100 Hz, stereo, s16 ← output

 

I asked for 48000 and the server ran -ar 44100. So the value is read — something resamples — but what I sent isn't the target.

Route 2 — /Audio/{Id}/universal with MaxSampleRate=48000. Here it looks inert:

• 96 kHz source → AAC out at 96 kHz
• 192 kHz source → AAC out at 96 kHz
• adding EnableAutoStreamCopy=false changes nothing

Why 48 kHz specifically, given that 44.1 obviously plays fine. It isn't a preference: 48 kHz is the ceiling of the device I'm feeding, which won't take anything above it. From a 96 kHz source, 48 kHz is a clean 2:1 decimation; 44.1 kHz is a non-integer resample I didn't ask for and don't need — and the server pays for it in CPU on every track. On the /universal side the effect is different: the output rate follows the source, so a library with mixed rates changes rate from one track to the next.

Three questions, and any of them closes this for me:

1. On /stream, is AudioSampleRate meant as a target, or only as a trigger to resample — and what picks 44100?
2. Is that 44100 coming from a default device profile for an unknown client? I'm sending no DeviceProfile at all, so if that's the answer, I'll send one and stop asking.
3. On /universal, is there a parameter that caps the rate, or is that route by design "never resample"?

Happy to run any variation against my server and post the resulting ffmpeg line — that's how I got this one.

ffmpeg-transcode-dd0d84ff-2858-4207-8878-41d4056868a5_1.txt

[Luke 42831]

It looks like there might be something in the server limiting it to 44100, however that is not easily removed right now. It was likely done to solve problems, so it can only be removed at a time when we're ready to deal with the consequences of making the change.