High Resolution music dowsampling sort of?

After switching from vanilla MPD, I’m hitting a bit of a learning curve when trying to get the sound “bit-perfect.”

I have some high resolution audio files that are 24 bit 96khz. I normally play the music through mpd using alsa. So I’ve tried to mimic this as close as possible in mopidy. My usb dac is located at card 1, device 0.

mixer = alsamixer
output = alsasink device=hw:1,0

card = 1
control = PCM

enabled = false

I’m not exactly sure what mopidy is doing. It’s not really downsampling. It’s more like playing 96khz file at 44.1khz, so about half speed. This is what I get when I test the output using:
cat /proc/asound/card1/pcm0p/sub0/hw_params

format: S24_3LE
subformat: STD
channels: 2
rate: 44100 (44100/1)
period_size: 441
buffer_size: 8820

As you can see, the rate is showing 44100.

It should look like this:

format: S24_3LE
subformat: STD
channels: 2
rate: 96000 (96000/1)
period_size: 12000
buffer_size: 48000

Normally what should happen is that the playbin element from GStreamer should detect that the decoded audio and the alsasink are compatible and automatically pass-through. Why this is not happening I have no idea.

One way of testing this in isolation from the rest of mopidy is the following line, which is essentially equivalent to how playback is done:

gst-launch-0.10 playbin2 uri=file:///path/to/your/flac audio-sink="alsasink device=hw:1,0"

I just tested it out using the command you listed and the sample rate is the same as through mopidy, 44100.

I did get these messages though:

Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
Pipeline is PREROLLED ...
Setting pipeline to PLAYING ...
New clock: GstAudioSinkClock

Does the GstAudioSinkClock have something to do with it?

Also my high res files are ALAC rather than FLAC if that makes any difference.

The clock has nothing to do with, it is simply for synchronizing when you have multiple outputs, for instance audio/video. ALAC vs FLAC shouldn’t matter. If nothing else this tells me this a GStreamer issue, which doesn’t directly help you fix the issue, but might give you a better chance of finding an answer by searching.

You can also run @adamcik’s command with the very verbose option (-vvvvv). On my system, for a 88.2KHz ALAC it shows:
caps = audio/x-alac, codec_data=(buffer)00000024616c616300000000000010000018280a0e0200ff00002e6b001eebe100015888, samplesize=(int)24, rate=(int)22664, channels=(int)2
I don’t pretend to know anything about these files but you can see the correct rate as 0x15888 in the codec_data field. Shame that it’s not using it.

Compared to an 88.2KHz FLAC:
caps = audio/x-flac, channels=(int)2, framed=(boolean)true, rate=(int)88200, streamheader=(buffer)< 7f464c414301000004664c61430000002210001000000acb00105d158883700006baa87bd26be099c8afd61a59c0a34e908388, 04000028200000007265666572656e6365206c6962464c414320312e312e3420323030373032313300000000, 03000012000000000000000000000000000000001000, 8100200000 .... >

So, as @adamcik says it sure looks like a gstreamer 0.10 ALAC bug. Running a similar command (using playbin instead of playbin2) with gstreamer 1.0 shows they are doing things a bit differently (libav vs ffmpeg??) and the correct rate for the ALAC file is shown:
caps = audio/x-alac, codec_data=(buffer)00000024616c616300000000000010000018280a0e0200ff00002e6b001eebe100015888, samplesize=(int)24, rate=(int)88200, channels=(int)2

The fact that 1.0 gets it right doesn’t help you at all, it’s just kind of interesting.

Thank you @adamcik and @kingosticks

I converted one of my alac files to flac and tested the playback. And yes, the sample rate is now correctly showing.

Is there a reason mopidy uses gstreamer 0.1 instead of 1.0?

See https://github.com/mopidy/mopidy/issues/225