Sunday 4 November 2018

MUSINGS: Raspberry Pi 3 B+ "Touch" Optimizations; CRAAP Settings, and the "Extremus" Filter Setting.

Okay, let's have some fun with the Raspberry Pi 3 B+ motherboard, piCorePlayer, and my little "Touch" device I recently updated. As discussed before and in the picture shown above, these days, I have the inexpensive JustBoom Digi HAT (~US$40) board attached out the back for simple S/PDIF connectivity as well as USB when I need.

Today, let's hit a few topics related to the Pi 3 B+ setup above. Some little tweaks, things to get it working well, and fooling around with a piCorePlayer/SoX filter you can try for yourself without unnecessary hype nor expense...

I. Oh CRAAP™ (Optimizations) 😀

I've been asked about this in the last couple months. Remember that I like efficiency and value. While many Pi users probably want to try overclocking to increase speed when using it as a general purpose computer, a fixed-purpose audio streamer connected over the ethernet to my server doesn't need much processing power and I like keeping things running cool with minimum stress on the power supply. So, like before, I've been playing with the parameters to find a setting that works for my needs which includes the ability to use SoX for extreme quality oversampling (which we will be discussing below).

Remember back in early 2017, I suggested we could easily underclock and undervolt the Raspberry Pi 3 with the Convoluted Rationalizations And Audiophile Perceptions (CRAAP)™ settings. Well, here's what I'm using these days with the B+:

# Archimago's CRAAP Pi 3 B+ Settings...

# Force max current to USB 0=OFF (600mA) 1=ON (1.2A)

As usual, use your favourite text editor (I like Notepad++) to change the clock speed section of the config.txt file in the root directory of your piCorePlayer SD card with the above settings:

Notice I've also set max_usb_current=0. The B+ motherboard has the ability to supply more current to USB devices - great for external hard drives and perhaps SSDs. Since I don't intend to connect peripherals with higher power needs off the Pi, keeping it lower at the 600mA level (same as the original Pi 3 B) is fine for me.

The undervolt -3 value represents a -0.075V lower for CPU and SDRAM (1.2V nominal for CPU and RAM) isn't extreme and works for me without worries of hangs or crashes with high workloads - the machine has been running 24/7 for 4+ weeks. Since the Pi 3 B+ ARM CPU can run up to 1400MHz, I'm underclocking it with a maximum speed of 1GHz but keeping the SDRAM speed at 500MHz, we have a nice 2:1 ratio (Low Power DDR2 RAM has a 2X bandwidth). The CPU will automatically reduce the speed to 600MHz anyway when load is low. If you run into stability issues with the reduced voltage, it's potentially more an issue with the undervolting of the SDRAM than the CPU since I'm keeping RAM at stock 500MHz (so maybe try over_voltage_sdram=-2 if you run into unexplained crashes/hangs).

As with the Pi 3 B, the graphics parameters have remained unchanged with a low 400MHz core speed and 300MHz GPU and low gpu_mem=16 as per default; there's little demand for speed or memory even with the Jivelite user interface installed.

Remember, even while underclocking, we still have about 2000 Dhrystone MIPS and 150 Linpack double precision MFLOPS available under the hood to play with.

For you "hardcore" tweeker Raspberry Pi 3 B+ audiophiles probably with fancy linear power supplies already :-), give this a go and let me know if it fits your system...

Also, if you have one, let me know how a CRAAP Pi feeding a Schiit DAC sounds! 😏

II. Pi 3 B+ Ethernet Back to 100Mbps

Certainly one of the major upgrades to the B+ motherboard is the faster Gigabit ethernet link (internally up to 300Mbps). Unfortunately this is through the USB bus and since the architecture is still USB 2.0, there's only so much bandwidth to go around if you have multiple USB devices hooked up such as communicating with a USB DAC while attending to the ethernet data flow.

Alas, I documented a few weeks back that I was experiencing issues with my USB DAC playback with high resolution PCM or DSD at gigabit link speed. As noted before, you might need to kick the ethernet speed back down to 100Mbps. To do this, remember to select the "Advanced" tab in piCorePlayer. Then go into the "Extensions" menu of piCorePlayer and "Load" ethtool.tcz:

Then put this parameter in the "Tweaks" tab:

sudo ethtool -s eth0 speed 100 duplex full
I have found that when I'm not using USB audio output (eg. using JustBoom Digi S/PDIF), I can keep using the default gigabit ethernet link without much problem. Remember S/PDIF is limited to 24/192 and the USB bus can just be dedicated to pulling data off the music server over gigabit ethernet.

Also, I have not been successful with upsampling to 768kHz to either the RME ADI-2 Pro FS or Oppo UDP-205 DACs even with 100Mbps ethernet. I suspect this is a USB bandwidth limitation of the Pi 3 B/B+... I guess we will need to wait for the Pi 4 or perhaps try the ODROID-C2 (which I have not done yet) for such extreme sample rates.

III. Let's go "Extremus" with the SoX digital filter!

Lastly, for some fun, now that we have even more processing speed under the hood with the B+ (not that we actually needed more, feel free to do this with the B), why not have a listen to an even more "ideal" brick wall digital filter setting?

Remember awhile back I discussed and suggested the steep intermediate phase filter?

Upsample Setting: v::4:28:95:105:45
These days, I'm using the JustBoom Digi HAT S/PDIF output more (will publish measurements in the near future). Since S/PDIF "only" goes up to 192kHz, let me then try upsampling to that rate but with some "extreme" parameters which I have lovingly called the "Extremus Filter" 😎.

Max sample rate:

Upsample Setting:

That setting provides an opportunity to listen to a very strong "brick wall filter" while still using intermediate phase setting for some pre-ring suppression for poorly bandwidth limited signals.

Doing -3.05dB attenuation provides some overhead as this is typically enough for the vast majority of situations to prevent significant intersample overload (as discussed recently). Only very "pathological" music would require more overhead. These days, I use ReplayGain which for loud music will already attenuate the volume a bit and get us away from overload and might just use -0.5dB. SoX is using 28-bit precision - that's a potential resolution of 168.57dB in the digital domain, I've seen "big numbers" like these thrown around in audiophile presentations even though in reality no DAC could ever approach this.

Setting passband_end to 99.7% is extreme and signals an intent to maintain flat frequency response up to 22kHz (21,984Hz to be more exact). With stopband_start at 100%, we're aiming to suppress all "leakage" beyond Nyquist. The price for this is a little more CPU utilization; no big deal... Even with the CRAAP underclocking, we're still maxing out at <15% and typically <6% CPU load when doing the realtime upsampling of 44.1kHz to 176.4kHz sent over S/PDIF (about the same for 48kHz --> 192kHz).

Here's what that filter looks like on the "Digital Filter Composite" (based on Juergen Reis' suggestions a number of years back) - Raspberry Pi 3 B+, JustBoom Digi --> Oppo UDP-205 DAC via TosLink --> RME ADI-2 Pro FS ADC to capture:

We can also run the RME ADI-2 Pro FS @ 384kHz sample rate to make sure no unexpected ultrasonic noise all the way to 192kHz:

That's about as "extreme" as one can get with a strong "brick wall" filter. We can compare the frequency response with the other filters available in the Oppo UDP-205 which as I've described before are actually excellent already!

Here's a snapshot of the frequency response using 16/44.1 wideband noise with 0dBFS peaks zoomed in between 18-25kHz comparing the "Extremus" filter, my previous "Goldilocks" setting, and a selection of the Oppo/ESS filters available on the UDP-205 (click image for a better look):

Now that from the perspective of a low-pass filter is what I call "ideal" performance with very clean "brick wall" characteristics compared to the filters being offered by Oppo on its machine! It redefines the words "sharp" or "fast" or "steep" when describing filters.

Impulse response? Long as expected with significant pre-ring suppression thanks to the intermediate phase setting:

Remember that there will be some phase shifting with an intermediate phase setting:

A linear phase setting results in a straight line with no phase deviation. Notice that the "Extremus" setting results in minimal phase deviation thanks to the mild intermediate phase setting. As expected, with a minimum phase filter at a reasonable 95% passband, there's quite a bit more resulting phase shift.

The above phase information was all created digitally using SoX and its filter settings. But what about measured phase characteristics while playing back audio using the Raspberry Pi 3 (USB) --> Oppo UDP-205/TEAC UD-501 --> RME ADI-2 Pro FS (sharp linear phase ADC filter) so I can examine the actual DAC filters compared to the "Extremus" setting? Let's also add the PonoPlayer on the graph to show the effect of the Ayre "Listen" filter while we're at it. Remember that this is going through DA/AD conversion at 24/44.1 rather than straight SoX digital processing as in the graph above:

That looks pretty good. We see the Oppo "Linear Phase Fast" filter staying at 0°. The "Extremus" setting results in some phase shift but not a huge amount, in fact it's essentially flat below around 18kHz (us older guy >30 years old or so likely can't even hear higher). Most of the shift occurs beyond 20kHz.

Notice that the Oppo minimum phase settings created the most phase shift, worse with the "fast" (steep) setting than the "slower", more gentle filter setting. For interest and completeness, we also see the TEAC with digital filter off (NOS mode) which also stayed flat to 20kHz. And I've also measured the Ayre "Listen" filter from the PonoPlayer which is a very slow roll-off minimum phase design with minimal phase shift as a result. The "Extremus" filter has a little more phase anomaly than the Ayre filter from 18-20kHz. Only super-duper Golden Ears will be able to hear that I suspect! 😏

But what about the dreaded pre-ringing you ask!? Should be horrible with such a steep brick-wall filter, right!? Well, let's have a look at some waveforms for comparison:

Those are bandwidth unlimited square waves passed through the digital filter with output at approximately the same level for each. Like an impulse response, this waveform will result in "ringing" in the analogue output. Using the Oppo UDP-205 as the reference device fed into the RME ADI-2 Pro FS (these were recorded at 768kHz sample rate), the top tracing is with the standard Oppo "Linear Phase Fast" filter, then "Minimum Phase Fast" filter below, and the bottom tracing the "Extremus" filter with intermediate phase.

As expected, the "Extremus" filter's intermediate phase setting will have ringing that is a combination of the linear and minimum settings. The post-ringing becomes accentuated similar to minimum phase but the amplitude is not as marked, with a little more pre-ringing just before the square wave transition, but nowhere as obvious as with the linear phase setting. IMO, it's a reasonable compromise of the two whenever your DAC runs into extremely compressed and poorly bandwidth limited "loudness war" casualty albums.

What happens when we respect the Nyquist limit (ie. no frequency content at/above 22.05kHz) with 44.1kHz samplerate material? Let's create and look at a band-limited "squarish" waveform:

Notice the odd-order harmonics as expected for these squarish-looking waves with the last component out at ~21kHz. What does this waveform look like when passed through the sharp/fast filters and the brick-walled "Extremus"?

Suddenly all that ringing is gone regardless of the type of filter used! This is a reminder that the impulse-response ringing that companies and reviewers like to drag up to differentiate DACs is not a big deal. Despite how dramatic an impulse response will look or the length of pre/post-ringing, the moment you send "legal" audio data to these digital filters, the resulting output will not be severely affected! In fact, what would be affected are things like frequency roll-off and phase deviations as noted above when the filter is not "sharp" enough and when linear phase is not used (the phase/time anomaly is why we see that extra little post-transition "beat" with the minimum phase filter squarish wave above).

Remarkable isn't it that all kinds of "golden ears" claim they can hear "pre-ringing" with linear phase filter settings with DAC playback (remember, we're not talking about DSP processing like EQ which could lead to audible pre-ringing)? This is despite the fact that ringing is really not an issue in the majority of recordings (absent in good recordings that respect the Nyquist limit), all the while, "golden ear" manufacturer and audiophile magazine writers seem not to notice potential phase shifts across the audible spectrum when using DACs with steep minimum phase filters, and seem to even prefer this. We can of course thank Meridian for this minimum phase trend, and I see their latest Meridian Ultra DAC doesn't offer anything other than various levels of minimum phase filtering. Remember that phase shifts are time domain variations. I guess Meridian doesn't really think that maintaining "time-aligned" frequencies is important ;-).

For completeness, some RightMark tests to make sure nothing significant has changed in distortion and noise level when using the 'Extremus' filter...

Slightly higher noise level and lower dynamic range due to the -3.05dB attenuation... Otherwise SoX upsampling looks/sounds great as expected.

Finally, anyone worried about jitter still?

Just the usual Oppo UDP-205 low level sidebands as previously discussed. No evidence that getting the Raspberry Pi to do some upsampling for us creates any jitter abnormality at all. This again should be no surprise for anyone following along as we've discussed jitter many times (not to mention of course the fact that jitter is likely inaudible unless very extreme).

I've been listening to this filter setting for the last while either just by itself or when I send music through Brutefir for digital correction with the appropriate room measurements of course. Sounds great IMO. Tight frequencies throughout. The "transparent" sound allowing everything up to ~22kHz through to the DAC with no compromises - no early roll-off, no "leakage" into ultrasonic frequencies. Remember that transparency has its "price". There is no romantic "euphonia" here; if the album is harsh, shrill, unnatural, distorted, that's what you're going to hear. That's what high-fidelity is about in my opinion. This is the antithesis of the NOS DAC.

Remember to manage expectations when thinking and talking about the effect of digital filters. There's all kinds of hoopla out there about digital filtering having almost magical qualities - whether we're talking very precise filters like the "Extremus" (consider Chord's Hugo M Scaler which I suspect is similar to this "Extremus" setting at linear phase - have a listen to piCorePlayer setting: "v::3.05:28:99.7:100:50"), or weak filters like Ayre's "Listen" and MQA.

Other than a significant effect on frequency roll-off that can be audible, my opinion is that the effect is subtle at best. By the way, if anyone has one of the Chord DACs, I'd be very curious how steep their filters are compared to "Extremus"!

Always remember, there's no need to freak out about the length of the impulse responses or extent of pre-ringing unless you're frequently listening to low quality poorly bandwidth limited music! And IMO, no audiophile who values high fidelity should be evaluating high quality audio gear with just poor quality albums anyway.

Give this a try if you're running piCorePlayer. Doesn't cost anything and it'll give you a taste of what a high quality essentially "ideal" brick-wall filter sounds like. After all, the processing power is there for you to use - a Pi has plenty of computational power to get this done at least to 24/192.

Notice that I'm only doing 4x oversampling here to 176.4/192kHz from 44.1/48kHz (and of course only 2x oversampling if playing 88.2/96kHz). Some have asked whether this makes a difference compared to going even higher like 352.8/384+kHz. IMO, no, there will be no difference unless your DAC somehow plays 176.4/192kHz material in an inferior fashion compared to even higher sample rates like 352.8/384kHz (or vice versa). Once we upsample with a good filter to even 2x (eg. 44.1 --> 88.2kHz), we're looking at bandwidth outside the audible range already... Sure, maybe 384kHz upsampling turns off any further internal interpolation in the DAC compared to 192kHz. So what? I have seen/heard no such issue in measurements and listening tests.

Finally, regardless of what filtering you use, if you're further upsampling 88/96kHz+ material, it really does not matter what algorithm because even if the algorithm creates significant imaging artifacts, phase shifts or somewhat early high-frequency roll-off, the effect would be more than likely beyond 20kHz. As such, it's of course no surprise when John Atkinson wrote in the Meridian Ultra DAC review: "I drove myself crazy trying to hear any differences between the Ultra DAC's three upsampling reconstruction filters with this 192kHz-sampled album". What did he expect to hear when trying different filter settings using a 24/192 album?! Even a 20-year old golden ear would not be able to hear a difference! Please, subjectivist/pseudo-objective audiophiles, think before writing this stuff!!!

Kudos and a shout out to the folks who made piCorePlayer. Great work on such as stable product with all kinds of potential for the audiophile tweaker.


Enough fun for a blog post I hope ;-). This article turned out to me much longer than I had anticipated when I started writing...

Over the week that I was writing this post (early October before going overseas) and off-and-on while traveling, I was listening to Casey Abrams' Put A Spell on You (Chesky, DR14). Nice recording if you're into light pop/vocal/mild jazz. I've always liked CCR's "Have You Ever Seen The Rain" which is covered on this album quite well, I thought. While these days, I almost never buy hi-res music since it makes no meaningful difference to the vast majority of recordings, for the occasional album like this I will when recommended by a friend. The dynamic range is great and clearly it was recorded and produced in high-resolution when pulled up and examined in an audio editor.

It was recorded in binaural and the liner notes say that the Mytek ADC was used. The binaural effect is excellent on headphones with 3D spatial envelopment. Bass extension is excellent on "Take The A Train". It also sounds great through the "Dolby Atmos" computer speakers of my Huawei Matebook X Pro though lacking a bit of bass on account of the small speakers.

However as a binaural recording, the music does sound different with my main speaker system. I see web pages and research papers looking at implementing crosstalk cancellation to convert binaural recordings for standard stereo loudspeakers (anyone vouch for a good binaural --> standard stereo DSP?). Without conversion I find binaural recordings do tend to have a "suck out" of sorts in the center of the soundstage when played with conventional speakers. This is overall a nice production with great attention to detail making this a good "male vocal" album to use for showing off a high fidelity headphone system. So, if you want to support "real hi-res", this is a good one to consider.

A friend recently also recommended a good "female country vocal" album - Mary Gauthier's Between Daylight and Dark (2007). Sounds great on my system.

Hope you're all enjoying the music...


  1. Arch, phantastic post again. Also nice to see that the ADI-2 Pro improves all the mesurements and graphs significantly.

    Question: you recorded the bandwidth unlimited square waves at 768 kHz sample rate. How did you do this and what was used to show them? That looks like your usual Audition screens, but Audition can't do 768 - or?

    Binaural recording - wouldn't the Crossfeed in the ADI-2 Pro compensate that effect for speaker playback? The Width setting (a bit more mono) might also help.

    1. Hi Tech,
      Yes, I still use Audition CS6 to work on and display the 768kHz audio data. No playback or recording with the software but you can still do some data manipulation like cut, paste, amplify, etc...

      Hmmm, yes, I haven't tied the crossfeed on the ADI-2 Pro yet. Was thinking it would be nice to have some kind of process to "remaster" the binaural audio to a standard stereo version of the album for playback...

  2. Great post, really. Nice experiment with extreme filtering - Chord DACs no longer neccessary :-) I am not sure that I will follow that path but as a proof of concept - amazing.
    I also upsample to 176.4/192 kHz. That is more than enough. With competent DAC, filtering at that rate cannot be done better and file size is still manageable. Only on mobile I upsample to 88.2/96 kHz only.

    1. Agree.

      Even though I can use the Pi to upsample to 352.8/384kHz, I really don't see the point. At some threshold even the "big numbers" folks must realize that it's just not needed any more given perceptual limitations.

      Likewise all this talk about filters and such. We could do all kinds of stuff to tweak the parameters. An even "more linear" intermediate phase setting to reduce phase shift a little more... Allow the filter to be less steep because we don't need 22kHz of passband... The potential is endless for those who want to play with this stuff :-).

      The bottom line for me is that we can show here and now using freely available software and an inexpensive computing platform that an essentially perfect digital upsampler can be implemented for anyone to try.

      Of course it's subjective for each of us whether this kind of high-precision "ideal" brick wall filter is preferred or "felt" to be preferred. All I can say is that I like the "hi-fi" sound so the 'Extremus' works for me :-).

    2. HI Archimago, thanks for answer. Yes your digital upsampler is an example what can be done. If Nyquist and Shannon lived today, They would be happy to see it, because they imagined such a filter only theoretically :-)
      Yes "x4" upsampling is optimal.
      Maybe in the future also other kind of filters than FIR available in SoX will be used for upsampling. But for today the filter with great name "Extremus" serves as an example what can be done digitally. And that is awesome, I think that this blog reached new heigths with this post!

  3. Hi Archi

    Great Article again. It shows, that with prober recording and mastering, we can get „perfect sound“ without fiddling on oversampling filters etc.

    I mean, if everyone would master the level, not to have sample overs and intersample overs, than every DAC chip would have no problems with intersample overs.

    If everyone would record in 96 kHz with a prober low pass filter, so no „illegal signal” is captured (only signal below 48 kHz) and with prober low pass filter when mastering,

    then every linear phase filter in every DAC chip would see only „legal signals” and would have no group delay (perfect timing) and no ringing will occur (neither pre nor post).

    So this would be a perfect world for every audio friend and we would not need to fiddle around with crazy compromise filter coefficients or the intersample overs.


    1. Yes. If 96 kHz be used everywhere, we would not have to deal with 44.1 filtering which will always be tight. Even 48 kHz would be good enough. By the way, a lot of of signal above 20.5 kHz is in some cases partly aliased from ADC or resampled filtering, which usually filters when using 44.1 kHz with some alias ….
      44.1 is the huge relict of CD Audio. Sufficient, but I would prefer that the industry switches to 48/96 KHz.

    2. To clarify - I meant above the source 44.1 file which we use for playback - if it is from common ADCs then a lot of them alias with internal filters, and when created with downsampling it depends on the setting that was used in the studio.
      Aliasing when upsampling depends on playback settins, upsampler settings and/or DAc filter setting.

    3. Agree...

      Alas, 44.1kHz will be with us till the end of our lifetimes :-|. So I guess it's best to just accept it. As Juergen says, the best we can do is encourage music studios to do the right thing:

      - Don't make albums too loud to the point of distortion, clipping, massive intersample overs.
      - Ensure the Nyquist limit is respected.
      - For the love of all that is holy, give us some decent dynamic range to enjoy. :-)

      All things considered, the above would be more important to me than whether it's 44.1kHz or 96+kHz.

    4. Yes 44.1 will be here … forever. A lot of great music was recorded in it natively, by the way.
      On the other hand, many studios today work at 48 kHz or 96 kHz, and then create 16/44.1 for distribution. Here I see the potential for improvement - they should offer the tracks at native sample rate (48/96) they used. And of course 24 bit, given, as you write, they utilize the dynamic range they really, really should :-)

    5. This is a sad point ... I have downsampled to 16/48 some material that was @ 24/96, and I was unable to hear the difference. Difference I could hear when listening (with Qobuz) the 16/44.1 version.
      I guess the reason is in the more complex Mathematics needed to go from 96KHz to 44.1KHz, /vs the simpler (it's a decimation) mechanism to be used when going from 96KHz to 48KHz.
      16/48 should become the standard for the streaming @ "CD Quality".

    6. Well, 16/48 could be the new and for foreseeable future final standard for streaming and conversions. For buying music in FLAC files 24/48 is more appropriate since it needn't be dithered.
      44.1 suffers both from tight filtering (primarily) and uneven conversion from studio rates 48/96 kHz. I have also an (unproven) theory that uneven conversion can cause more timing errors, since any irregularities of ADC clock (jitter or simply inherent variations) could propagate with uneven conversion worse than with even conversion.
      On the other hand when we convert once from 24/96 or 24/48 to 16/44.1 with great converter such as SoX or Resampler the result should be high quality still, no need to worry much.

  4. Here's some filter measurements of chord DAC :)

    1. So Extremus is even more steep that Chord, right? :-)

    2. Hmmm... Thanks for the link verifonix. Indeed the Extremus does appear to be steeper looking at that transition band graph of the Chord Mojo. Of course we're looking at a few hundred hertz of transition way up above 21kHz. Probably "diamond ears" needed for this level of acuity!

      Alas, the Mojo has a mere 26,000 taps filter. Wondering if anyone has tried out the DAVE with it's He-Man-like 164,000 taps or the Hugo M Scaler with its gargantuan 1,015,808 taps!!!

      Bigger the number the better, baby ;-).

  5. Hi,
    having replaced my old Audiolab 8200CD with an Audiolab M-DAC+ I can finally comment on this topic.
    1. When upsampling 44.1(88.2) to 352.8 or 48.0(96.0) to 384.0 (with JRiver 24 and SOX) I can say I hear some difference, but I'm unable to characterize it; so in a "blind" test I would be unable to remember what to hear to differentiate.
    2. When converting from PCM to DSD128 (I could go to DSD256 but my i3 seems to be unable to do it properly) I hear the same differences that everyone hears (and that you discussed in a old blog): wider and deeper soundstage, more "analog" sound.
    I'm listening now to "Lighthouse" of David Crosby and it's a real pleasure.


    1. Nice Teodoro, looks like a good upgrade!

      Well, now you can have a listen and play with the filters and figure out for yourself what the talk is about ;-).

      I agree, PCM upsampling especially with standard filter parameters isn't going to yield massive changes in the sound. NOS and filters like the Ayre Listen (eg. PonoPlayer) would be more audible as they result in some attenuation in the higher frequencies.

      Yes, DSD is a different beast but typically it's hard to do volume-controlled testing with the same DAC. My impression was that DSD64 had more of an "analogue" sound due to the fact that it's noisier and perhaps the low-pass filtering in many DACs could have an effect. Once I upsample to DSD128 and DSD256, I'm not sure I hear as much subjective difference compared to a clean hi-res PCM signal.

      These days, I like my DSP room correction which makes a much bigger difference than PCM/DSD or the DAC's filter setting. I suppose I could still take the DSP'ed audio and convert to DSD like running JRiver in my sound room as a rendering device... Alas, that would require a more powerful machine in my sound room rather than the cool-running, inexpensive Pi streamer.

      Thanks for the Crosby "Lighthouse" suggestion! I'll have to check this one out.

    2. I made one more experiment. This time with the album “Live from The Minster” by “The Lake Poets”, that can be freely downloaded from
      There are two versions: a 16/44.1 and a 24/96. Guessing that both come from the same master, I tried to compare them.
      As far as my old (but trained) ears can say, the HiRes version gives you (only) the feeling of being in a church.
      Then, using SOX, I down-sampled the 24/96 version to 16/48. No complicated Mathematics is involved: only truncation and decimation.
      What happens then? I was unable to distinguish the 16/48 version from the 24/96 version.
      Then I did something more: since I have a DSD capable DAC (Audiolab M-DAC+) I converted the 16/48 version on the fly to DSD128 with JRiver Media Center 24.
      Then … I jumped on my seat!
      But, for the moment I don’t want to say what I heard differently …
      When my guitar teacher went for my weekly lesson, I asked to him to make the same experiment. Without saying him what to expect.
      16/44.1, 24/96, then 16/48 converted to DSD128.
      He said immediately: “Uh!”, jumping on the seat.
      So we shared the (independent) experiences: wider soundstage, more “air” around the singer and its guitar, voice coming from the body, larger guitar (it’s a Gibson Jumbo, indeed).
      I know perfectly that Mathematics would say that we shared hallucinations, but … really?

    3. Cool experiment Teodoro :-).

      Indeed it's more than just mathematics I think! If you can, would be interesting to run some measurements of your DAC and see what happens with DSD conversion on that device.

    4. Well, probably that dac plays DSD better than it does upsampling from 16/48. Actually on many DACs the upsampling process is unfortunately not very good, especially filtering from 44.1/48 kHz.
      Also as it was discussed in another thread here intersample peaks make difference. Worth usually to decrease volume 1-3 dB before upsampling.

    5. Sorry, but I cannot do any measurement.

  6. You talk about minimum face filters and such, and I can see differences with the post ringing... Is this something that I need to look out for when I am making a system?

    Does something like the MiniDSP handle this in the correct way, or will I be missing out on something?

    1. Steven(s?),
      Don't worry about it :-).

      This is minutiae that you can play with *after* getting the system up and running. If you're running the miniDSP for room correction with Dirac, etc... Then that will have leaps and bounds more of an effect than tweaks like the digital filtering.

  7. (minimum phase filters, not "face.")

  8. Hi Archi

    What kind of low pass filter have you used to create the bandwidth limited square wave?


    1. Hi Juergen,
      I'm sure there's a way to automate the process, but for the "square looking" waves above, I started with a 1.00227kHz unlimited square wave and used an audio editor to (painstakingly) edit the transition points to remove the ringing as shown when interpolated using Audition...

  9. Not that anyone asked, but the network problem is almost certainly a case of buffer-bloat.

    It's counter-intuitive that faster network rates decrease performance, but buffer-bloat is counter-intuitive. :)

    What's happening is the server is sending huge slugs of packets to the RPi at one moment in time. Then the server sits idle and waits for the RPi to work-off the backlog. Once the RPi works off the backlog, the RPi sends it's 'ACK' and the server slams it again with a huge slug of packets. It's NOT that the RPi is running out of data. It's that the time it takes to handle the big slugs of packets causes the music to hiccup.

    If the server sent smaller gulps of packets, the RPi would take less time to move them from the network stack to the buffer for the DAC port and there would be no hiccup.

    There's a few ways to fix it, and you've definitely hit on the easiest one. ;) By lowering the ethernet rate you're throttling the server so it sends packets in more manageable gulps.

    Bad analogy, but good visual: it's like racing from red-light to red-light down a street where if you go a steady 25 MPH, you'll hit all the lights green.

    For folks interested, another long-winded Canadian blogger (is there any other kind? -- I kid, I kid.) has an excellent write-up of the phenomenon, along with more elegant (read: complicated) solutions.

    Of note, wifi is notorious for use of large buffers, which is why folks often complain about poor results with wifi.

    Of further note, if you download the entire song and playback from local memory, the problem necessarily goes away since the network will be out of the loop, which is another thing I've seen some especially under-informed OCD types recommend.

    Of final note, I suspect, based on all its good reviews and that this is an annoying enough of a problem with an obvious enough solution to anyone sharp and paying attention, that ROON has rolled buffer management logic into their product -- it will do it's own throttling irrespective of the network's capabilities so as not to overwhelm the client.

    Cheers. Hope you've enjoyed the digression. :)

    1. "I have found that when I'm not using USB audio output (eg. using JustBoom Digi S/PDIF), I can keep using the default gigabit ethernet link without much problem"

      I hadn't noticed that originally. I'm going to recant slightly in that this is not what is typically considered buffer bloat.

      It is a resource contention issue stemming from the same root-cause as buffer bloat -- inherent bursty nature of TCP combined with oversized buffers induces latency -- but buffer bloat refers to when data is being passed from one network domain to another (even if you define network domain loosely to be a DAC port).

      This is more of a quality-of-service type of problem. Two entities with different types of usage have to share a resource.

    2. Thanks for the comment Allan!

      Yeah, that Canadian blogger guy is long winded :-).

      Interesting discussion and I think I'll need to spend some time playing with the buffer mechanism for piCorePlayer and the Linux parameters of the virtual box time permitting!

  10. This comment has been removed by the author.

  11. Hi, do you know which software does the resampling and brickwall filterering?
    After listening to a Cord Qute DAC, I would like to try this on my hifiberry (currently mpd+brutefir). Is it sox?

  12. This comment has been removed by the author.

  13. If the last component of the square wave was at 21kHz at stated, there's little wonder there was no ringing. Ringing occurs when energy above the passband is present. Since your passband is to nearly 22kHz ...

    Note doing a spectrum analysis of a track might reveal no HF energy but still certain events (e.g. cymbal hit) when analysed in isolation can reveal HF energy.

    I've read that sharp phase shifts are actually more likely to be audible than a smooth phase shift up to a reasonable absolute limit.

    Finally, the fact artefacts are above 20kHz does not imply they're inaudible - thanks to distortion especially in tweeters. Otherwise, there would be no need to worry about imaging either (but we do).

    Finally, finally, an intermediate phase filter in SoX like -p 25 has no visible pre-ringing at all, yet half the phase distortion. I would love to see -p 25 measurements! Thanks. (I consider this the baseline rather than -p 0.)

  14. Hi Archimago - Last weekend I built a RPi 3 B+ with the Touch Display, running piCorePlayer, powered by a 10 Ah battery pack (2.1 A out) and simply using the mini-jack analog out on the RPi board. When applying your latest CRAAP settings I hear click noise in the analog output. I returned to default settings and it went away. Any comments? Will this issue go away when I get my DAC board installed? (What's the difference?)

  15. Scroll down to near the bottom of this forum for some interesting pics on how to physically disable the USB ports on the Pi. Supposedly enhances performance. A resistor and capacitor on a bare USB board does the job. Takes about 10 minutes.

  16. A bit late to the game, but I'm impressed. I have a Pi 3B+ w/ piCorePlayer feeding a Bifrost 2 DAC via USB (no DAC HAT) and it is working fantastically. The CRAAP settings are working very well and results in a cooler RPi overall. I have a Pi4 B on its way and hoping there will be some recommended tweaks (maybe an addedndum).

    Keep up the AWESOME work!!!

  17. Hi, also late to the game and a newbie with ssh and pasting code for fixes and adjustments. I'd love to try this, just must ask a dumb question about any lines starting with a hashtag #. These are just explanations, not actually what should be entered right? So for my 3B+ it should be:

    # Archimago's CRAAP Pi 3 B+ Settings...

    # Force max current to USB 0=OFF (600mA) 1=ON (1.2A)

    Do I add just add "max_usb_current=0" right after "over_voltage_sdram=-3" and then proceed with yes, enter, sudo reboot? Or must I apply spaces?
    Or do I actually enter everything listed?


  18. Really appreciate the work here. Couple of questions:
    1) Interaction between DSP settings for Dac in Picoreplayer and the Extremus upsampling settings - I did not realise the Dac (same chip as Hifiberry DAC that you wrote a post on relating to DSP filters) applied these filters. Reading your post made me aware of this. Now I would like to better understand how the DSP filters in Picoreplayer for this DAC interact with the upsampling parameters in SOX (based on your Extremus setting). I am upsampling to max 176,400 or 192,000.
    2) Related to the above, I recently learnt how I can upload to LMS in Picoreplayer a custom convert file to allow for parametric EQ to be applied (usage case is headphones but later I would like to also do Room EQ etc for speakers). I am wondering about the interaction between the SOX upsampling and the custom.conf file (also SOX). In particular, which is applied first? I understand that parametric Eqs are normally developed for a specific sample rate (e.g., AutoEQ provides parametric EQ settings for a default range of sample rates). If I have a parametric EQ designed say for 48000 sample rate and the Extremus settings upsample to 192000, does the upsampling also take care of changes to the parametric EQ, or do I need to adjust the EQ to 192,000 sample rate (in my case I have 176,400 and 192,000 so if I had to adjust the EQ settings, I would not know how to make it work for both upsampling frequencies). Hope the question is clear. Thanks again.

  19. to add, here is an extract of my custom.conf for LMS (edited mac address etc). I am worring if the sox part before the equaliser settings is somehow conflicting with my upsampling extremus settings? is there duplication here or conflicts, especially this part -q -t wav - -b 24 -t flac :

    # EQ setting for xxx
    flc flc * 00:xxxxxxxxxxx
    # FT:{START=--skip=%t}U:{END=--until=%v}
    [flac] -dcs $START$ $END$ -- $FILE$ | [sox] -q -t wav - -b 24 -t flac - gain -3.5 bass +7.5 115 0.71q equalizer 1100 2.0q -1.2 treble +7.0 1300 0.71q equalizer 3050 3.0q -1.8 equalizer 5000 4.0q -5.1 equalizer 8100 6.0q -4.6 treble -3.8 10000 0.71q

  20. And for completeness sake my squeezelite command for the particular player to which the EQ in the custom.conf file is applied.
    ./squeezelite -o pipewire -a 100:4:32:1 -r 176400,192000 -R v::3.05:28:99.7:100:45 -v -C 5

    Not sure if the -W flag should be added or not at the end. When using the CPO Transcoder helper which did upsampling on the LMS server I had to add -W to the squeezelite command.