Audible Performance Differences in HiFiBerry Digi+ and Digi+ Pro/Digi2

[changer]

I need another tip: The DSP in pCP Alsamixer is not very reliable and is causing issues. This is why I would like to transfer my preferred setting of the 15 band equalizer into my Hypex amp, where I have 7 PEQs for room correction that I already use. Given that I find out the filter Q of my 15 band equalizer, is where I can calculate the sum of two sets of PEQs and get one set of PEQ that contains both?

 

[mdsimon2]

Short answer is you need to define a target curve based on the combined response of pCP and Hypex DSP.

I prefer direct measurement as it eliminates variables with Q interpretation. You can measure the response at your amplifier output using the setup described in this thread -> https://www.diyaudio.com/community/threads/howto-distortion-measurements-with-rew.338511/. You already have a 2i2 so the only additional thing you need is a dummy load if you do not have one already.

You could probably also model your Hypex filters in REW or VituixCAD and save that as .frd file, then apply the pCP filters (assuming you know the Q definition) to generate the target curve.

Once you have the target curve defined in a .frd file you can use REW or VituixCAD to automatically design filters to meet your target curve.

The other advantage of direct measurement is you can check the result with another measurement when you are done to verify it works as expected.

Michael

 

[changer]

You could probably also model your Hypex filters in REW or VituixCAD and save that as .frd file, then apply the pCP filters (assuming you know the Q definition) to generate the target curve.

This is the way to go in my case. But I will consider the other measurement sometime in the future, when I have capacities to extend my audio hobby into new depths.

 

[changer]

Because I do not want to handle too many returns and equipment changes, and HiFiBerry yesterday anounced customers could hope for a redesigned HAT around April, I will probably wait and use the Digi+ Transformer as a temporary solution. I thought I had found a fix when I switched the Pi3s supply to the Pi4, but it was only wishful thinking. The Digi+ Transformer is inferior to the Digi+ Pro, this is my finding. I hope the revised Digi+ Pro/Digi2 will deliver the same performance. I will write a follow up when I have it.

 

[Tangband]

Im sure that the difference you hear is dependent on the two optimized clocks in digi + pro.

The two boards locks almost the same , except for the clocks .

 

[changer]

I tend to agree, it cannot be for obvious reasons galvanic isolation, and I tried as good as I can to ensure it is neither the base, the Pi itself, nor different power supplies. This at least is good news, because if it is the clocks which produce the surplus in spacial perception, I will get this very nice rendition back in about two months.

And never use alsamixer, it isn’t any good.

 

[rwortman]

Static test signals dont measure timing errors ( jitter ) and are very different from real music.

Static test signals are used to test for jitter all the time. As far as the performance of a digital transport is concerned, music, test signal, it makes no difference. It’s passing digital data and whether that data describes a single sine wave or twenty it still does the same thing.

 

[FrantzM]

Digital signals are RF.
Further, digital transports with spdif is dependent of the clock noise from the source and the ability of the dac to recreate the clock . Asychronuos USB is better .
Spdif outputs can have different qualitys - if the RF noise from the transport is big, its harder for the dac to recreate the clock.
Resampling can also be bad for sound, if done in a bad way.

A bad digital transport has less details in high freq and sound will be less dynamic In the whole music spectra. Listening to music will be boring and not fun.

Care to show us a few exemples? Please? Not anecdotes. Measurements showing us how audible these issues are. We are talking about a hat for the Raspberry Pi here. BTW.
Thanks in advance

 

[Tangband]

Care to show us a few exemples? Please? Not anecdotes. Measurements showing us how audible these issues are. We are talking about a hat for the Raspberry Pi here. BTW.
Thanks in advance

You never gonna hear a difference, because you have already made up your mind about this. You have to listen and compare for yourself . If you cant hear a difference between different digital sources with spdif, then fine for you.

 

[BDWoody]

You never gonna hear a difference, because you have already made up your mind about this. You have to listen and compare for yourself . If you cant hear a difference between different digital sources with spdif, then fine for you.

It's about any actual evidence from anyone, ever.

Have that? Haven't seen it.

Claims aren't evidence.

 

[FrantzM]

You never gonna hear a difference, because you have already made up your mind about this. You have to listen and compare for yourself . If you cant hear a difference between different digital sources with spdif, then fine for you.

It's not about me. Please bring up measurements to backup your assertions. Measurements. And, while you are it, their audibility.

Peace.

 

[changer]

The people insisting on measurements usually behave as if the person who shares his experience owes the audience a set of data. This is messed up. If they want data, they must provide the means, send the technical equipment which is necessary and if the process is complex, a well structured manual. Also, if it is a lot of work to acquire data, they must think about some reimbursement. Despite that there are guys around with formal training in i. e. engineering, there is also many who have not worked with advanced measuring tools. This means it is a project on its own to comply. I probably wouldn’t do it, it is a lot of work and one must be knowledgeable to make the measurements correctly, so that the data can show something. I have other things to do besides my hobby.

The local HiFi repair I trust asks 70 Euro per hour. Hopefully in April, when HiFiBerry has its new board ready, I will once again be in the possession of two of such boards. If the newly revised board to my ears still sounds better than the Digi+ Transformer, I can offer you to bring both boards to the HiFi workshop, if you come up for the expenses. If not, please lower your expectations and live with the fact that people hear differences with bit perfect digital transports.

 

[mdsimon2]

I think the focus on measurements is probably a bit misguided when there is no evidence of an audible difference in controlled listening tests.

So far the playbook seems to be...

1) Claim a clear audible difference in digital transports without controlled listening tests
2) Attribute supposed audible difference to clocking differences / jitter with no measurements to support this assessment
3) Spread misinformation based on 1 and 2 to mislead others

I really do not have an issue with people having subjective opinions but I think presenting them as truth to others without any sort of supporting evidence is pointless.

Michael

 

[BDWoody]

If not, please lower your expectations and live with the fact that people hear differences with bit perfect digital transports.

Sure, when they don't use proper controls.

Claims aren't evidence.

People waste money chasing bogus claims all the time. This place isn't like most other audio fora. To hear differences would be extraordinary, so might require actual evidence to be taken seriously...at least here where it isn't all a big unknowable mystery that science hasn't caught up to yet... Science has caught up to digital transports.

 

[Tangband]

Sure, when they don't use proper controls.

Claims aren't evidence.

People waste money chasing bogus claims all the time. This place isn't like most other audio fora. To hear differences would be extraordinary, so might require actual evidence to be taken seriously...at least here where it isn't all a big unknowable mystery that science hasn't caught up to yet... Science has caught up to digital transports.

This is an example of a really bad digital transport with spdif , the chromecast audio. The measurements are made by amirm.
In this case, there is probably also badly executed SRC involved with bad results using the googles own browser.
This streamer has a SINAD of 35. It can not be called hifi. This is clearly audible.

Using Roon, the result is much better.

So, this is proof that problems sometimes exist in the digital domain .

Read more here :

Review and Measurements of Chromecast Audio Digital Output

This is a review and detailed measurements of Google Chromecast Audio digital output. The Chromecast is a tiny dongle that allows one to "cast" (stream) audio and video to a remote device. The audio version as the name implies, foregoes the video functionality and provides audio streaming...

www.audiosciencereview.com

 

[changer]

Claims aren't evidence.

People waste money chasing bogus claims all the time.

Both assertions are true, I wouldn’t argue.

But I cannot value the sort of members which in the name of their belief loose all restrains and begin to behave as if the other users had any obligation towards them, they don’t. In the end, even if we are collected here in the search for technical explanations of good sound, there are but people on the other side. Some zealots of their belief think that they can expect audio magazine level of proofs, despite for the most amateurs, it is even very hard to produce a simple set of clean linear distortion measurements. I find this people to be lacking manners.

One more thing: if people waste their money because on their imagination of audio, I am sorry that they did not put the effort that I have invested to build myself a proper base of judgement. They could have. If they rather spend their money for a good feeling, this is their way of learning to listen and finally find out that it might have been bollocks to invest a sum. They are responsible for their purse and their desires, and I am not their teacher.

From this thread they can learn a lot btw: an average guy asks the forum for advice, no one can really give it, he orders the equipment and finds the inconvenient choice the better option, yet postpones his decision and lives with the slightly less exciting for three four months because this seems more pragmatic. If they read closely, they will see that between the options which where debated, only their own comparison of the equipment will probably give them an answer. This is a very straight up thing, it is called experimentation and lies at the foundation of modern sciences. Everyone should do it once in a while.

 

[Tangband]

Another streamer with badly executed spdif in.

 

[mdsimon2]

This is an example of a really bad digital transport with spdif , the chromecast audio. The measurements are made by amirm.
In this case, there is probably also badly executed SRC involved with bad results using the googles own browser.
This streamer has a SINAD of 35. It can not be called hifi. This is clearly audible.

View attachment 189782
Using Roon, the result is much better.

So, this is proof that problems sometimes exist in the digital domain .

Read more here :

Review and Measurements of Chromecast Audio Digital Output

This is a review and detailed measurements of Google Chromecast Audio digital output. The Chromecast is a tiny dongle that allows one to "cast" (stream) audio and video to a remote device. The audio version as the name implies, foregoes the video functionality and provides audio streaming...

www.audiosciencereview.com

So your proof is that software can cause issues with bad resampling? I don't think that is up for debate, ALSA resampling will also give you terrible results on Linux if you let it (I've measured it). Doesn't prove anything in the current debate.

Another streamer with badly executed spdif in.

View attachment 189785

This is exactly what a measurement looks like for a DAC that cannot achieve clock sync. If you've ever made a measurement with a DAC that has multiple clocking options and not used the right one for your source (i.e. using SPDIF in while using internal clock) this is what it will look like. Oh, and this will be audible by clicks / pops / glitches, they might be faint but definitely audible.

Is your hypothesis that the Hifiberry Digi+ with a single clock will show anything like those results?

Michael

 

[Tangband]

So your proof is that software can cause issues with bad resampling? I don't think that is up for debate, ALSA resampling will also give you terrible results on Linux if you let it (I've measured it). Doesn't prove anything in the current debate.



This is exactly what a measurement looks like for a DAC that cannot achieve clock sync. If you've ever made a measurement with a DAC that has multiple clocking options and not used the right one for your source (i.e. using SPDIF in while using internal clock) this is what it will look like. Oh, and this will be audible by clicks / pops / glitches, they might be faint but definitely audible.

Is your hypothesis that the Hifiberry Digi+ with a single clock will show anything like those results?

Michael

I dont know, it might be, especially if the digit+ clock is optimised for 48 kHz and most music is 44,1 kHz. - Im just saying that there is sometimes differences and that the differences is smaller or bigger with different dacs .

And yes, in this modern days the software doing SRC and volume is sometimes terrible.

 

[mdsimon2]

I just so happen to have a Hifiberry Digi+ I/O, the one with only one 27 MHz oscillator (oh no, the horror!) and no isolation transformer.

I made some quick measurements of it at 88.2 kHz and 96 kHz sample rates using the optical input of a MOTU Ultralite Mk5, looks text book perfect to me for 24 bit data. Tests were done with the REW signal generator on the Pi with the MOTU connected to Mac mini running another instance of REW as REW in Linux would not recognize any inputs beyond the first 2 (TOSLINK is input 13/14).

When I have some free time tomorrow I can run some measurements of the DAC output with a Cosmos ADC to see if there is any difference between USB input and TOSLINK from the Digi+ I/O.

88.2 kHz, 1 kHz tone, 0 dBFS, -145 dB THD+N

88.2 kHz, J Test

96 kHz, 1 kHz tone, 0 dBFS, -145 dB THD+N

96 kHz, J Test

Maybe the DAC output tests will show something different but this is about as excellent as it can be from a digital transport standpoint.

Michael