TOPIC:

OK. At this link you can find 1) a new stimulus file created today and an .MDAT file with three measurements made from it. One measurement is Roon to Chromecast to the SHD via Toslink. The other two are Roon to Volumio / SHD.

I did find something MAJOR in this exercise. The SHD / Volumio is also reversing the channels. I've only been showing right channel measurements since starting this thread (though left shows the same issues) and noticed that the Frequency Response was also off (I don't remember this to be the case earlier but also didn't spend much time looking at FR once I saw the wonky IRs). I have a bass dip around at 50hz on the right channel, but not on the left side which alerted me to this.

You can find the files here: drive.google.com/open?id=1UT-kIrXuS0PrN0e6-JJAZwQ5Gj8mod4e

And, just FYI, I have highly directional hybrid electrostatic speakers. As such, I take measurements at each ear position (e.g. left ear and right era). The mic was positioned where my right ear would be, hence the drop off on the ones that erroneously came out of the left speaker.

joelkarp wrote:

I did find something MAJOR in this exercise. The SHD / Volumio is also reversing the channels. I've only been showing right channel measurements since starting this thread (though left shows the same issues) and noticed that the Frequency Response was also off (I don't remember this to be the case earlier but also didn't spend much time looking at FR once I saw the wonky IRs). I have a bass dip around at 50hz on the right channel, but not on the left side which alerted me to this.

Nonsense. The SHD (Studio) doesn't actually specify left/right channels, but the routing with the factory default conditions would send input 1 to output 1 and input 2 to output 2.
There is no reversal via the LAN input. I have numerous test files recorded on my NAS that make their way into the SHD via the SHD/Volumio interface and the channels are not reversed.

You really need to start checking the veracity of your "MAJOR" issue claims before posting here.

Dave.

A clock adjustment of 1,230 ppm is needed to restore the impulse responses.



The modified mdat is at volumio.mdat

Thanks JohnM - much appreciated.

Dave - I don't know what to tell you. If we agree that SHD channel mapping is device-wide (e.g. not possible on a per input basis), then you have all the proof you need in the MDAT file I posted earlier. At least for my unit - I have no idea if this is isolated or not.

I reconnected my PC to the SHD Studio, resynced, and restarted the SHD. The reversed channel has now been restored on the LAN input with no change to Toslink (the latter has never deviated from correct L and R). I know we disagree Dave but to me this behavior is major in all facets. I did not create a L sweep so there is no way any noise should have been coming from the left channel.

I've taken new measurements in the v2 MDAT file here: drive.google.com/open?id=1UT-kIrXuS0PrN0e6-JJAZwQ5Gj8mod4e

I took two measurements of the sweep through Volumio and one through Chromecast called 'Post Reset xxx'.

To the best of recollectiuon the images I attached at the beginning of this thread were made with the sweeps playing through the correct channels. That said, per this most recent MDAT file there is no change to the IR.

Now that all are measuring the same channel the clock rate adjustment can be found more accurately as 1,225 ppm.

So gentlemen, what is the conclusion of all of this? Do I understand correctly that there could be a clock difference between Volumio and the rest of the SHD?

I have all the equipment required to make the measurement, and I would be happy to verify if my SHD studio shows the same behavior as reported here. I would need someone to share files and give a little guidance.

I have tried to test if I can hear a difference between the same file played from my laptop via the USB input or using volumio/DLNA. And there is clearly a sound difference but that is dominated by the fact the the USB input is a little softer. Hard to say much on the sound quality otherwise.

I believe you summarized the status correctly. I have a ticket still open with miniDSP and haven't heard much from them yet except for a quick acknowledgement of receiving the ticket. I provided a link to this thread and 'll keep the forum updated with any updates / progress..

I'm not entirely sure what JohnPM and john.reekie were doing to validate it but the way I identified the issue was to create and save a timing reference sweep in REW. I saved it to a USB stick and uploaded it to Roon. I then used REW and my UMIK-1 to measure the stimulus through various inputs on the SHD - e..g Roon to chromecast via toslink, Roon to Volumio (LAN), USB stick to Volumio, etc... and then compared all the Impulse Response from the various inputs.

Dear All,

Here some context for everybody. As a starting point, I'd appreciate to give the respect long time members like John/Dave/JohnPM deserve. Besides being extremely knowledgeable and very objective, they will be the first one to tell us if we messed up! Comments that they are trollers will not be accepted and I hope that we're all onboard that it's outside the T&C of this forum. When trying to fix an engineering issue, being open minded is step#1. Thanks for your understanding!

To be honest we're not sure what is the reason for that clock drift as we're not 100% sure to understand the process of measurement on REW. We'll make sure to inquire more with JohnPM to understand how the artifact shows up...

​Internally, engineers use Audio Precision units (ap.com) as our reference. In this test, we used our APX585 (www.ap.com/analyzers-accessories/apx58x/) on a stock SHD&SHDStudio running 1.038. The representation is a bit different from how REW represent it but the concept is the same.. In USB mode, file mode (wav playing from Volumio) or Roon mode, the impulses are overlaying exactly. Same happens to the response in frequency domain.

Test#1: USB audio from PC to SHD


Test#2: Volumio streaming with file stored on USB key at back of unit.


Test#3: Roon streaming


Bottom line, we're not 100% sure what is the trigger of that faulty impulse in your setup but we stand convinced that it's a measurement artifact. Few things to consider:

a) When investigating signal integrity, start simple. Stick to the electrical level (i.e. Don't bring Acoustic into the mix with a UMIK-1). With the UMIK-1+ Roon+network latency you have many complex path here with some latency which will potentially mess up the signal for a "loopback" method with a soundcard. Keep it simple is 101 debugging. Our 2cts
b) Roon is right now at beta stage. We are still undergoing Roon ready certification. We haven't heard any issues from Roon team as you imply here but maybe your setup is different. In any ways, maybe keep it simple in your chain. If you were to hear an audio quality change,it would be major, not a simple issue of clarity of the bass.. Do you agree? Maybe look at FFT?
c) If the audio were indeed to be so majorly distorted on the impulse response, we could be wrong but it would be seriously different to hear...it wouldn't be a story of feeling the audio isn't right.
Here is our Roon setup btw:






Hoping this info helps. We can't investigate much more from our side with the AP knowing all look ok and we haven't received any reports so far from a)Dirac b)Roon team c)customers that there is a major issue, but we'll make sure to keep our eye open. There is a new kernel being released on Volumio in coming few days. Roon certification process is still few weeks away and hoping that everybody is understanding that Roon is beta as it's never stated as Roon ready at this stage. That's not to imply that you're going to get a messed response as you can see from above though.. .

Happy to answer question/comments.

DevTeam

Hi DevTeam,

Many thanks for taking the time to investigate this and to extensively document your findings with your professional test rig.

Just for context, I stumbled on this not by setting out to test signal integrity but to test the efficacy of the Dirac FR, IR, and Step correction on the LAN input which is the input I intended to utilize the most given the specifics of my system architecture (e.g. I don't want to leave my TV on to stream Roon!). That said, your point (and other contributor's points) regarding simplicity and alternate paths to do this is understood - though I do wish I could understand more of the specifics on how this could be a measurement artefact. I'm not sure I quite have my arms wrapped around this yet...

In the event you are able to expend a few more cycles on this (from your post it sounds that this is unlikely though) would there also be any value in you testing your SHD / SHD Studio via REW and a UMIK-1 to see if you can at the replicate the IR issue? If you were able to validate it would that by helpful in ruling out any type of limited population with a potential bug or hw issue?

Joel