Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Langston]

Hello:

Three days ago I finally looked at JRiver MC and I'm stunned. What an amazing piece of horsepower for the music lover. I've been using hardware processors for convolution and the more basic needs to tune sound systems for years, and this piece of software pretty much encompasses everything as far as playback systems are concerned. The Wiki is amazing. Matt is amazing. Thanks to everyone involved with this work of art!

Anyway, I read everything I can before asking questions and it appears that using several 2-channel D/A's connected to my Mac mini using OSX's aggregate device feature isn't going to work with MC. I tried everything I could think of today without success. The Benchmark converters are my favorite and they are only available in 2-channel format. It looks like I'd have to buy something like a Lynx Aurora 8 to be able to interface them to my Mac in a way that MC can use them. The aggregate device does show up in the MC's Options as a selectable sound device, it just won't work.

Too bad, but given the technical prowess behind this software, my guess is the problem may be Apple's implementation of this feature.

Anyone that has had success using an aggregate device grouping of sound cards in OSX with MC, please chime in. :)

[JimH]

Welcome to the forum and thanks for your comments.

You could use zones to handle two or more DAC's.  The wiki has a topic.

[blgentry]

I just played with this to try to make it work.  It took a bunch of messing around, but I got it to work.  The biggest keys for me were:

1.  Turn off exclusive access.
2.  Set DSP Studio > Output Format > Channels  to the actual number of channels your aggregate device has.

I have no experience long term with this.  On the windows (and maybe Linux?) side several members have tried to use multiple external sound cards to drive multi-way speaker systems and they have found that they drift apart. I'm not sure what will happen on OSX.  In Audio MIDI setup, I noticed that it knows to use the clock from ONE of the DACs as it's source, so maybe it will keep them synced?

What exactly are you hoping to accomplish?

Brian.

[blgentry]

Playing with this some more, it doesn't seem stable.  Playing 16/44.1 files I get sound correctly from both devices.  Switching to 24/96 material, one source gets very distorted with lots of clicks and pops.  I adjusted hardware and software buffering and thought I made a difference.  But then the clicks came back.  Not sure what's going on here.

Brian.

[Langston]

That's huge Brian - thanks so much for all the time you spent on this. And I should have mentioned the end game per your first post. :)

The typical reason given for setting up an aggregate device in OSX is to save loot over buying a single multichannel audio interface. In my case I'd really like to use a specific D/A converter that only comes in 2-channel versions, thus I'd like to have (3) of them for a total of 6-channels driving a 5.1 system. I'm using an Oppo BDP-105D at present via its HDMI input as a 5.1 converter and it works like a charm with OSX and MC. It's main converters for left and right are also very well designed and embarrass several multi-thousand dollar units I've tried. I just made an evil subjective statement in my second post! :)

And thanks Jim, I'm definitely looking forward to using Zones, but it's my impression that while it may allow multiple D/A's to be used simultaneously, it wouldn't employ the cool and probably necessary feature in OSX's implementation of syncing clocks through the digital audio stream. Not doing this is likely the source of the trouble experienced by the Windows/Linux folks when attempting aggregation.

I'll let you know what I come up with, but I'm not hopeful unless the MC code gurus get interested. In my experience, proper inverse filter design (convolution) outweighs high end vs. very good D/A converter differences by 10 fold at least. A good bottle of wine always helps, so I may stick with the Oppo as converter even if I can get an aggregate device to function reliably.

PS: It's hilarious that the forum software changes "J-R-M-C" (without dashes) to "MC". I guess the "why" behind that is very deep and mysterious. :)

[blgentry]

Maybe your setup will work properly.  For testing I was using one external DAC and one built-in sound device.  So who knows.  When you set up your aggregate device, be aware of the channel numbering.  It should go in this order:  L, R, C, Sub, LS, RS .  Corresponding to 1, 2, 3, 4, 5, 6 in Audio MIDI's channel numbering.

Like I said, several people have tried this and haven't had good results.  But I don't think any of them have tried it under OSX.  You might be the first!   Good luck.

Oh, here's me testing:  MC.  MC.  Is there a JR in the first one?  Nope.  I never noticed the auto-correction before!

Brian.

[JimH]

I didn't understand your use case.

[JimH]

On this forum, there is only one MC.  The other one is WMC.

[blgentry]

I didn't understand your use case.

The OP wants to use three (3) stereo DACs to drive a 5.1 channel audio system.  He wants to do this because these DACs are very high quality and presumably a 6 channel DAC of the same quality would be more money, or perhaps not available.  That's all.

Brian.

[Langston]

Brian and Jim:

Thanks again for the clues. :)

I have access to (2) USB D/A converters at the moment, the Benchmark DAC2 and the Oppo BDP-105D. I just set them up as a 4-channel aggregate device and can’t get it to break - it seems to work perfectly. OSX v10.9.5.

I set up the aggregate device as follows:



I had to disable both "exclusive access" and "integer mode" in MC’s Options. After reading through the Wiki and some of Matt’s forum comments, I can’t see what I’m giving up in quality by disabling these features given that this is a dedicated media server with no other sound sources competing for the hardware.

I used FLAC 16bit/44.1k and ALAC and WAV 24bit/96k source files. I tried every Sample Rate from 44.1k to 192k and both D/A’s obediently switched their SR’s to match while remaining at their hardware’s maximum bit depth. All (4) channels maintained their proper signal output relative to my Left, Right, Left Surround, Right Surround layout. Each channel processed a 96k convolution file that was seamlessly resampled at the other SR's with no audible degradation - amazing. Rebooting the computer a couple of times didn’t confuse it - it came back with the aggregate device operating properly with clock master, etc., selections in Audio MIDI Setup remaining constant. Drop out free so far.

My next test will be to connect to the multichannel D/A in the Oppo via HDMI and have a go at enabling (4) of its (8) channels to serve as LS, RS, Center and Sub while the Benchmark handles the main L/R.

This software is amazing. I’m going to buy a 2nd copy to give away for Christmas.

[blgentry]

Awesome.  I'm glad to hear it's working correctly for you.  I would think you'd want to do some sort of long term playback over at least 4 channels to make sure there's no timing drift as has been previously reported.  Maybe an hour or two?

BTW, the "speaker configuration" portion of Audio MIDI seems to be ignored by MC.  It seems to just take the channel assignment numbers on the first page and maps them in the order I was telling you before.  At least that's what *seemed* to be happening on my system.  Reassigning channels to different speakers on the speaker graphic screen didn't change anything in MC's playback for me.  So I think you can ignore that part in terms of MC's playback.

Let us know how the rest of your experiments go.

Brian.

[JimH]

Thanks for reporting what worked.

[mwillems]

Awesome.  I'm glad to hear it's working correctly for you.  I would think you'd want to do some sort of long term playback over at least 4 channels to make sure there's no timing drift as has been previously reported.  Maybe an hour or two?

This is worth watching out for; it might also be worth your while to take some measurements to make sure everything is really time-aligned from the get go or just "close enough."  Things can sound "in sync" but be far enough out of sync to create goofy phase anomalies that you can hear but don't necessarily sound like sync issues (specifically drift of a millisecond or two won't be audible as echo, but can be more than enough to wreck the bass response where the mains and the sub crossover). 

The easiest way to measure the time alignment is (once you've got the Sub setup) to do a fullrange log sweep and see what happens where the signal moves from the sub to the mains.  If you get a smooth transition then your time alignment is solid, but if you see wildly variable results than you're hitting the issue that typically rears it's head with trying to aggregate multiple dacs: variable time drift between the DACs.

If this works to within millisecond tolerances out of the box on Mac, that's the first thing I've encountered that would make me want to buy a Mac    Windows surely can't do it, and in my experiments neither can Linux.  You're in new territory, but it's exciting territory. I look forward to hearing your results.

[Langston]

A measurement challenge?!

Looks like you may be in the market for a Mac - Merry Christmas! :))

Seriously though, that was great idea - thanks for pointing it out. The bottom line is that if you do device aggregation for output into a single audio system, you'll want to use the same model of D/A converters to keep latency the same. If you have fancy measurement gear and can do open loop phase testing like the following, you could add a straight delay to the early bird - but I'm not going to bother. KISS. :)

The clocks between two wildly different converters were sync'd perfectly at the 96kHz test SR. I made at least a dozen measurements with an Audio Precision APx515 comparing the left analog output of the DAC2 with the right analog output of the Oppo and vice-versa. I show (4). The take away is that the 50 point 10Hz - 45kHz log stepped sine sweep showed identical results measurement after measurement. That means the phase difference between units is due to a constant time arrival difference, i.e. a constant delay. This would not be the case with unsync'd clocks as the phase traces would be different most of the time. You'll notice the traces don't line up at HF, but that's just measurement noise. There arent many points in a stepped log sweep at HF - I can tell they are identical. It would be nice if I could do high resolution closed loop measurements through MC. I've read about "live" mode or whatever, but at this point people have too much trouble with it for me to trust measurements even if I could figure out how to do it. Plus I prefer making measurements that exercise the DUT in exactly the same way it's used when possible.

Both converters have truly excellent specs and sound wonderful except that the Oppo has a typical home audio low voltage (4.2V max) and high-ish impedance output. The DAC2 is much nicer but costs 2.0x more and has 0.2x the functionality.

RMS levels of the converters with their gains at 50%, 80% MC internal volume, stimulus peaks at 0dBFS:

DAC2 Oppo Levels

THD+N at these gains:

DAC2 Oppo THD+N

And the moment you've all been waiting for; the time domain. The Oppo is about 0.5ms late to the party (180˚ at 1kHz for example). This would be more than close enough for a sub to low crossover, but it'd get ugly at mids/highs without delay compensation. The prefect horizontal traces are measurements of the converters' own left and right channels. It would be bad news if a converter didn't at least agree with itself. :)

DAC2 Oppo Phase

MC is amazing - OSX has it's points too. :)

---

PS: I don't have the image thing figured out. These lovely vector PDF's are less than half the size of the 700KB limit and I had to put them in as links instead. No biggie, maybe the inclusion of PDF in the acceptable file type attachment list is incorrect.

---

PPS: You're right Brian - I found the same thing in that MC takes control of the Audio MIDI Setup and pushes output channels (L, R, C, Sub, etc.) to their industry standard destinations no matter what adjustments you make in OSX. This proved to be a deal breaker for me with using (4) of the Oppo's channels aggregated with (2) from the DAC2 in my 5.1 setup. I wanted the Oppo's far superior electronics in its first two outputs to drive my LS and RS loudspeakers. Instead, MC forces those channels to Center and Sub when the DAC2 is taking the first two L and R slots. The PEQ section of MC allows you to move input channels around, but the outputs that go downstream to the converters remain fixed to standard positions. You can lie to MC, but then Room Correction gets weird and everything downstream of the lie in DSP Studio is messy. The same D/A's for all channels in use will solve both this and the latency issue. :)

[mwillems]

A measurement challenge?!

Looks like you may be in the market for a Mac - Merry Christmas! )

Seriously though, that was great idea - thanks for pointing it out. The bottom line is that if you do device aggregation for output into a single audio system, you'll want to use the same model of D/A converters to keep latency the same. If you have fancy measurement gear and can do open loop phase testing like the following, you could add a straight delay to the early bird - but I'm not going to bother. KISS.

That's fantastic. FWIW, the identical DACs piece is no guarantee outside of the Mac environment.  I've seen even identical DACs showing variable clock drift in Windows, but it sounds like you're not seeing variable drift even with different DACs with the Mac Aggregator which is very encouraging.  The next question is whether the Mac Aggregator would work equally well with cheapo USB DACs as it does with multi thousand dollar kit.  I will endeavor to test as soon as I can find a device running OSX  

The clocks between two wildly different converters were sync'd perfectly at the 96kHz test SR. I made at least a dozen measurements with an Audio Precision APx515 comparing the left analog output of the DAC2 with the right analog output of the Oppo and vice-versa. I show (4). The take away is that the 50 point 10Hz - 45kHz log stepped sine sweep showed identical results measurement after measurement. That means the phase difference between units is due to a constant time arrival difference, i.e. a constant delay. This would not be the case with unsync'd clocks as the phase traces would be different most of the time. You'll notice the traces don't line up at HF, but that's just measurement noise. There arent many points in a stepped log sweep at HF - I can tell they are identical. It would be nice if I could do high resolution closed loop measurements through MC. I've read about "live" mode or whatever, but at this point people have too much trouble with it for me to trust measurements even if I could figure out how to do it. Plus I prefer making measurements that exercise the DUT in exactly the same way it's used when possible.

Unfortunately there is no JRiver loopback mode for Mac, which is a shame because the loopback would actually be closer to the real use case because it runs the measurement through JRiver's audio path.  But we're as close as we're going to get to testing the actual conditions on a Mac and your results are impressive.  

As a side note, if you do wind up using a windows machine at some point in the future, the JRiver loopback mode(s) work quite well for measurements once you get the relevant mode setup correctly (IME). I used it for measurements to setup my bi-amped system with no real difficulties, and it was crucial to be able to measure with JRiver's crossover filters in place. I still use it regularly for measurement in other contexts too.  But it hasn't made it's way to OSX or Linux yet unfortunately.

The HF only seriously diverges above 20K, so the divergence may actually be real and just an artifact of the different aliasing filters used by the two different DACs (the effects of aliasing are most pronounced at the highest frequencies).  In any case, real or not, the sync is very tight in the audible band (I don't much care about phase divergence in the ultrasonics).  Very nice indeed.

And the moment you've all been waiting for; the time domain. The Oppo is about 0.5ms late to the party (180˚ at 1kHz for example). This would be more than close enough for a sub to low crossover, but it'd get ugly at mids/highs without delay compensation. The prefect horizontal traces are measurements of the converters' own left and right channels. It would be bad news if a converter didn't at least agree with itself.

Fixed delay is trivial to fix in JRiver.  There's a delay filter with arbitrary precision in the PEQ banks, so that's no problem at all.

PPS: You're right Brian - I found the same thing in that MC takes control of the Audio MIDI Setup and pushes output channels (L, R, C, Sub, etc.) to their industry standard destinations no matter what adjustments you make in OSX. This proved to be a deal breaker for me with using (4) of the Oppo's channels aggregated with (2) from the DAC2 in my 5.1 setup. I wanted the Oppo's far superior electronics in its first two outputs to drive my LS and RS loudspeakers. Instead, MC forces those channels to Center and Sub when the DAC2 is taking the first two L and R slots. The PEQ section of MC allows you to move input channels around, but the outputs that go downstream to the converters remain fixed to standard positions. You can lie to MC, but then Room Correction gets weird and everything downstream of the lie in DSP Studio is messy. The same D/A's for all channels in use will solve both this and the latency issue.

There's a filter in PEQ that will fix this.  The Order Channels filter will let you remap channels without any issues with Room Correction or downstream consequences.  It just reorders which channels get mapped to which output.

Thank you very much for the measurements and the effort writing them up!

[blgentry]

Very nice Langston!

To add to what MWilliems says:  There are two different PEQ tools that mess with channels:  Mix Channels and Order Channels.  Mix lets you do all kinds of interesting and crazy stuff including mixing, copying, and moving.  Order Channels just swaps them around.  MW was WAY more experience with this than I do.  I just wanted to point out that the tool he's recommending is not the Mix Channels tool.

Brian.

[JimH]

Who is MWilliems?

[blgentry]

^ <sigh>  MWillems.  No extra "i'.  Sorry.

Brian.

[JimH]

Who is MWillems?

and you say you are a UNIX guy.

[mattkhan]

That's fantastic. FWIW, the identical DACs piece is no guarantee outside of the Mac environment.  I've seen even identical DACs showing variable clock drift in Windows, but it sounds like you're not seeing variable drift even with different DACs with the Mac Aggregator which is very encouraging.  The next question is whether the Mac Aggregator would work equally well with cheapo USB DACs as it does with multi thousand dollar kit.  I will endeavor to test as soon as I can find a device running OSX  

FWIW I was curious about this so googled and came up with this link -> http://apple.stackexchange.com/questions/59390/what-is-sound-drift-correction-on-os-x-and-how-should-i-use-it

The linked thread indicates that this means that "drift correction" is really resampling to reclock to the master clock. It sounds like jack can do this too (on linux) - http://jackaudio.org/faq/multiple_devices.html

[mwillems]

^ <sigh>  MWillems.  No extra "i'.  Sorry.

Brian.

No worries, my last name is a classic "false friend" name (it looks like a familiar name, but isn't). 

One of my earliest childhood memories is of my father spelling our last name to someone 

FWIW I was curious about this so googled and came up with this link -> http://apple.stackexchange.com/questions/59390/what-is-sound-drift-correction-on-os-x-and-how-should-i-use-it

The linked thread indicates that this means that "drift correction" is really resampling to reclock to the master clock. It sounds like jack can do this too (on linux) - http://jackaudio.org/faq/multiple_devices.html

In my linux testing I tried a variant of method 3) in the Jack article with no success.  I'll try a few of those other methods and see how far I get (as it's significantly easier for me to test on Linux than on OSX).

[Langston]

Oh well, looks like MWillems can save his money for something other than a Mac. :(

I really didn't like what I said earlier about being sure there were no phase differences at HF when there were so few data points being considered in that 50 point stepped log sweep. It was obvious that this was true up to about 5kHz or so given a reasonable density of data up to that point, but afterwards...

So I designed a custom linear stepped sweep with 300 points. Took about a week to execute, but the truth of the matter was revealed. For sake of clarity I inserted a delay on the DAC2 to line it up with the Oppo's additional latency:

I noticed that delay resolution is reasonably limited by the SR, 96kHz or 0.01ms in this case (T=1/SR). MC rejected my attempts to add intersample delays, also called arbitrary precision, which is a cool use of math to achieve greater resolutions than the SR would normally allow. This is quite useful in acoustic measurement systems when operating at 48kHz SR's for good LF resolution, but also post processing absolute phase and related stuff that depends on µsec timing. I can't think of how it would be a helpful addition to MC.

Inconsistent results occur above ≈5kHz.* This won't be audible in many situations, but unacceptable in others such as HF crossovers. There's still hope that good D/A's of the same model may work properly in aggregation. I'm going to see if Benchmark will loan me a couple of DAC2's to find out.

DAC2 Oppo Phase (high resolution)

I appreciate all the education you guys have so graciously offered - it's been a huge help given this is day 5 with the first digital media software other than iTunes I've ever used. I'm never going back. Obviously. :)

* If splitting hairs, more like 200Hz - see my next post.

[mwillems]

Inconsistent results occur above ≈5kHz, but the following link offers an example. This won't be audible in many situations, but unacceptable in others such as HF crossovers. There's still hope that good D/A's of the same model may work properly in aggregation. I'm going to see if Benchmark will loan me a couple of DAC2's to find out.

That is a little discouraging, but I'll keep my eyes peeled for a two of the same device comparison.  I'd need to test with an actual crossover handoff to be "sure" in any case, but it looks like it might be possible if the frequency is low enough.  I'm pretty happy with my current 8-channel DAC, so I'm not in a huge hurry to grab a Mac (my bi-amped system is sorted for the foreseeable future), but it would be nice to have an answer for the folks that show up here looking to aggregate DACs to create a budget system.

I appreciate all the education you guys have so graciously offered - it's been a huge help given this is day 5 with the first digital media software other than iTunes I've ever used. I'm never going back. Obviously.

The DSP capabilities in MC are really second to none in the media player space, and better than a lot of professional VST software floating around.  It's what sold me on MC and like you I never looked back 

[Langston]

Another observation... Warning, this is useless information that will only entertain geeks. Like us. :)

I'm so used to living in the acoustic world when it comes to measurement that I have a habit of extending the "close is the same" mentality to the electrical domain, which is wrong.

I also keep getting spanked by the repeatable exactness of the Audio Precision hardware - the small differences are actually real differences. Again I made an error in saying the phase was the same up to about 5kHz. It actually isn't, it's the same up to about 200Hz if you zoom in and look closely at the repeated measurements. This area has the majority of the log spaced 30 sine wave points that were spread across the huge range of 10Hz - 45kHz. You see a curve because the software plays connect-the-dots between the data points.

DAC2 Oppo Phase (30 Log Points)

The separation becomes much clearer when compensating for the latency difference and dialing up the measurement resolution. If you enlarge the vector PDF phase plot, you can see that the beginning of the sine wave from the Oppo starts showing up later (negative phase) than the beginning of the sine wave from the DAC2 around 200Hz.

DAC2 Oppo Phase (300 Linear Points)

Since both D/A converters show perfect phase alignment between their own channels, the source of this variation lies entirely with the only guy left in the room, the OS.*

* I just thought of something. Maybe the OS isn't at fault, or only partially at fault. These phase plots have been one channel relative to the other since I've been doing open loop measurements, if the absolute phase is squirrelly on one or both of the units the OS could be innocent. I can do closed loop measurement on the D/A's. This horse isn't quite dead yet.

[Langston]

I figured it out. This'll be my last post on this topic.

For the record, OSX's aggregate devices feature sync's the clocks perfectly.* In this one regard at least, OSX rules.

Oppo lied about the audio quality of their flagship player. It's consumer grade crap. I'm not going to bother going over the noise, crosstalk and other specs I measured in this thing (middle of the road performances BTW) - I'm just going to cover what is relevant to this topic - time synchronization.

One of the Oppo lies is in their noise performance. Instead of designing low noise circuits, they put in an "auto-mute" "feature" that you can't bypass. This mute circuit has a threshold that Oppo thinks will open with music quick enough that the user won't notice, which may be the case, but it also totally mutes and shuts off the converter circuits less than a second after playback levels drop below the threshold.

Every time the converter circuits wake up again they recalibrate to a slightly different latency. The Oppo channels all follow the same latency, but this thing is a moving target for OSX's aggregate devices clock sync - yet OSX still manages to keep up with it. But this means that you need a slightly different delay compensation for the HF in DSP Studio every single time this occurs - in other words, you can't successfully aggregate the Oppo with anything else.

This insane behavior was screwing up my earlier measurements and making it look like OSX was at fault. For example, the stepped sine sweeps have a one second gap between each frequency point, thus the Oppo was going to sleep and waking up at a slightly new latency at every single step! That's the reason for the wiggles in the phase curve that turned into wild swings at HF.

I managed to keep the Oppo awake with 5 second long continuous sweeps in a closed loop measurement feeding its digital inputs (both optical and coaxial gave identical results). In the following I show (8) consecutive measurements with no changes between measurements - I just kept hitting the measure key. I've yet to see the Oppo produce the same latency twice.

Oppo Impulse Responses

So how do you measure something that won't stay still between sine steps? Use another open loop calibrated stimulus, this time I chose a multitone with 50 sine tones that all occur at once, so the full passband is exercised for a couple of seconds and then it ends. This worked well and kept the Oppo from falling asleep, thus I was able to get stable phase plots that were indicative of a pure delay. These phase traces are of the Oppo in reference to the DAC2, in other words, the APx box had the output of the DAC2 going into its Ch 1 analog input and the output of the Oppo going into its Ch 2 analog input.

In the following, I again show (8) consecutive measurements and the phase plot kept moving just like the IR's did with each new measurement. I also included the frequency response of the DAC2 (blue) and Oppo (brown) in this plot.

Oppo Phase

An amazing observation is that OSX managed to properly sync the DAC2 with sub-millisecond latency to a moving target with more than 200ms latency! Just for interest, here are (8) consecutive measurements for the DAC2. They all overlap perfectly. Everything in this thread has been at a 96kHz SR.

DAC2 Impulse Responses

* Not consistently true unfortunately. Read my following posts in this thread before committing your time and money to this.

[blgentry]

It's sort of amazing that you know so much about measurement and happen to have started a thread on a subject that requires some measurements to be made.  This is nice work.

How did you ever figure out that the Oppo was turning off and recalibrating between silence?

Most importantly, is your conclusion that aggregate devices *can* be used properly with MC and OSX to run systems and have predictable time delay between them?  I.E. something that you can compensate for once and have it be perfect thereafter?

Brian.

[Langston]

You’re such an encouragement Brian - thanks for your kind words. :)

Please ignore the stuff below under "background" if you want, it just seems like you’re scratching your head a bit about my measurement background combined with my newbie status with MC.

Answers:

1. I’m convinced at this point that OSX absolutely does what they advertise with aggregate devices. There is sample accurate synchronization going on using the audio data paths to the D/A’s, just as routinely done in pro sound where the clock sync is normally derived from the first digital input to a DSP processor, etc. I deleted the Oppo and aggregated the DAC2 with a silly little USB flash-sized D/A called a Dragonfly and it works perfectly, though measures somewhat worse than the Mac’s built-in audio. No hiccups ever. I’m so convinced I’m about to lay down some real loot to buy another pair of Benchmark DAC2 units. The key is to do what you said - get D/A’s that don’t play games with their latency, which I’d assume the Oppo is a rare offender. It’s possible that this obscene behavior is typical of all/most video playback gizmos, I don’t know - new realm for me.

2. Figuring out the Oppo shenanigans happened pretty much the same way I figure out all things audio; several iterations of "What the heck?!" "I wonder if... Nope, must be something else". Until it hits. The way it hit me was making closed loop measurements from its digital input to its analog outputs. I kept getting different phase and group delay plots, then I looked at the IR’s that I showed in the last post where I lied and said it was my last post. Then I saw dreadful magnitude results from shorter continuous sweep times. When I chose 1 second, I got a magnitude response that muted at about 10kHz and started again around 25kHz. A big HF hole. Why? The Oppo’s gating threshold was timing out because it seems to look at mid frequencies* (not uncommon). When the sweep moved past this mid frequency for long enough it muted! When it turned back on the IR arrival changed, and added a 2nd baby IR with the very HF behind the first large IR that was missing it. This happened every time. Piece of crap. Testing this theory I went to something like pink noise that exercises the entire passband simultaneously (generally what the Oppo engineers expect of music). Those measurements were proper in all cases, but every new measurement had different latency results of course. So every song you play on this thing will have a different latency! Took me about 2 hours to figure all this out - I’m no genius, but do have pit bull tenacity. :)

Background:

The deal is that home audio is new to me, I’ve been running a concert production and install company for about 15 years and I’m into the bleeding edge of excellence - as you guys are or you’d be using iTunes! :)

A family member had a medical issue happen that has kept me at home for quite a while now and I needed more to do - so I bought several air guns (pellets) and restarted an old flame with target shooting in the back yard and trained my sights on home audio. For years I’ve been trying to bring world class sound experiences to large audiences yet didn’t have an interest to try the same at home.

I’ve been using fancy hardware processors in live sound for years trying to tame the time domain of loudspeakers as well as standard frequency domain stuff. A few years ago I started experimenting with inverse filters (convolution), but in live sound you can not get away with much latency, particularly with the fact that about 5ms or so is already built into modern digital consoles, digital snakes, digital wireless, etc.

So you have to carefully select which areas of the passband to apply time domain correction to and which to stick with minimum phase correction (some call this mixed filtering). The latency constraints of live sound are largely thrown out the window with prerecorded playback, which is fun - but I’ve found that what I learned with the constraints of live sound have been hugely helpful with my new little hobby that’s so nicely facilitated by a $50 piece of software! I purchased a few miniDSP OpenDRC boxes at $350 apiece a couple of months ago and got results from a few home loudspeaker models that impressed me greatly, but these boxes have several serious design limitations to meet their price objective - then I found MC a week ago. No compromises required. Installed it on several of my home computers - no need keep buying boxes that can only talk 48kHz. DSP Studio is a geek’s playground dream come true. :)

Anyway, I’ve spent more on measurement gear than most spend on cars, some on houses. I’ve studied under some of the best there are. I’m kind of into it. Here’s a couple of reviews I did before I had to go off grid due to the medical stuff. I’m NOT trying to impress anyone, it’s just representative of what I do for a living. I’m the student here and you are my teachers. :)

1. A review of a few of Dave Gunness’s wonderful loudspeakers

2. A digital wireless microphone review

* I have to be wrong about the frequency guess because the sweep moves from low to high and I do get consistent LF results. It may be a simple RMS level detector. With the continuous log sweep there's much more RMS power at LF that smoothly decreases until the end point is reached. The gap where the muting occurred did vary on each measurement, thus at HF the measurement stimulus must have been hovering right at the muting threshold. Whatever the case, the Oppo gets a failing grade on playing well with others.

[blgentry]

Wow, thanks for all the background information.  It's neat to hear all that.  ...and it's super encouraging to learn that aggregate devices appear to measure "perfectly" in the time domain.

It's interesting that time is disregarded so often in measurement.  I've learned through the years that you have to get the time domain right first, or everything else just doesn't matter.

I've been a student of acoustic measurements for a long time, but I've had very limited access to good measurement equipment.  Back in the early 90s, I worked for a company that had an original TEF and later a TEF20.  I used the TEF20 a bit, but I never felt like I truly understood enough about the system.   I used it to decent effect while building a pair of speakers and adjusting them after the initial build.  Still, I always wanted to really learn the ins and outs of "the TEF cube".

Back when this stuff was sort of new, I read a bit about the MLSSA, and other systems, but I always came back to the TEF.  When I got my degree in Electrical Engineering, I made my senior project to build a small version of the TEF.  I got just far enough to demonstrate that I had done some good work and got an "A".  But I was FAR from a workable measurement system.  Very far. 

These days the REW seems to do 70% of what the TEF did and it's essentially all software.  I don't now much about the state of the art these days.  My exposure to Audio Precision is limited to their amplifier analyzer and some early acoustic stuff that was not valuable in an acoustic environment because it couldn't discriminate time.

Anyway, it's just really cool to read this stuff from someone who's really used it.  ...and now is applying it to my absolute favorite media player and library manager:  JRiver Media Center! 

Thanks,

Brian.

[Langston]

Hey Brian:

Some sad news... Realizing that some people may make purchase decisions based on my data, I rebooted the computer, removed the aggregate device, put it back in, and did about 50 measurements to prove to myself nothing would change.

It actually continued to work, but the DAC2 required a slightly different delay to line up with the little Dragonfly USB card. This is a deal killer. MWillems was right to be skeptical.

One needs to use a hardware solution with a single connection to the computer to be confident that things won’t go out of sync. :(

---

BTW, Richard Heyser was a hero of mine and I’ve not gotten through everything he wrote, but I have most of it and the revolution he started with heterodyned swept sines changed the world of audio forever. I so wish he was still alive - I never got to meet him. I actually own a TEF 25 that someone gave me. I played with it a bit, but Goldline’s software is too buggy and the company and market too small to fix it apparently. It’s still pretty amazing.

Though Heyser developed hardware based tracking filters to follow the sine sweep, he wrote about the possibility of a software implementation and several measurement software makers have actually pulled it off - the same amazing noise rejection using normal sound cards. Ivo, a brilliant computer scientist and professor in Croatia developed ARTA and its STEPS module performs TEF measurements. The whole package is about $150 and it’s Siegfried Linkwitz’s primary measurement platform and that guy can have anything he wants.

Doug Rife, the inventor of MLSSA (my first measurement system, c. 1988) developed a stereo to 4.1 high-end surround sound scheme that he wrote a paper on that I have - it’s the first thing I’m going to try once I get a stable multichannel D/A converter setup figured out. I was planning to implement it the way Doug did - the painful way using hardware, but MC can do it all within DSP Studio! I’ve yet to be impressed with a 2 channel to surround sound upmix scheme, hopefully that’s about to change. I keep going back to 2 channels - I want more reality, not special effects.

[blgentry]

Thanks for the tip on ARTA.  I've been reading up on it. 

Brian.

[Langston]

It turns out that it is possible to implement an aggregate device with proper time sync on the Mac.

The D/A converters need to have synchronous inputs. That means the D/A converter has the ability to lock to the source clock. This is the way the professional sound reinforcement systems I'm used to function - they have to because there's a lot more than just audio going through those Ethernet cables that the components have to have bit perfect understanding of (gain control, phantom power switching, EQ adjustments, etc.).

The vast majority of consumer devices with digital inputs have asynchronous input which eliminate the possibility of bit perfect transfer, but makes interconnection foolproof. The latter trumps the former in the home market and reduces the cost of support calls to the mfg.

The Benchmark designer offered this explanation:

"Aggregation of USB devices is generally not possible when the devices operate in the "Asynchronous Mode" because the conversion clock is supplied from the external device and not from the host computer. This means that each D/A converter would be running from an independent clock and this generally prevents them from being aggregated into a single virtual output device."