High Resolution music dowsampling sort of?

General
1

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.


[audio]
mixer = alsamixer
output = alsasink device=hw:1,0

[alsamixer]
card = 1
control = PCM

[softwaremixer]
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


access: RW_INTERLEAVED
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:


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

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"
3

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.

4

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.

5

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.

6

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?

7

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