[Guide] Using Soxr Resampling with Rune 0.4 Beta

Raspberry Pi related support

Re: [Guide] Using Soxr Resampling with Rune 0.4 Beta

Postby janui » 24 Oct 2017, 13:45

Hi andfor,
I'd be interested to know how you think the changes affected the sound, if at all. Positive or negative.
Finally got round to do some listening.

Tested with combinations of Pi Zero, Pi B+, generic 'Sabre' ES9023 async (50gHz) Dac, generic TI PCM5102 async Dac, PiFi dac (modified Chinese clone with TI PCM5122 chipset) and a HifiberryDac+ (with TI PCM5122 chipset).

First performance, no problems running SoXr on a Pi Zero or B+. Both have more than 50% processor headroom when MPD/SoXr are working hardest (output bitrate/depth “192000:32:2”).

Like you, most of my music is 44.1kHz, mostly with 24bit depth. Just for reference, CD encoding quality is 44.1kHz @ 16bit depth.

With the PiFi dac and the HifiberryDac+ I could not find any combinations of setting which added anything to sound quality. Less sharp, less details, muffled…

With the ‘Sabre’ also no improvement. This Chinese clone has relatively sound poor quality even without using SoXr.

The big surprise came with the cheapest Dac of the selection, a generic TI PCM5102 async Dac costing less than 5 Euro. To begin with the sound from the Dac is OK (but it’s not as good as the Dac’s using the PMC5122 chipsets but better than the ‘Sabre’). I found that using “96000:32:2” is really interesting. Details and clarity are a little less, but the soundstage opens up. Wider and seems to have more precision in the positioning of the players/instruments. For me this is now the standard setting for this Dac.

What I also found when experimenting is that the output bitrate should be set to one of the standard bit rates which the Dac supports and not a multiple of the input rate. These are generally 8, 16, 32, 44.1, 48, 96 and 192kHz. Don’t use 384kHz, it is not supported by the Pi (ALSA). I have a feeling that the Dac’s are optimised for processing these frequencies.

Setting the bitrate higher than 96kHz (e.g. 192kHz) does not seem to improve anything.

Increasing the depth to 32bits (if the Dac supports it) seems to be the key to what SoXr does to improve the soundstage. But this seems only to work when the input and output bitrate are different. It also works fine with output bitrates lower than the input, e.g. “32000:32:2”.

To summarise, SoXr changes the sound, usually negatively, unexpected soundstage improvements are possible, the effects are Dac specific, on/off changes are easy to hear, output bitrate and depth changes are extremely subtle (are they really there?) and most importantly it will be your personal preferences which will determine if it is better or not.

janui
User avatar
janui
 
Posts: 699
Joined: 20 Dec 2014, 12:55
Location: Ollanda

Re: [Guide] Using Soxr Resampling with Rune 0.4 Beta

Postby andfor » 25 Oct 2017, 17:11

Hi janui

Thanks for your detailed reply.

janui wrote:With the PiFi dac and the HifiberryDac+ I could not find any combinations of setting which added anything to sound quality. Less sharp, less details, muffled…


I think the reason I preferred soxr in combination with the Hifiberry DAC+ PRO, at least on my initial listening, is this lack of sharpness. My amp is homemade and very minimal, transparent and uncoloured. There is clarity in abundance, a little too much at times with a digital souce, which can make listening slightly uncomfortable, especially in the high-end. It's not a huge issue and is likely compounded by the room I'm listening in (lack of soft furnishings, hardwood flooring) but once you notice it....

From what I have read, soxr on VHQ setting implements a 95% bandwidth which (if I understand the term correctly) may be what is attenuating the very high end and making the sound more listenable (maybe). I plan to do some further listening with soxr disabled to see if the additional clarity is really worth sacrificing or if it's all in my mind :shock: . Maybe I'll abandon resampling and put a rug down :D

janui wrote:What I also found when experimenting is that the output bitrate should be set to one of the standard bit rates which the Dac supports and not a multiple of the input rate. These are generally 8, 16, 32, 44.1, 48, 96 and 192kHz.


Agreed. The Pro version of the Hifiberry DAC+ can handle 176.4 kHz natively, from the website:

The DAC+ Pro uses its own on-board low-jitter clock generator. To have the lowest jitter values, there are 2 different clocks on board: one for 44.1/88.2/176.4 kHz sample rates and another for 48/96/192kHz.


The thing about whole-number multiples was just something I read that seemed to make sense, and as the DAC supports it, why not? Interesting that you thought higher sample-rates added nothing. I just went with the 'higher numbers must be better' philosophy. Perhaps I'll try scaling things down a little.

I have tried the 32-bit depth, but honestly didn't like it. I might try it again taking your notes into account.

Despite my initial enthusiasm I do have reservations about resampling in general. As Frank has said elsewhere it is probably a silly idea, fidelity-wise, to alter the source audio. And my instincts tell me he is right. It is simply not possible to 'add' anything to audio that has been sampled at a particular rate by artificially chopping it up further before sending the audio onto a DAC. There is definitely not going to be any increase in fidelity. It's just implementation details. The best you can hope for is a change in sound quality that better suits your particular system.

My final experiment is going to be running soxr without altering bit-depth or sample-rate at all. This should be possible by specifying

format "*:*:*"

in mpd.conf. My theory is that this will take advantage of the soxr reduced bandwidth without the additional buggering about with the source. Using soxr instead of mpd's built in filters and whatnot. It remains to be seen whether or not I'll keep soxr as part of the system.

Thanks again for the input.

When I started out on this DIY audio journey I promised myself I wouldn't turn into one of those boring audiofool nerds chasing down every last tiny incremental audio improvement. Oh well......
User avatar
andfor
 
Posts: 57
Joined: 26 Jun 2017, 15:48
Location: Birmingham, UK

Re: [Guide] Using Soxr Resampling with Rune 0.4 Beta

Postby R101 » 14 Mar 2018, 21:25

andfor,

I tried modifying the mpd.conf file to give a 24 bit output at the original sample rate, but the actual output still remains bit-perfect.

This is the modified file:

Code: Select all
###################################
# Auto generated mpd.conf file
# please DO NOT edit it manually!
# Use RuneUI MPD config section
###################################

log_level "verbose"
log_file "/var/log/runeaudio/mpd.log"
state_file      "/var/lib/mpd/mpdstate"
zeroconf_enabled        "yes"
zeroconf_name   "runeaudio"
bind_to_address "/run/mpd.sock"
bind_to_address         "any"
port    "6600"
max_connections         "20"
user    "mpd"
group   "audio"
db_file         "/var/lib/mpd/mpd.db"
sticker_file    "/var/lib/mpd/sticker.sql"
pid_file        "/var/run/mpd/pid"
music_directory         "/mnt/MPD"
playlist_directory      "/var/lib/mpd/playlists"
follow_outside_symlinks         "yes"
follow_inside_symlinks  "yes"
auto_update     "yes"
filesystem_charset      "UTF-8"
id3v1_encoding  "UTF-8"
volume_normalization    "no"
audio_buffer_size       "2048"
buffer_before_play      "20%"
gapless_mp3_playback    "yes"
mixer_type      "disabled"

input {
        plugin  "curl"
}

decoder {
        plugin  "ffmpeg"
        enabled "yes"
}
replaygain      "off"

resampler {
plugin "soxr"
quality "very high"
}

audio_output {
        name            "JLsounds Hi-Rez Audio 2.0"
        type            "alsa"
        device          "hw:0,0"
        format          "*:24:2"
        auto_resample   "no"
        auto_format     "no"
        enabled         "yes"
}



This seems to be the relevant part of the logfile:

Code: Select all
Feb 22 14:40 : alsa_output: opened hw:0,0 type=HW
Feb 22 14:40 : alsa_output: buffer: size=16..131072 time=362..2972155
Feb 22 14:40 : alsa_output: period: size=8..65536 time=181..1486078
Feb 22 14:40 : alsa_output: default period_time = buffer_time/4 = 500000/4 = 125000
Feb 22 14:40 : alsa_output: format=S32_LE (Signed 32 bit Little Endian)
Feb 22 14:40 : alsa_output: buffer_size=22050 period_size=5513
Feb 22 14:40 : output: opened plugin=alsa name="JLsounds Hi-Rez Audio 2.0" audio_format=44100:32:2
Feb 22 14:40 : output: converting in=44100:16:2 -> f=44100:16:2 -> out=44100:32:2



I am sure I am missing something obvious, but where did that 32 bit setting come from?

Edit:

Code: Select all
access: RW_INTERLEAVED
format: S32_LE
subformat: STD
channels: 2
rate: 44100 (44100/1)
period_size: 5513
buffer_size: 22050
(Pi 3B, rAudio-1, JLS I2S over USB)
R101
 
Posts: 343
Joined: 29 Apr 2016, 16:16

Re: [Guide] Using Soxr Resampling with Rune 0.4 Beta

Postby janui » 14 Mar 2018, 22:10

Hi R101,
Your jlsounds dac uses an ak4490 chipset. This chip works only at 32bit. It seems that the alsa plug-in for the dac/chipset automatically forces this setting. It will be zero-filled if the source is lower, as you say it remains bit perfect.
janui
User avatar
janui
 
Posts: 699
Joined: 20 Dec 2014, 12:55
Location: Ollanda

Re: [Guide] Using Soxr Resampling with Rune 0.4 Beta

Postby R101 » 14 Mar 2018, 23:06

Hi Janui,

The JLS "I2S over USB" is just an interface, not a DAC. To check that it should work, I have just tested it with Audacious + SOX plugin on a laptop running Lubuntu and counted 24 data bits per frame on an oscilloscope screen.

I do not know much about drivers. Does the Arch kernel have a different one from Debian?

MP3 streams are decoded to 24 bit and play OK, but I have never checked whether the actual output is 24 bit, or truncated.
(Pi 3B, rAudio-1, JLS I2S over USB)
R101
 
Posts: 343
Joined: 29 Apr 2016, 16:16

Re: [Guide] Using Soxr Resampling with Rune 0.4 Beta

Postby janui » 15 Mar 2018, 22:39

Hi R101,
R101 wrote: Does the Arch kernel have a different one from Debian?
If Alsa is used they are the same, on some distributions Pulse is used.
In most cases the 24 bit output is actually output as 32 bit, but zero filled after 24 bits.
The details concerning the way Alsa works are complex, input and output can be specified, forcing nothing to done to the digital signal or modifying the bit rate and/or bit width. You could to look at the Alsa documentation to learn what is going on.
MP3 could therefore be unchanged or zero filled from 16 bit to make a 24 bit or 32 bit width output.
I understand that Rune is set up for bit-perfect reproduction. So if changes are made to bit width, I would expect it to be zero filled.

But going back to the SoXr discussion. SoXr does nothing unless the bit rate changes (= is forced to change) and then only when this happens in MPD (and not in Alsa). I am not sure what happens to the bit depth when a bit rate change is forced, maybe SoXr actually uses the full available bit depth.

janui
User avatar
janui
 
Posts: 699
Joined: 20 Dec 2014, 12:55
Location: Ollanda

Re: [Guide] Using Soxr Resampling with Rune 0.4 Beta

Postby R101 » 16 Mar 2018, 15:06

Hi Janui, and thanks for your interest.

There is no problem with mpd itself, or the driver. I have checked, and 24 bit sources output a 32 bit word with 24 active data bits. Likewise, 16 bit sources output a 32 bit word with 16 active data bits.

I think there might be some confusion about word length and bit depth going on. Most DACs expect a 32 bit input per channel with the data either left-justified or I2S format, which means the driver does not care about bit depth, but needs to know the sample rate. The HAT drivers look like they use 24 bit words, though.

It seems in my case that Rune ignores what I am putting in the mpd.conf file. If I modify the file and go to the mpd settings in the Rune menu, I get a warning that the file has been modified and an invitation to manually modify it or reset it to default. Neither option seems to do anything.

All my efforts to find out more about SoX have come to nothing, as the documentation is aimed at those who already know what they are doing. I have tried removing the resampler section from the conf file and leaving the format line, as mpd is supposed to have a crude internal resampler, but this did not work either.

The SoX resampler works with the Audacious player via ALSA, so I think my problem must be something to do with the way Rune-mpd interacts with SoX, or perhaps another setting has disabled all software processing?
(Pi 3B, rAudio-1, JLS I2S over USB)
R101
 
Posts: 343
Joined: 29 Apr 2016, 16:16

Re: [Guide] Using Soxr Resampling with Rune 0.4 Beta

Postby janui » 16 Mar 2018, 17:39

Hi R101,
As I said, output word length (or bit depth) is sometimes forced by alsa when the driver specifies a specific value. You were using a driver/interface from the manufacturer ‘JLsounds’, the DAC products produced by ‘JLsounds’ require a 32 bit depth (word length). I suspect that the driver/interface ‘JLsounds Hi-Rez Audio 2.0’ is forcing 32 bit.
Then again concerning SoXr: it will automatically switch in if the bit rate input vs. output is different. An example of forcing a bit rate change is as follows. add the following line in the ‘audio_output’ section of ‘/etc/mpd.conv’:
Code: Select all
format "192000:*:*"
It will then look something ike this:
Code: Select all
...
resampler {
plugin "soxr"
quality "very high"
}

audio_output {
name "snd_rpi_hifiberry_dacplus"
type "alsa"
device "hw:0,0"
format "192000:*:*"
auto_resample "no"
auto_format "no"
enabled "yes"
}
...
Generally, SoXr will do nothing if the bit rate in the format command is a ‘*’, for example:
Code: Select all
format "*:*:*"
or
format "*:32:*"
or
format "*:24:2"

In MPD, SoXr just replaces the standard built-in resampler or the ‘libsamplerate’ resampler plugin. It is not a full SoXr implementation. SoXr is considered better than ‘libsamplerate’ and is certainly better than the built-in resampler, that’s it really. The documentation is here: https://www.musicpd.org/doc/user/resampler_plugins.html
My experience of using SoX with MPD for changing the bit rate is disappointing (e.g. 44.1k to 192k), it sounds worse than the original.
janui
Edit 17-03-2018: Incorrect reference to BBC 320k radio feeds removed, thanks R101.
Last edited by janui on 17 Mar 2018, 12:06, edited 1 time in total.
User avatar
janui
 
Posts: 699
Joined: 20 Dec 2014, 12:55
Location: Ollanda

Re: [Guide] Using Soxr Resampling with Rune 0.4 Beta

Postby R101 » 16 Mar 2018, 19:09

Janui,

You are still confusing word length with bit depth. They are not the same thing. The interface does not "force 32 bit", whatever that means. A 32 bit word is what it works with, whatever the bit depth or output format. Sample rate and bit depth are nothing to do with each other. If the format is set to "*:24:*" only the bit depth should be changed (if it does not match the original).

It does not matter what I put in the mpd.conf file, I have tried various options and all are ignored.

You do not seem to understand that a 320k stream does not in any way equate to sample rate. The BBC 320k feeds are 48k AAC encoded. I wonder if you have actually looked at the outputs you are getting from SoX, rather than what you think you are getting?
(Pi 3B, rAudio-1, JLS I2S over USB)
R101
 
Posts: 343
Joined: 29 Apr 2016, 16:16

support RuneAudio Donate with PayPal

Previous

Return to Raspberry Pi

Who is online

Users browsing this forum: No registered users and 5 guests