[AudiocRaver]

John,

Thanks for such a great product!

Suggestion: The timing reference selection,

Preferences > analysis > impulse response calculation > timing reference

is not retained. It defaults to acoustic timing reference, which I never use, and I have to change it every time I start REW. Hopefully it would not be difficult in your next beta for you to make that selection be remembered between sessions.

 

[EarlK]

Hi Wayne,

Odd

I just checked this out.

Versions 5.17 & 5.18 both retain any Timing Reference selection made ( upon re-opening REW ).

Have you nuked your REW preferences ( then closed>re-opened REW ) and then checked for this behavior ?

I'm running Win8.1 Pro . You ??

 

[AudiocRaver]

Hi Wayne,

Odd

I just checked this out.

Versions 5.17 & 5.18 both retain any Timing Reference selection made ( upon re-opening REW ).

Have you nuked your REW preferences ( then closed>re-opened REW ) and then checked for this behavior ?

I'm running Win8.1 Pro . You ??

Good suggestion. I had uninstalled REW before installing 5.18, but not zapping the preferences. That did the trick! Thanks for the suggestion.

John, false alarm! My thanks for a great product bears repeating, though.:grin2:



Still on Win7-64Pro.

 

[AudiocRaver]

I am back. When I first followed the above suggestion, it worked. That was with Java drivers. After switching to ASIO drivers, ASIO4ALL, it is back to not being retained properly. No Reference is retained, Acoustic Reference is retained, but Loopback Reference is always switched to Acoustic Reference. Is there something else I am missing?

 

[EarlK]

I am back. When I first followed the above suggestion, it worked. That was with Java drivers. After switching to ASIO drivers, ASIO4ALL, it is back to not being retained properly. No Reference is retained, Acoustic Reference is retained, but Loopback Reference is always switched to Acoustic Reference. Is there something else I am missing?

That's very interesting Wayne since;

My successful retention of said Timing Reference is actually with ASIO selected and then using ASIO4ALL as the driver.

I'm using ASIO4ALL ( dedicated to just this notebooks builtin Realtek soundcard as an ASIO wrapper ) but;
- I currently have no input showing as connected ( or selected ) within REWs preferences ( it's auto-disengaged since there isn't anything plugged into the 1/8" jack ).

How are you using ASIO4ALL ( eg; creating a composite driver for 2 soundcards ) ?

 

[EarlK]

I still can't REW to drop the LoopBack Timing Reference when using ASIO4ALL with either

a composite driver created ( from 2 soundcards ) or

using the generic USB interface WDM ( I just plugged in / a Behringer UCA222 ) or

selecting 44.1K or 48K sampling rates ( among a few other changes made with the "Analysis" tab ) .


So :dontknow:

 

[JohnM]

If you are using a USB mic and have timing reference set to loopback, REW will change that to acoustic, since loopback is not possible with a USB mic. 'Using a USB mic' on Windows is assumed if a USB mic is currently plugged in, since Windows and ASIO4All went through a spell of not including the mic's name in the info returned when querying what was currently selected so there wasn't any way to know when the mic was being used.

 

[AudiocRaver]

AHA!



With a Umik-1 plugged in, the Acoustic timing reference is assumed. Remove the Umik-1, and the Loopback ref setting can be retained again. Sounds good, right?


BUT


My application uses an audio interface to give me a 2-channel digital output to a DDRC-22D, plus a Umik-1 for measurement and Dirac Live calibration. With the audio interface present, Loopback timing reference is easier for me. The assumption of acoustical reference with a Umik-1 is probably true 93.71% of the time, but almost never for me.


I would like to have the Loopback reference setting retained even when a Umik-1 is used.


John? Help?

 

[AudiocRaver]

John, I did not see your post until after my last post. Does my application not make sense as a valid way (although admittedly unusual) of having Loopback timing reference along with a Umik-1? I have done it before, and it does work.:innocent:

 

[AudiocRaver]

I understand that Windows (or The System) can introduce small (plus/minus a few microseconds) of relative timing error between the USB mic and the USB audio interface when making a series of measurements. In some critical applications that error can be a problem, in most cases it is not.

 

[EarlK]

Wayne,

The last time I tried that ( your configuration ) I ran into significant timing differences ( REW ran in succession within a single REW session ) on a fixed speaker driver ( ie; & the distances measured were unreliable and not to be trusted ) .

This was no doubt due to the two sound-cards having different internal clocks ( & not being synchronized to each other ).

So now I'm curious, can you achieve a consistent answer ( in distance ) when taking multiple successive readings with your composite SC, timing setup ?

If so, I think it's an aberration / and still believe Johns builtin "Positive opt-in Selection for a setup that's inherently inaccurate" makes good sense ( since it ought to cut down on questions from those who don't understand the issues at play here ).

 

[AudiocRaver]

Wayne,

The last time I tried that ( your configuration ) I ran into significant timing differences ( REW ran in succession within a single REW session ) on a fixed speaker driver ( ie; & the distances measured were unreliable and not to be trusted ) .

This was no doubt due to the two sound-cards having different internal clocks ( & not being synchronized to each other ).

So now I'm curious, can you achieve a consistent answer ( in distance ) when taking multiple successive readings with your composite SC, timing setup ?

If so, I think it's an aberration / and still believe Johns builtin "Positive opt-in Selection" makes good sense ( since it ought to cut down on questions from those who don't understand the issues at play here ).

So you have tried it too? Cool!

I love it when you guys get super thorough about this stuff!

My initial response to your question is that it is enough trouble to get this application working that it will not be undertaken lightly or accomplished accidentally. It is an advanced application, if you will. Anyone using a USB mic and an audio interface for timing reference will probably (???) know the risks.

For measuring drivers within a single system, the technique might not be appropriate. For relative speaker placement

How accurate or inaccurate can it be? I thought I remembered it being in the range of a few microseconds, but did not save a project I can refer to quickly. I am getting ready to make some measurements and will respond to your question in the next day or so.

 

[EarlK]

I'll be curious to hear of you experiences with this setup .

I'd also like to know whether ( or not ) the Mac OS is truly more accurate regarding timing drift ( since OS10 allows it's own version of a composite driver, called "Aggregate Devices" that will follow a single clock.

 

[JohnM]

In general I have not found Windows to maintain any relative timing relationship between different soundcards from one measurement to the next, but perhaps an ASIO4All-managed composite device gets around that. However, I think there are more people that could end up trying to make measurements with Loopback selected whilst using a UMIK in conventional fashion (and getting results that won't reflect what was intended) than people doing it deliberately to take advantage of a composite device setup. Given that, the once per session impact and the placement of a timing ref mode selector on the measurement dialog since 5.17 allowing easy change of mode, I think it is better leaving the behaviour as is.

 

[Savjac]

WHOA, I guess it is high time I read the directions and get mine to work properly !!!!

 

[AudiocRaver]

You guys win, big time. I glanced at it once, in another system, I don't remember it being this bad.

I ran 10 sweeps. The impulses ended up in two clusters. Total spread about 8 mS. The technique is totally unusable.

Thank you, John.