Blue or red pill?

[adamdea]

13 hours ago, mansr said:

I'm surprised nobody has questioned what the meaning of the word "is" is.

Abbreviation for Islamic State.

[Summit]

I would like to go back and discuss DAC isolation a bit more. I have for many month now evaluated some different ferrites* on some of my digital cables and gained considerably better sound with some of them, but also SQ degradation with others.

 

The clamp-on core ferrites I have tried was put on my LAN and SPDIF cable. In my audio system ferrets which filtering mostly between 25-150 MHz (I belive) sounds much better than these that there filtering much higher on 1-2 GHz.     

 

Ferrite are propably the simplest and least expensive types of interference filters and can in my experience enhance SQ significantly. I have a DAC with GI on all inputs that are feed by an USB to SPDIF converter that is feed by an ultraRendu. One would maybe think that no EMC, EMI or RFI could pass all those buffers, reclocking and regenerating devices, but to my ear it’s clear that those noise are only reduced and not eliminated.

 

I have gained best result (so far) with 6 of these ferrets on my SPDIF cable if anyone like to try.  

 

https://www.electrokit.com/ferrit-kabelklamma-o10-512-5mm.48209

file:///C:/Users/Abbe/Downloads/7427122S%20(2).pdf

 

*Clamp-on core ferrites are made to prevent EMC, EMI and RFI disruption. Ferrite are used as a passive low-pass filter by converting EMC and RF energy to heat.

[manisandher]

21 minutes ago, Summit said:

I would like to go back and discuss DAC isolation a bit more.

 

This is from the Pacific Microsonics Model Two (with AES3 I/O) manual:

 

"Ground loops can occur between the grounds of digital and analog signal cables when they are connected together by a single device that has both digital and analog signal connections. If not properly isolated, noise currents on grounds have the potential to seriously degrade A to D and D to A converter performance."

 

"The AES Ground Isolators [provided with the Model Two] consist of a number of turns of precision 110 Ohm balanced, shielded cable fed through multiple ferrite cores, each having a different selected permeability. The cable is terminated with XLR-3 connectors. This construction provides 160 mH of inductive filtering effective over a very wide range of frequencies. A 100 Ohm resistor is also placed in series with the pin 1 ground connection, providing further isolation."

 

I spent a lot of time playing around with AES cables, AES isolators, AES voltages, etc when I had the PM2 - all of them affected the sound*... without changing any bits, of course.

 

I'm not sure how susceptible USB is to these sorts of things. The design of the Phasure Lush cable suggests to me that it is.

 

*I suppose someone will suggest that the PM Model Two was "badly designed" too.

 

Mani.

[manisandher]

I've got some insights as to what's happening with the 10kHz plots.

 

Here's Mans's plot for the Altmann DAC:

 

And here's mine for the Altmann DAC:

 

 

Here's Mans's plot for the Phasure DAC:

 

 

And here's mine for the Phasure DAC:

 

 

The important thing here is that the 10kHz test tones used were different in each case:

- for the Altmann, a 24/44.1 file was used

- for the Phasure, a 24/176.4 file was used

 

Redoing the Phasure plot, but using the same file as the Altmann, we get:

 

 

The 100Hz spikes are still there, though at a much lower level now. I'm not sure what's causing them, but it seems it's nothing to do with my AC mains (or indeed planes flying overhead ).

 

Mani.

[manisandher]

Here are non-averaged plots for the Tascam ADC:

 

With interconnects attached:

 

 

With no interconnects attached:

 

 

It seems:

- the 100Hz and 400Hz tones are not intrinsic to the Phasure DAC (100Hz is present in one case, and 400Hz in the other)

- the 100Hz tones may not be intrinic to the Altmann DAC either (I will pass the 24/176.4 10kHz file through the Altmann and see if the spikes become 400Hz instead)

- the Tascam ADC is not to blame

 

I suspect the 100Hz and 400Hz spikes are simply by-products of upsampling at 4x and 16x rates respectively.

 

Mani.

[PeterSt]

15 minutes ago, manisandher said:

With interconnects attached:

 

But shortcut, right ?

(it looks like not)

If not, no need to re-do it. It is fine as it is.

 

[manisandher]

32 minutes ago, PeterSt said:

But shortcut, right ?

 

No, ICs still connected to DAC (but no signal). These are captures I took a while ago that I'm just looking at now. I'll have to set everything up again to redo some captures. I will do this, because I'd like to try a few other things too. I'll include shorted ICs for sure.

 

Mani.

[manisandher]

On 4/11/2018 at 1:34 PM, mansr said:

Yes, there's a spike every 100 Hz. No, that's not normal.

 

On 4/12/2018 at 11:17 AM, mansr said:

There are spikes every 400 Hz, which is still not normal.

 

Solved.

 

We should have checked the test tones themselves!

 

10kHz 24/44.1 computer-generated test tone uesd:

 

Phasure DAC output:

 

 

10kHz 24/176.4 computer-generated test tone used:

 

Phasure DAC output:

 

It seems the DACs were innocent after all!

 

I'd like to run a totally clean 24/44.1 10kHz test tone through the Altmann again. Does anyone know where I can get one of >3 minutes duration from?

 

Mani.

[mansr]

39 minutes ago, manisandher said:

I'd like to run a totally clean 24/44.1 10kHz test tone through the Altmann again. Does anyone know where I can get one of >3 minutes duration from?

Try this one.

10k.flac

[esldude]

I feel like using only a 10 khz test tone is not enough to characterize the performance of a DAC.  

 

Mani would you be willing to run a series of tones if I put them together in a couple of tracks?

 

If so should I put them together in 24/176 form or 16/176 form?

[mansr]

4 minutes ago, esldude said:

I feel like using only a 10 khz test tone is not enough to characterize the performance of a DAC.  

Of course it isn't.

 

4 minutes ago, esldude said:

Mani would you be willing to run a series of tones if I put them together in a couple of tracks?

I have a set of ~30 test signals I typically use. Takes a while to run through them all.

[esldude]

1 minute ago, mansr said:

Of course it isn't.

 

I have a set of ~30 test signals I typically use. Takes a while to run through them all.

Well how long is takes awhile? 

 

What I typically do involves a 5 1/2 minute file with some useful tones.  And another 3 1/2 minute file for testing low signal level performance.   So if you run what I have in mind it probably would take someone all things considered a half hour I suppose to do both files twice.   So it'll take a half hour of Mani's time, but I would say he has spent more time than that typing replies here getting no where.  

 

Or maybe your more extensive group of signals is worthwhile.  I feel like you've handicapped yourself figuring out what is happening with only a single high level tone to work with and the direct music captures.  

[mansr]

6 minutes ago, esldude said:

Well how long is takes awhile? 

I usually play them for one minute each, so around half an hour. Obviously, that's mostly unattended.

 

6 minutes ago, esldude said:

What I typically do involves a 5 1/2 minute file with some useful tones.  And another 3 1/2 minute file for testing low signal level performance.   So if you run what I have in mind it probably would take someone all things considered a half hour I suppose to do both files twice.   So it'll take a half hour of Mani's time, but I would say he has spent more time than that typing replies here getting no where.  

 

Or maybe your more extensive group of signals is worthwhile.  I feel like you've handicapped yourself figuring out what is happening with only a single high level tone to work with and the direct music captures.  

It was never the intent to use only that one test.

[esldude]

1 hour ago, mansr said:

 

 

I have a set of ~30 test signals I typically use. Takes a while to run through them all.

Off topic, but I'd be interested in what your 30 test signals are and what all they investigate. 

[mansr]

9 minutes ago, esldude said:

Off topic, but I'd be interested in what your 30 test signals are and what all they investigate. 

There's white noise, tones, tone pairs, sweeps, impulses, and some some others at various frequencies (where applicable) and amplitudes.

[esldude]

31 minutes ago, mansr said:

There's white noise, tones, tone pairs, sweeps, impulses, and some some others at various frequencies (where applicable) and amplitudes.

Sounds the same as I have in general then.  

 

Since I am using recording ADCs I separate the low amplitude signals to a second file to run.  I adjust the gain of the ADC upward (usually 20 db) which applies gain to the noise floor of the DUT.  This gets the DUT noise floor well above the noise floor of my ADC so I can more accurately see what is happening on that end. 

[fas42]

On 14/04/2018 at 6:40 PM, manisandher said:

 

 

I'm not sure what a 'diff' program would find (I know you have to be careful with dud results from some of them). I suspect the signals are too complex or "chaotic" to identify any consistent differences between the two playback means, even within just a small section of time. The fact that the human ear can suggests that this is perhaps another inappropriate measurement.

 

But if anyone is interested in trying this, I'll be uploading soon the analogue captures that we took when Mans was here.

 

Mani.

 

A well done diff'ing analysis should find something of significance - they most certainly will vary, the hard bit will be pinpointing those aspects which matter to the ear, in the sense that we are talking about it here ... I'm certainly interested in having a go, .

 

It's trivially easy to see how badly the soundfield is "mangled" in some uploads of original versus system reproduction waveforms - typically, transients are way off what they should be ... in the situation here it will be far, far more subtle ...

[esldude]

So are we getting anywhere on analysis or has it hit a brickwall?  

 

Do you plan to run some test signals to further investigate the DAC in use?

 

Do you plan to make available the captures from the Tascam of both test signals and music?

 

Just curious.  If you've been busy, I understand and my apologies.  Just wondering where all this stands currently. 

[manisandher]

26 minutes ago, esldude said:

So are we getting anywhere on analysis or has it hit a brickwall?

 

The analysis to date has shown a consistent, albeit small, difference between the analogue outputs of the two bit-identical streams. However, the analysis has only been done with 10kHz tones, which themselves now look to have been slightly compromised. And the differences are at such a low level that it would be quite amazing if they were audible (directly).

 

26 minutes ago, esldude said:

Do you plan to run some test signals to further investigate the DAC in use?

 

I'm more than happy to do this.

 

10 hours ago, mansr said:

I have a set of ~30 test signals I typically use. Takes a while to run through them all.

 

Mans, if you could send these through to me and let me know what you'd like me to do, I'll do it. I'm assuming we'd need to do two takes, one for each of the settings used in the A/B/X?

 

26 minutes ago, esldude said:

Do you plan to make available the captures from the Tascam of both test signals and music?

 

Yep, I'll do that later today when I have more time. I'll upload digital and analogue captures of 'A' and 'B'. Mans has already verified that the digital captures are identical. You could try to compare the analogue captures to themselves, but I suspect it'll be difficult finding anything useful. What might be interesting would be to compare the analogue captures, not against themselves, but against one of the digital captures in turn - I wonder if this would help getting things more easily aligned?

 

Mani.

[manisandher]

I'm confused... perhaps someone could help me?

 

We put the following 10kHz test tone into the Altmann DAC:

 

The low-level spikes in the signal lie at around -165dB.

 

And here's the output from the DAC:

 

Yes, the above is averaged, but the spikes are visible even in the non-averaged output:

 

 

Now, how can a DAC using a 25-year-old 16-bit chip possibly resolve these spikes?

 

I'd love to know...

 

Mani.

[PeterSt]

14 minutes ago, manisandher said:

Now, how can a DAC using a 25-year-old 16-bit chip possibly resolve these spikes?

 

I'd love to know...

 

Mani, yesterday already I noticed that whatever the software is you are using there for the FFT's, it can't be right. There is no such thing as a SNR of better than 200dB which your first pic in the last post suggests.

 

16 minutes ago, manisandher said:

 

What's misleading in this "output of the DAC" is that the level is too low and not really visible for dB number. Looks like -30dBFS. The noise level looks to be ~-130dBFS so the SNR is ~100dB. This would be OK for the 16 bit DAC.

 

Btw, notice that you are "creating" problems now at analysing DACs which is not the subject to begin with. So we're drifting off ? It's not necessary to dig out more data than what's been done so far (or it must be that you like to satisfy random quests now). As far as I recall it was about 400Hz peaks visible in plots. Has that been sorted out now ?

 

[manisandher]

37 minutes ago, PeterSt said:

The noise level looks to be ~-130dBFS so the SNR is ~100dB. This would be OK for the 16 bit DAC.

 

OK, thanks.

 

37 minutes ago, PeterSt said:

Btw, notice that you are "creating" problems now at analysing DACs which is not the subject to begin with.

 

You and I would agree that the DAC used for the A/B/X was irrelevant, but some here criticised the chosen DAC, based on the chip's datasheet, and also its output of the 10kHz tone. I suppose I'm just trying to redress these criticisms. Perhaps there's no need?

 

37 minutes ago, PeterSt said:

It's not necessary to dig out more data than what's been done so far (or it must be that you like to satisfy random quests now).

 

No, I'm not looking to satisfy random requests. But if someone thinks that a specific set of tests would help them understand what's going on, I'm happy to do this. What's the downside, other than the time it takes me to conduct them, and the time it takes the requester to analyse the captures?

 

37 minutes ago, PeterSt said:

As far as I recall it was about 400Hz peaks visible in plots. Has that been sorted out now ?

 

Yep. The 400Hz peaks were intrinsic to the 24/176.4 10kHz test tone itself, and the 100Hz peaks were intrinsic to the 24/44/1 10kHz test tone itself.

 

37 minutes ago, PeterSt said:

So we're drifting off ?

 

OK, so where to now, in your opinion?

 

Mani.

[manisandher]

29 minutes ago, PeterSt said:

Mani, yesterday already I noticed that whatever the software is you are using there for the FFT's, it can't be right. There is no such thing as a SNR of better than 200dB which your first pic in the last post suggests.

 

I posted the non-averaged FFT earlier:

 

The averaged FFT looks like this:

 

OK, maybe the software (Musicscope) has a problem?

 

Mani.

[sandyk]

28 minutes ago, PeterSt said:

 It's not necessary to dig out more data than what's been done so far (or it must be that you like to satisfy random quests now).

  +1

 It's all about not doing things originally the way they would have liked to have seen them done, and perhaps attempt to denigrate Mani's results in the process ?

[adamdea]

I have not got very far with working out how to control for any artefact of the process of switching vs not switching the software settings, but one possibility would be to see whether the outputs can be tested as files in the foobar abx comparator. This could be done from recordings

1) of the spdif output of the computer

2) of the analogue output of the dac.

 

For my own part I think it would be interesting to see what the results of these would be, but would the fact that the stream was not live in the former, and that there was an additional ADDA loop in the latter, be deal breakers?  

 

The other possibility which had occurred to me would be to have two live streams which could be switched between -either two computers each running a version of the software or possibly two versions of the software running at the same time on the same machine.