Let's test the output of our DACs with RightMark Audio Analyzer.

Discussion in 'Audio Hardware' started by Robert C, May 12, 2016.

  1. harby

    harby Forum Resident

    Portland, OR, USA
    Although somewhat indicative, you shouldn't take much stock in this measurement. If you are monitoring noise, the response is going to be bouncing all around and the response will vary several dB just depending on when you take a snapshot. Also, especially in low frequencies, you cannot use FFT to obtain a very objective measurement. FFT analysis is not logarithmic, and breaking 96kHz into 8192 frequency bins gives very little resolution in low frequency. FFT cannot completely isolate a single band, it uses a windowing function that is a compromise of selectivity and accuracy. It is a very in-depth topic I don't feel like writing a treatise on right now.

    I tried to discover information about how the FFT analysis is performed in the Voxengo CurveEQ software, but there was no documentation. The smoothing of the line means we don't see the bins or samples, so don't have enough information to draw much conclusion, especially since you are live-sampling noise.

    You've found the reason for nothing. +0.1dB is imperceptible. Only kids and bats can hear above 15kHz, and likely your PA speakers are down 10dB+ at the 20kHz frequency 'peak'.

    The frequency response curve is exceptional, a standard that other analog components would struggle to meet. The peak is probably a function of the order of lowpass filtering that can clearly be seen.
    Last edited: May 20, 2016
  2. darkmass

    darkmass Forum Resident

    I do think your 50 Hz peak at -112 dB and repeating peaks at 100 Hz intervals are related to the characteristics of your mains. I'll be providing some additional insight further down.

    But first let me revisit my tested frequency response characteristics.

    Here is the frequency response graph, from my initial 192k/24 USBPre 2 test, that corresponds to your first graph in post #49:

    It honestly looks kind of pitiful compared to your Asus Xonar U7 plot...clearly your sound card is good stuff. I don't think my USBPre 2 is so bad at the upper end, it peaks at +0.04 dB at 4500 Hz, graphs at -0.11 dB at 20 kHz, is -0.29 dB at 30 kHz, and, hey, rolls down and out by ~72 kHz. If it's not as good as the Asus, by a lot of measures the USBPre's upper end is still something that can be easily lived with.

    It's the lower end of the scale where the USBPre seems a little wonky. There is no disputing it rolls off the lows. One question, at least in my mind, (as I suggested in post #47 above) is the FFT analysis exaggerating the amount of the roll off?

    Let me be arithmetical for a bit...

    A nice thing about the frequency response graphs is the way RMAA reads out the cursor position on a graph. It doesn't show the XY location of the cursor--though the X readout does correspond to the cursor location on the graph. However, the Y readout isn't the cursor Y position, it isn't even quite the graph Y point at the X cursor position. Actually the Y readout is more of a "bar chart" readout. As X moves, the Y readout stays constant (even if the Y cursor position is changing, and even if the graph in view has a slope to it) until at some X position there is a jump up or down in the Y readout value.

    In a graph, like the Asus graph, where the graph lower frequencies are ruler flat, this couldn't be seen. But in my USBPre 2 graphs the effect is visible. The Y jump (or drop) occurs at a slope inflection point, visible when the graph is zoomed in. These transition points can only be an edge of an FFT analysis bin.

    Now here's the real arithmetic... I found a bin edge at ~24 Hz, one at ~48 Hz, and one at ~72 Hz (the FFT bins are a constant linear frequency width). The total number of FFT bins is always a power of 2. If the sample rate is f Hz, the maximum FFT analysis bin ends at f/2 Hz, with the first bin starting one semi neutrino width to the right of 0 Hz. Okay, so for a 192 kHz sample rate, log(96k/24)/log(2), rounded to the nearest integer, should give the power of 2 for the total number of FFT bins. That turns out to be 4096 FFT bins, with each bin exactly 23.4375 Hz wide. That's for a 192 kHz sample rate. For a 44.1 kHz sample rate, each of RMAA's 4096 FFT bins is ~5.383 Hz wide.

    That's a lot of stuff, but what it means is that for FFT determined "frequency response" purposes, at a 192 kHz sample rate RMAA cannot tell the difference between 24 Hz and 46 Hz. RMAA cannot tell the difference between 0.0006 Hz and 23.2 Hz. The graph looks like it interpolates...but even so, on some level RMAA is faking it. To increase accuracy, more FFT bins are needed (a not unusual way to go).

    I'm going to pull up the 44.1k/24 plot because that somewhat helps by narrowing the FFT bins, but it should be kept in mind it also most likely modifies the USBPre 2 D/A/D frequency response characteristics:

    When I zoomed in I got a reading of -0.2 dB at 30 Hz, -0.29 dB at 20 Hz...not absolutely terrible. Sigh, it also made visible a ripple above 3 kHz. It's a modest ripple to be sure, but sometimes I just can't win!

    (continued next post...)
    Kyhl likes this.
  3. darkmass

    darkmass Forum Resident

    On to noise, and power...

    Here's my USBPre 192k/24 noise level graph that corresponds to your post #49 Asus graph:

    For me, RMAA reported a noise level of -101.0 dB. That looks to be the spike at 48 k Hz.

    Let me bring up the specs once more:

    For noise and dynamic range the specs indicate a measurement range of 22 Hz to 22 kHz, and that's pretty sensible for human ears. Within that range, the graph shows a maximum noise level of about -118.5 dB at 180 Hz. That's actually about 4.5 dB better than the spec's A/D converter dynamic range within the measurement interval...and the graph is a two-way result.

    In the graph you'll see spikes at 60 Hz, 180 Hz, 300 Hz, and 540 Hz. The mains over here are 60 Hz, of course, so that confirms your power related 100 Hz intervals. We both have spikes at 24 kHz, 40 kHz, ... Because of where they occur, my feeling is that they are sample rate related. (Our devices? RMAA?)

    One thing I haven't mentioned (though it was mentioned in the USBPre 2 site page I provided the link to in post #47) is that all the power comes to the USBPre 2 via the USB port. (If the USBPre is used stand alone, power needs to be provided by a wall wart or battery pack terminating in a USB connector.) You used an Audioquest Jitterbug to see if it would modify the noise. So allow me to try an iFi Micro iUSB Power along with an iFi Gemini "Dual Headed" USB cable (which splits off signal from power so the iUSB Power can provide clean power).

    Using the iFi stuff, I once again ran 44.1k/16, 44.1k/24, 96k/24, and 192k/24 RMAA tests.

    Here is the summary table with everything. I've placed corresponding tests adjacent, to aid comparison:

    Hmm, slight but pretty meaningless changes. How about the noise level comparison graph?


    Nope, the iFi doesn't seem to have done anything particularly meaningful. Maybe the laptop power is pretty good. :)
    Robert C and Kyhl like this.
  4. Robert C

    Robert C Sound Archivist Thread Starter

    London, UK
    :chill: :righton:
    Plan9 likes this.
  5. Robert C

    Robert C Sound Archivist Thread Starter

    London, UK
    Odd that yours is looking rolled off at the low end. The graph I posted on page 1 for my Rega DAC also shows a flat response in the sub-sonic frequencies.

    I also tried the noise test with my laptop running on battery power which gave worse results in the 50 Hz region. Curious that both the Jitterbug and iFi do nothing to clean up power!
  6. back2vinyl

    back2vinyl Forum Resident

    London, UK
    Sorry for delayed reaction.

    I sort of understand what you’re saying but I’m really out of my depth with FFT bins and the like. In Voxengo they talk about block sizes and I wonder if that’s the same as a bin size. I tend to obsess over the bass end of the frequency spectrum and in order to increase resolution and accuracy at the bass end in Voxengo (which I use a lot), I tend to use a higher block size than the standard default – my personal default is 16,384, which seems to produce a pleasing chart with good bass definition, and that’s what I used here. Voxengo also allows you to choose the degree of smoothing and my default, as used here, is 1/6 of an octave, though it’s easy enough to switch it off.

    I don’t want to over-burden the thread with charts but I have tried experimenting with other block sizes and I’ve found that reducing the block size to, say, 2048, does significantly increase the apparent size of the bass roll-off. On the other hand, increasing the block size makes little difference because I’m already nearly at the top setting - the only settings higher than 16,384 are 32,768 and 65,536.

    For what it’s worth, here is the same chart again but this time with smoothing switched off and another window open showing the block size:


    Just on the question of using pink noise as a measuring tool, I think Voxengo uses averaging to make its calculation so I don’t think it should matter too much if the response is “bouncing around” at the moment when you switch it on or off, though I can see it would have some impact.

    If you should want to see the documentation for Voxengo CurveEQ, there are two PDF files, a general one and another one specific to CurveEQ. There are links at the top left of this page:

    Voxengo CurveEQ

    Darkmass, that USBPre 2 looks a very nice piece of kit – I’ve never seen one before. On the subject of your frequency response charts, it’s amazing and slightly scary how you can get three very different charts from the same equipment chain, all using RMAA. It does seem to illustrate the danger of allowing this software to fall into the wrong hands! I don’t pretend for one moment to have followed your very impressive arithmetic but my sense is that what you’ve done is flesh out in numbers the general point made by harby, which is that you have to be careful with FFT bin sizes when measuring EQ, especially at the bottom end of the scale. If I’m understanding this right, which I very much doubt, there are two ways you can lift a sagging bottom – you can either increase the bin size or you can reduce the sampling rate. (Or both.) And the converse, obviously, is true. It makes for very difficult comparisons and I wonder that testers aren’t required to state what bin size and sampling rate are employed when producing a chart.
  7. House de Kris

    House de Kris Forum Resident

    Not sure that's how to interpret noise measurements. Just eyeballing the picture I quoted here, even ignoring the cyclical spurs (IOW, just looking at the random noise), I'd have said this was right around -99dB. I'd say the random noise swamps out the spurs you see. RMAA reports -101dB, so I'd be inclined to believe that. Certsainly no where near -118.5dB, or better. With the manufacturer's spec of -114dB for the ADC and 112dB for the DAC, I'd expect a loopback measurement to be in the neighborhood of -109dB to -110dB. BUT, the manufacturer's spec is a band limited A-weighted number. It is very difficult to apply A-weighting with the eyeball method, but weighting and bandwidth limiting could likely yield another 10dB. Thus, I'd conclude that RMAA bears out the printed claims from the manufacturer pretty well.

    EDIT: Oops, just saw that the RMAA noise is claimed to be A-weighted (dBA). Hmmm, not sure where that leaves us now. /EDIT

    Most likely the mains spurs you see are being picked up by the analog cable being used for the loopback. If you can, use a really short, very well shielded cable. Not routed near any power supply cables. Also, try moving it around and rerun the test to see if the physical position has an impact on the mains spurs measured.
  8. darkmass

    darkmass Forum Resident

    Speaking of delayed reactions (and probably illustrating profoundly what can happen when something falls into the wrong hands) . . .

    The USBPre 2 is quite a nice machine. I originally picked it up because it looked to nicely meet my needs for making SACD laser drops from the analog outs of my "Oppo 93". And it served that purpose well. However, as you certainly know SACD rendering can be a slippery slope. The USBPre 2 did come into play when I wanted to change de-embedded HDMI SACD from S/PDIF coax to USB, and with its wealth of digital and analog ins and outs it very handily serves odd jobs from time to time. No doubt much as your Hilo Lynx does, if not with the sheer quality of the Lynx. In reality, my USBPre 2 probably has only one advantage over your Lynx...I expect I could chuck my USBPre at a cat, then pick it (the USBPre 2) up and reconnect it for full and normal operation.

    Let's see, some other comments then I'll get on to additional business (which might also interest @robertzombie and others).

    1) The Voxengo terminology is confusing and a bit misleading. When it refers to "Block Size" that can only be the number of FFT "collection bins" which get spread in equal frequency interval/widths over the entire sample rate. That is, as an example, if the audio sample rate is 96 kHz and the Voxengo "Block Size" is 16384, each FFT bin will be 5.859375 Hz wide. Half of these will be in the range from to 48 kHz to 96 kHz, and to my way of thinking reasonably useless (though no doubt mathematically necessary). But I'm learning as I'm going, and maybe eventually some light will dawn for me.

    2) my "log(96k/24)/log(2) rounded to the nearest integer" was probably unnecessary, but it's also kind of the way I've come to think. The "24" part was the approximate FFT bin with I had determined from cursor movements, and the log stuff was a step in my finding out an exact FFT width...the 96k was the visible portion of the true 192k sample rate. I could have just as easily said "96000/24 = 4000" then found the power of two nearest "4000"...which would be "4096". My powers of 2 get a little murky after 1024 (2 to the number of fingers I have), so I invoked the log stuff. Of course I clearly was using a calculator, so I could just have gone "2 x 2 x ..." till I found something close to 4000.

    3) Yes, knowing the FFT bin width and sampling rate would certainly add meaning to tests and comparisons.

    4) You were using "pink noise" (equal spectrum energy for each octave...which has true human meaning), but it may have been nominally more meaningful to have been using "white noise" (equal spectrum energy for each frequency) due to the FFT underpinnings for most readably available spectrum analysis tools. Granted, spectrum analysis tools have a log-domain X-axis (pink noise like). But the pink noise is why the filled-in portions of your Voxengo plots have slopes to them. But. Play around, then just use whatever you like to use.

    5) When I found out how FFT binning treated low frequencies I was even more shocked than when I first found out about the DSD "hump". Much more shocked in fact.

    Okay now it's time for the additional thread business . . .

    Even though I haven't been particularly visible over the last week, I've been worrying some of the USBPre 2 stuff as I have been able to fit it in. I did make a few interesting discoveries.

    In my tests earlier in this thread I was using the "consumer level" aux ins and outs with a quite "throw away" quality 1-meter RCA terminated interconnect. Well, it helped illustrate some lessons probably worth learning. (Keep in mind, however, not much of this thread's testing is entirely meaningful stuff...I've never before used the USBPre with the outs connected to the ins, and I won't be doing much of it in the future.) But what I'm leading up to is that the USBPre 2 also has balanced outs and ins. I've got a very fine half-meter, silver, Surf Audio pair of balanced cables, but there's a problem.

    Due to my purpose for the Surf Audio cables, the two have an XLR connector on each end. The USBPre 2 balanced outs, are XLR--and switchable between line and mic characteristics--but the XLR ins are mic only (no switching). The USBPre balanced ins are for 1/4 inch balanced jacks. I did try the Surf Audio cables mic to mic, but mic voltage levels and necessary amplification gave no better testing results than by my earlier using the "aux" ins and outs. I looked through my box of audio detritus collected over the eons--but no XLR to 1/4 inch adapters. However, I did have some RCA female to XLR (both male and female) adapters, and some RCA female to 1/4 inch male adapters. I also had a middling Monster 1-meter stereo interconnect. At least in looks the middling Monster was about 50 times the quality of the throw-away interconnects. So I was able to put together an ersatz balanced cable that could connect my USBPre 2 balanced outs (in the "line" setting) to the USBPre 2 balanced "line" ins.

    Here's the 192k/24 RMAA summery table. First column, old "aux" testing, second column balanced testing:

    Of note, Noise level and Dynamic range have each improved by 5 dB. And look at what happened to the Stereo crosstalk!

    Now if you think the Noise level has improved (and it has), take a look at the balanced Noise level plot:

    That's a serious enough improvement over the "aux" 192k/24 plot.

    Robertzombie, why didn't the Jitterbug and the iFi reduce our noise levels? It seems we live in a serious electromagnetic soup, and interconnects can make pretty fair antennas. Of course single-ended versus balanced line level signal strengths and corresponding amplification levels have to be a notable factor in my personal test results. And, it's appropriate to acknowledge House de Kris's comments in post #57.
    Robert C and Kyhl like this.
  9. Robert C

    Robert C Sound Archivist Thread Starter

    London, UK
    Nice work!
    darkmass likes this.
  10. darkmass

    darkmass Forum Resident

    Part 2 . . .

    I still wanted to get at the low frequency characteristics of the USBPre 2, and I had my mistrust of RMAA for frequencies in the vicinity of 20 Hz--due to the FFT bin size RMAA uses in its most precise mode. Fortunately (or seriously unfortunately), I tend to purchase various software tools.

    RMAA can write out its testing file as it exists before it's sent through any equipment. Here is what that RMAA wav file looks like when it's brought into iZotope RX5 Advanced Audio Editor 64:

    Left and right channels, the blue portions indicate signal strength as a function of time (with the thin blue pair at the top repeating that), the orange/yellow regions indicate frequency and frequency strength as a function of time. I've figured out the purposes of some of the regions. The third region from the left is a 1 kHz reference tone at a low volume, the fourth region from the left is a 1 kHz reference tone at a high volume. I think the thin six and seven regions are for left and right channel spectrum testing, and probably also serve for crosstalk testing.

    The six and seven regions are what I'm going to use.

    Using Sony Vegas Pro 13, I brought in the 192k/24 "baseline" testing wav file and 192k/24 "balanced" test results wav file and put them in parallel. Zooming way in till individual signal spikes and waveforms could be easily seen, I carefully aligned the "baseline" and "balanced" renditions and trimmed out everything that wasn't part of the six and seven regions.

    Here are the results in Vegas Pro:

    The top blue pair are the left and right baseline channels. The lower red pair, the balanced test results channels. I wrote each stereo pair out to their own 192k/24 wav files. It does look like the baseline has a bit more signal strength, but that's just amplification and the proper normalization will take care of it.

    All right, just about there now . . .

    RX 5 Advanced Audio Editor has a serious enough spectrum analyzer. There are other spectrum analyzers that have some more useful features from my perspective, but the RX 5 version will serve well here.

    First, the Vegas Pro trimmed "baseline" wav file brought into the RX 5 spectrum analyzer:

    Next, the trimmed "balanced" wav file:

    Since these are 192k/24 files, the analyzer plots run from 20 Hz to 96 kHz. The baseline plot is a touch higher over all due to signal strength, the balanced plot rolls off slightly at the low end and much more obviously at the high end.

    At the upper left of each plot, "FFT size" is indicated. Because I shrunk the plots down for this post, the number of FFT bins may be hard to read, but it's 1,048,576. Dividing that into the full 192 kHz sampling value, that results in approximately 0.1831 Hz wide FFT bins. Close enough for jazz. Oh, the heavier horizontal lines in the plot window are 5 dB apart.

    Not visible in these plots, but moving the cursor around gives a readout of the plot frequency at that X cursor position, and the actual plot height in dB at that cursor X position. (The cursor Y position is ignored. Everything acts just like in the spectrum readout in RMAA, but at a much finer resolution.)

    One thing that's immediately obvious is that these plots are not at all a straight line, though the peaks come very close to a straight line. From what I've seen recently, there may be an FFT analysis specific reason for that, but my knowledge isn't there yet.

    Okay, 1 kHz is the standard reference tone for things like this, so measuring the baseline plot signal level at 1 kHz I get -101.8 dB. 1 kHz in the balanced plot gives me -102.0 dB. So for normalization purposes, I need to add 0.2 dB to any reading in the balanced plot to get a correct comparison.

    Time to head over to 20 Hz for the final answer . . .

    At 20 Hz, the baseline plot reads -95.8 dB (20 Hz is not at one of the peaks). At 20 Hz, the balanced plot reads -97.8 dB...adding 0.2 dB for normalization, the balanced 20 Hz level is effectively -97.6 dB. For a final result, two-way with "balanced" outs to ins, the USBPre 2 is at down at -1.8 dB at 20 Hz. More or less. :)
    Kyhl likes this.
  11. harby

    harby Forum Resident

    Portland, OR, USA
    What you are looking at is analysis showing the "noise" for the wide band analysis is actually made by many tone generators in RightMark. We can see that the octave 100-200hz has five peaks, while the octave 1k-2k has eight peaks. Low frequencies have low resolution. The curves between the tones are from the windowing function in the analysis, likely a gaussian window in this case.

    To get the same effect, I generated four tones centered on the 44.1k 4096 FFT bins 10.76hz, 21.53hz, 32.30hz, and 43.07hz. Here is frequency analysis of the tones, analyzed at 65536 FFT size (zoomed in 10hz-120hz):


    You can see nearly identical features to your graphic above, although the bar view here shows the actual frequency bins. You can see the FFT window function artifact in bins adjacent to the tone frequency centers that have "signal" where there is none.

    Likely Rightmark does not use this tone for frequency analysis, the sweep tone that comes later would be used.

    For you to successfully and very accurately use FFT analysis to classify low frequency response, I've created a tone sweep for you. It is 60 seconds linear 5.38hz-53.83hz, followed by a 10 second ~1khz tone sweep at the same sweep rate for reference. Download here.

    Here is what analysis of the tone (averaging the whole 70 seconds) will look like at maximum FFT view - flat 5hz to 50hz with infinite FFT resolution available:
  12. back2vinyl

    back2vinyl Forum Resident

    London, UK
    Darkmass, many thanks for explaining Voxengo's block sizes a lot more clearly than Voxengo themselves ever have. Some of this is actually sinking in and I do feel able to make more sense of it all than before. Finding out why pink noise always slopes in Voxengo was the icing on the cake.

    With your new experiments, it was interesting that switching to better cables made such a difference, especially to a cable sceptic like me. I can understand why the noise level improved but the stereo crosstalk? I'm baffled by that. Any theories?
  13. darkmass

    darkmass Forum Resident

    Thank you for the description. And thank you for making the download available to me. Because I'm interested in my USBPre 2's operation for 192k files, I uprezzed your file to 192k (but left it at 16 bits) before I looped it through my device.

    While my preceding post left me concluding my 20 Hz response fell off to -1.8 dB compared to the normalized reference 1000 Hz level, by use of your work that changed to -2.2 dB compared to a normalized reference 1000 Hz. I have to believe that is more accurate.

    Inspired by what you did, I even dug into an application I've almost completely ignored since its purchase: SIGVIEW. Using SIGVIEW I generated a 600 second linear sweep running from 0.1 Hz to 2000 Hz at 192k (the signal generation is in mono) as a 32 bit float wav file. In other applications I can modify the bit depth, and I've since made a couple of stereo versions of that file: one file as a 10 minute matching stereo pair; the other, 20 minute, stereo file with the signal running for ten minutes strictly on the left, followed by the signal running for ten minutes strictly on the right. My intent with these is to get an idea of what crosstalk might do to low frequency response while in hi-rez USBPre 2 operation.

    Here is what the mono source file looks like with 524,266 FFT bins with no time overlap:

    And here is what the mono source looks like with that same number of bins and a "4x" time overlap:

    In my case I've included the 1000 Hz reference as part of the sweep. I'm doing these further tests strictly for my own rather warped curiosity and education, I probably won't be posting the results. :)
  14. darkmass

    darkmass Forum Resident

    I think I owe you an apology. I certainly need to more thoroughly research what my thought experiments can lead me to believe before I pass my thoughts on.

    It is true as a general rule that white noise should show as horizontally flat in a spectrum analyzer (though not necessarily as an absolutely straight line). In fact, recently I've been generating white noise signals of varying durations and looking at them in the RX 5 spectrum analyzer. Yes, pretty horizontal looking signals.

    But after I wrote you about the difference between white noise and pink noise, I began thinking, "Wait, shouldn't pink noise slope in the opposite direction from that shown in your Voxengo plots (that is, shouldn't pink noise slope down towards the right)?" So I looked at some pink noise in the RX 5 spectrum analyzer and, yes, pink noise sloped down towards the right. Other spectrum analyzers showed the same effect.

    Opening white noise and pink noise signals in Voxengo showed them both sloping down towards the left, though the slopes were different for the two signals. It seemed Voxengo, for its own reasons, presented signals in a non-standard manner.

    I went looking through the Voxengo controls to see what I could determine. Aha! Using the EDIT button, towards the top right, brought up a set of controls...one of them a dial labeled "SLOPE" (the SLOPE control does show in post #56). Mouse dragging the SLOPE dial to a reading of "0.0" (or just using the enter functionality for that) made white noise horizontal and pink noise slope down towards the right. I'm not sure how the SLOPE control affects the Voxengo spectrum matching results, but some experimentation should reveal the answer to that.

    I also owe you a crosstalk response, but that will wait a bit.
  15. back2vinyl

    back2vinyl Forum Resident

    London, UK

    Oh yes, I see what you mean. It's a long time since I read the Voxengo instructions but this rang a vague bell and sure enough, in the Primary Guide, it says this:

    Note that by default Voxengo plug-ins use 4.5 dB per octave slope for the spectrum
    display which makes it look considerably “elevated” towards the higher frequencies in
    comparison to most other spectrum analyzers available on the market. This setting
    can be changed in the “Spectrum Mode Editor” window.
    I wonder why they do that? I suppose it makes for a pleasantly level chart if there's normally less energy in the higher frequencies than in the lower ones. But it's kind of alarming if it exaggerates the higher frequencies at the expense of the low frequencies. I'll have to look into this a bit more.
  16. darkmass

    darkmass Forum Resident

    Back2vinyl, don't let go of your skepticism just yet. While I tend to be rich with theories about most everything, I decided that the wiser course was to first do some additional testing.

    Now as a precursor worth mentioning, robertzombie reported that when he ran his laptop strictly off the battery, his noise results looked no better...in fact his results may have worsened. Prior to reading that it had already occurred to me that since my USBPre 2 drew power from my laptop via the USB bus, the natural way to ensure smooth USB power, with no mains components, was to unplug my laptop and use the battery! I even powered down my wireless server to keep mains components from sneaking in that way. My results (this was when I was still testing "consumer" characteristics on my USBPre 2) did knock my 60 Hz mains noise spike down to where it was no different from other noise in the immediate frequency vicinity, but the 60 Hz multiples that stood out in the original noise plots were still there unchanged. I felt my results confirmed robertzombie's results...though in his case I think his 50 Hz mains spike was still present.

    The only thing I could conclude from all this was that not just random noise was present in our systems, we were also receiving radiated mains frequency related signals from all the electronic stuff we, and our neighbors, populate our lives with. In post #57, House de Kris mentioned that the "mains spurs" were most likely the result of my analog interconnect used for the loop back, and that made sense to me.

    Now back to the results you commented on. I knew, and I hoped this came out in my writing, that I changed two things related to my USBPre 2 in my kind of "go for broke" test...I changed from "consumer" circuitry to "balanced" circuitry, and I now used an interconnect that physically looked a lot more well constructed than the interconnect I first used.

    When I saw the quite visible improvements in test noise characteristics, I did feel that the outside noise, particularly the mains related frequencies, were no longer being picked up to as high a degree by the better interconnect. And, as an off the top of my head response to your crosstalk query, I would have said something like there are two cable antennas running right next to each other (left and right channel). That although the noise was being measured as an analog frequency range, the digitally sourced noise was most likely a mix of system internal noise and noise radiated into the interconnect--with a high proportion of the mix coming from within the system. However, the analog sourced noise (while still mixed) was less system internal noise but more highly proportioned as noise radiated into an interconnect channel. And I would have continued that the chart "Noise level" was a composite reading of internal noise and the noise radiated into the cable, while the diminished mains related noise spikes in the plots and the significantly improved crosstalk reading better indicated the differentiation of noise types present within an interconnect and better reflected the high level of diminishment of what was being radiated into the improved cable.

    As an additional comment, I should note that any crosstalk seems to me to be kind of a reverberant effect...with, say, a strong signal leaking from the left to right channel, then further leaking at a reduced intensity from the right channel back to the left channel--and so on. A better cable (or a better system) would more greatly reduce reverberant effects at each bounce.

    But setting aside all that, before I responded to you I knew I had to cut back from two variables being changed in my testing to only a single variable being changed.

    Because my "balanced" cable was constructed out of an RCA interconnect and balanced adaptors, all I had to do was to was replace the Monster interconnect with the "throw-away" interconnect in my "balanced" cable construction. If that put things back very close to my original results, the first "balanced" test results were probably entirely due to the interconnect. If with the single-variable "balanced" test things seemed kind of mid-way between my original "consumer" results and my first "balanced" results, then the effect was probably due to a combination of balanced circuitry/operational levels and interconnect characteristics. However, if swapping the interconnect in my "balanced" cable construction produced results similar to the results from the first balanced test, then the better balanced test results probably had nothing whatsoever to do with the qualities of my two interconnects...all the change must be due to USBPre 2 balanced circuit operation and balanced operation signal levels.

    A pure interconnect swap in my "balanced cable" didn't change a thing in my balanced tests. That is, using the throwaway interconnect in balanced operation still meant that noise and dynamic ranges were both improved by 5 dB over my very first tests. Using the throwaway interconnect in balanced operation still meant that crosstalk was in the immediate vicinity of -95.6 dB. So the only answer seems to be that the USBPre 2 internal circuitry/amplifiers have about 20 dB of (additional) crosstalk signal leakage when using the consumer level ins/outs. Whether that is all in D/A, all in A/D, or some combination of D/A and A/D is probably something I cannot sort out (though I am assuming the mains related frequencies showing up in noise plots are all analog domain circuitry effects).

    Still, in my opinion the USBPre 2 is very much fit for purpose. It does what it needs to do. It can juggle various digital and analog interfaces...and the two-way deleterious effects measured by the RMAA loop-through testing are, um, "down in the noise".
  17. back2vinyl

    back2vinyl Forum Resident

    London, UK
    I enjoyed reading about your tests, darkmass - thank you very much for explaining them so comprehensively. And I'm relieved to hear I don't have to let go of my cable scepticism just yet.

    I wonder, though. I think you conclusively proved that the quality of the RCA interconnect made no difference to noise or crosstalk. But I thought you were a bit harsh on your poor little USBPRe 2, heaping all the blame on its consumer level internal circuitry. I don't know enough about this to offer a an opinion but couldn't the difference simply be down to the inherent advantages offered by a balanced system architecture rather than anything specific to the USBPre 2? I didn't see how your tests ruled that out, though very likely I've misunderstood your conclusions.

    Off topic, I was looking at the slope in Voxengo CurveEQ. I can see now that it's purely a presentational thing and would never effect an EQ comparison. If you load two files, then hit "Match spectrums" to do an EQ comparison, it doesn't matter what slope you use because both files will be affected equally so the comparison always stays exactly the same. (When you change the slope, the spectrums tip one way or the other but the EQ curve never moves.) I suppose in theory, if you applied one slope to one file and another slope to another file, you could have problems comparing them, but this could never happen in Voxengo CurveEQ because you can only apply one slope to all the files loaded at any one time, and it's not possible to save a file with any particular slope applied.
  18. darkmass

    darkmass Forum Resident

    I think your point about inherent advantages in balanced circuitry is a valid one. If the consumer level circuitry of my USBPre 2 suffers in comparison, that could certainly be a natural consequence of circuit architecture differences. Though I think I'm stepping out of this thread, in the last several hours I've even ordered proper adapters to bring true, three-conductor, "line level" balanced signals, from a true balanced cable, into my USBPre 2 via quarter inch TRS plugs (amazing what carefully reading the manual can reveal).

    There will most certainly be balanced, and consumer level, RMAA "USBPre 2 connected to xxxxxx" learning adventures going into my task queue. Though my DAC (an Aune S16) was largely selected for providing balanced outs as well as single ended outs (the balanced outs connect to the balanced ins of my Cavalli Liquid Carbon headphone amp), I haven't yet decided whether the DAC will eventually go into the xxxxxx slot--but it may. What will happen soon, however, is that I'll load 44.1k/16 and 192k/24 RMAA test wav files into my Pono player and run outs from that, in both consumer and fully balanced configurations, into the A/D side of the USBPre 2 and see what happens. There will certainly be unknowns in my test setup, but for the Pono itself I have John Atkinson "Stereophile" test results from him putting a Pono on his test bench. If I'm not sure what I will learn, I will most certainly learn something I never expected.

    Now, you have reported that you have an extreme noise problem--and possibly a ground loop is included in that. If that surfaces only in attempting an RMAA loop through, that's possibly not a big deal even if it's frustrating. However, if the noise has an impact on any part of your normal configuration I hope you can get things quickly sorted.

    As always, I particularly enjoy our conversations. And that's good news concerning the Voxengo CurveEQ. Hmmm, I think I know a way you can use the Voxengo to make a "DSD hump" look much less threatening!
  19. back2vinyl

    back2vinyl Forum Resident

    London, UK
    That's a surprise, finding your USBPre2 has balanced line-level ins in the shape of TRS sockets. The only place I've ever seen those is on my Audeze LCD-2 headphones. I guess they provided such an amazing array of ins and outs on that very small box that they ran out of space for another set of full-size XLR line-level ins, so they provided the redux version rather than have anyone go without. No problem - except everyone who wants to use them has to buy a set of adapters!

    I suppose it's a mixed blessing in a way since it opens the way for endless testing which will tie you up for days, weeks or months to come. All good fun, though.

    As you say, my problem with noises arises from loop-through testing and I'm not too concerned about it since it doesn't arise in real life. One of these days, though, I would like to find a way of doing what you propose, which is to run an RMAA test WAV file on one device and measure the signal as it arrives at another. I never did figure out a way of doing that so if you should stumble upon a set of instructions at any time, do feel free to post a link.

    Anyway best of luck with it and I look forward as ever to reading your posts.
  20. darkmass

    darkmass Forum Resident

    Well, here I am once more. It's a surprise to me too.

    You said one device to another (device), right? Not instructions themselves, but one device that could work for you, here. I'll let this stand as one example, a portable player (like my Pono) would be another example.

    Okay, I just emulated the process I'm detailing below, and the process worked for me. (I'll say what my "emulation" means a bit further down.)

    Here's what you can do--if there's much more detail than you actually require, I'm trying for completeness. I do hope this is the kind of thing you mean, I could be completely missing the mark . . .

    1) Use RMAA to generate a basic test file at your desired sample rate and bit depth. It's just a garden variety wav file of course.

    2) Load that file onto a USB thumb drive and then connect the thumb drive to the above referenced output device.

    3) Run the analog audio out or digital coax out from the linked device into the appropriate Lynx Hilo inputs and, of course, USB goes from the Hilo to your computer.

    4) Set Audition to record at the sample rate and bit depth of the RMAA generated test file (naturally, using the Hilo ASIO driver as the recording input), arm the recording, and let the recording process run.

    5) Go to the Sony output device you are using and start playback of the RMAA test wav file.

    6) Give the Audition recording process a few extra moments to run and record after playback is completed, then save out the recording.

    7) Bring a copy of the original RMAA generated test file into Audition and bring a copy of your Audition recorded test file into Audition and trim the start and end of the recorded file to be good matches for the original RMAA file. Then save out the trimmed recording.

    8) RMAA can read the trimmed recorded file just as if RMAA itself had generated the file. Load the recorded file into RMAA and look at the RMAA analysis. Of course, RMAA can also incorporate the recorded results into comparisons.

    I emulated the above by setting my copy of Sony Sound Forge Pro to play the RMAA generated test file, after first setting up Sony Vegas Pro to record the data coming in via USB. In my case I used the USBPre 2 ASIO as both input and output devices and the playback looped through the USBPre 2. I then used Vegas Pro to trim the recorded file, then brought the trimmed file into RMAA (that was my one worry, I hadn't quite done that before). RMAA accepted the trimmed recording as one of its own, and matching results with an entirely RMAA initiated and executed loop through test showed agreement.

    You should be able to do a similar thing computer to computer, but that depends on the ins and outs of the two computers involved. I didn't know any of this stuff when you were first trying a computer to computer connection, but I've learned things in the course of this thread...and I've thought about a few things. If my set of steps is completely off base from what you hope to do, let me know so I can think about things more clearly.

    Back to the USBPre 2 . . .

    The balanced outs are XLR, and switchable between mic and line characteristics as a stereo pair. The XLR balanced ins are mic characteristics, but the characteristics are not switchable. The TRS plug balanced ins are line characteristics, and the characteristics not switchable. It does seem that if the XLR ins were switchable between mic and line characteristics that would solve everything...but there's some extra complexity to the USBPre 2. The USBPre 2 input can be switched between Mic (balanced), Line (balanced), Aux (consumer RCA), and SPDIF (there are both coax and TOSLINK, SPDIF ins and outs). The thing is the left and right stereo input channels are independently selectable. I have to assume the USBPre 2 designers saw some utility in providing for balanced (XLR) mic in for one channel and balanced (TRS) line in for the other channel (and, yes, there is no room for another XLR pair). The USBPre 2 really is a stunningly capable device. If it cannot do a particular capability with quite the specifications of a device dedicated to that capability, the USBPre 2 is probably closer to the performance of a dedicated device than human senses can normally detect.
  21. back2vinyl

    back2vinyl Forum Resident

    London, UK
    Aha! Thanks, darkmass - now I understand. My problem was, I was trying to figure out how to conduct an RMAA test from one device to another in real time - it never occurred to me to record the incoming signal in a WAV file and then play it back in RMAA to test it. Looking at the RMAA interface, I can now see how that would work.

    Sigh...now I'm going to have to test every piece of equipment I own.
    Robert C and darkmass like this.
  22. back2vinyl

    back2vinyl Forum Resident

    London, UK
    I'm reopening this thread to report an experience I had when testing a headphone amp with RMAA. I think it points to another risk of relying too heavily on test results.

    The DAC+amp was an Optima Nuforce uDAC 5, which is USB powered. It measured very respectably in RMAA but when I listened to it with my Audeze LCD-2 headphones plugged in, I felt the bass was distinctly lacking and somewhat distorted, relative to the sound obtained from my other DAC+amps or even the internal PC sound card. So I ran the tests again, this time using a Y splitter to pass the analogue signal from the headphone amp to two places simultaneously - the RMAA loop-back and the headphones. The RMAA test results were the same but the sound through the headphones was still poor.

    I then tried recording the output from the headphone amp into Adobe Audition, with no headphones attached. It sounded fine when played back through another PC, through a high quality DAC+amp. I couldn't hear a difference between that recording and other recordings done from other headphone amps.

    My conclusion is this. The Optima Nuforce uDac-5 DAC+amp performs well when playing with a light load but cannot cope with the load presented by the Audeze LCD-2. So even though it tests very well with RMAA, the reality is that it does not actually deliver those specifications in real life when attached to certain headphones. And the big problem is, you cannot test for this with RMAA using a Y-splitter, because even if you test the amp while under load, the signal that goes to your RMAA device will be untroubled by the load and will not reveal the effects. The only way to test the real-life output when under load would be to test the output from the headphones themselves using one of those hyper expensive head simulators that are beyond the reach of ordinary audio enthusiasts. And anyway, of course, you would then be testing the performance of your headphones as much as the output of the DAC+amp.

    Maybe this was always obvious to everyone else but it was a learning experience for me. What I now realise is that you can have a DAC+amp that measures superbly in RMAA but will actually perform quite poorly when plugged into a load, and unfortunately, there's no way of testing for this with RMAA because there's no way of putting RMAA in series with the load.
    darkmass likes this.
  23. Dude111

    Dude111 An Awesome Dude

  24. Robert C

    Robert C Sound Archivist Thread Starter

    London, UK
    I'd like to resurrect this thread by discussing a topic I've been thinking about recently: Do sound cards / DAC units with the same or similar specifications sound the same? Below, you can see the results for my Asus Xonar U7 sound card, Rega DAC-R, and @harby 's Creative Audigy 2 ZS. You can see from the Asus and Rega frequency response results that they are more or less identical. As @harby rightfully pointed out, +/- 0.1 dB is imperceptible, and (in 24/96 mode) I'm not sure that the Asus' additional 8.4 dB of dynamic range (equivalent to 1.4 bits) would be at all audible or useful when you consider the added noise level of pre-amplifiers and power amplifiers further down the signal chain. The Audigy has a visibly different frequency response, but it is flat throughout the majority of the audible band. The implication, at least according to the results and graphs we've seen here, is that "objectively" there should be no audible difference between these devices.

    I compared some DACs a year ago, before I developed an interest in objective audio, and believed that I could hear a difference between them. However I'm now wondering if I actually did or whether it was placebo. I'd be interested to know what the members here think about this topic.

    If, for example, there is an audible difference between the Asus Xonar U7 and Rega DAC-R, despite their very similar test results, what might cause that audible difference?

  25. daglesj

    daglesj Forum Resident

    Norfolk, UK
    My £20 Fiio DAC

    Jimi Floyd likes this.

Share This Page