Large Random Clock Drift Variance Solutions

[Tim]

I am using the following configuration to measure a 3 way configuration in the AL XO 6.11 demo with a fixed UMIK-1 and speaker locations.   Even though the physical locations are fixed, I get up to 1ms delay (12+ inches) variances for a given driver from measurement to measurement (typically @ 0.4X) variances.  This happens with or without the “Use Clock Drift Correction” enabled.

 

·         AL XO 6.11 Demo

·         Win7-64 Ultimate, i7 CPU, 16GB DDR3, no other applications running

·         miniDSP UMIK-1 USB mic (48KHz, 24-bit)

·         OKTO Research DAC8 PRO USB DAC

·         ASIO4ALL with lowest latency settings

·         Channel Remapping: 6, 4, 0, 5, 3, 1

 

The center of the tweeters are physically within 1/8” of an inch of being equal distant from the tip of the mic, yet some measurements indicate they are @ equal distant and others indicate the right is 0.7Xms (or more) away from the mic than the left.

 

Mitcho pointed me at his thread where he was able to achieve 0.02ms variance which is much smaller than I am able to achieve with the UMIK-1.

 

Question:  Does the Measurement Window show the corrected or uncorrected delays ?

 

If it is the corrected delays, is there any idea on how to remedy these large random variances ?  I have tried numerous ASIO4ALL settings.  The lowest latency settings still vary over multiple measurements.

 

I see miniDSP has a new UMIK-2 (that is currently sold out) which has lower self-noise and up to 32-bit/192KHz sample rates, but it is still USB with its own clock.

 

The OKTO DAC8 PRO has stereo AES/EBU outputs (that are unused).  Could the clock on the AES/EBU output(s) be used to sync to an analog mic configuration ?  If so, what products would be recommended to sync by the AES/EBU clock ?

 

Thanks much.

 

[Bernt Rønningsbakk]

Hi Tim,

 

The measurement window shows the uncorrected delay.

 

Try Asio4All with highest latency settings, and use high latency settings in dac and mic if you have the option.

 

Keep the clock drift correction enabled. There will be clock drift between the dac and the mic.

 

Disconnect anything else from the USB, turn off all programs that may use Audio, including web browsers.

 

Check that the default Audio settings for the mic and the dac in Windows matches what you use for the measurement. It shouldn’t matter in theory, but better safe than sorry.

 

This is unlikely to be noise related, more likely to be caused by glitches in the audio path.

 

Try short sweeps (5 s) and see if you get consistent results then.

 

PS: The measurements you’re getting now are probably good for a frequency correction and possibly a time domain correction up to a few kHz. But Ideally we would like to see max 1 sample difference between the tweeters from measurement to measurement as long as the mic is in the exact same location.

 

 

Mvh,

Bernt

--
--
Audiolense User Forum.
http://groups.google.com/group/audiolense?hl=en?hl=en
To post to this group, send email to audio...@googlegroups.com
To unsubscribe, send email to audiolense+...@googlegroups.com

---
You received this message because you are subscribed to the Google Groups "Audiolense User Forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to audiolense+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/audiolense/000901d6cdb8%2455260580%24ff721080%24%40adelphia.net.

[Tim]

Hi Bernt,

 

All Windows settings were already at 24-bit/48KHz (so there should be no resampling) and “Clock Drift Correction” is enabled.

 

All other applications are closed.  Very little software is installed on this machine.

 

I retried ASIO4ALL with the highest latency settings (2K and 1K) as well as the DAC’s drivers and shorter 5 second sweeps with no apparent improvements.

 

I have a USB2 8-channel DAC, USB2 UMIK-1 and a USB keyboard.  I moved the USB2 DAC and USB2 MIC to the USB3 controller since it is 10X faster than USB2 and should be able to handle 2 – USB2 devices with more headroom than the USB2 controller.

 

Windows power management was configured for highest priority. 

 

All windows GUI eye-candy features are disabled for fastest performance as part of my normal builds.

 

Windows was configured to favor background tasks, so I changed it to favor foreground tasks.

 

I used the Windows task manager to increase AL XO from “NORMAL” to “REALTIME” priority.

 

With these changes, the random variances appear to have decreased. 

Please correct my math if it is wrong.  1 sample @ 48KHz is @ 0.02ms (48K * 1ms = 48 samples/ms, 1/48 = 0.02083 samples). 

Most measurements are now within 0.07ms (@ 4 samples) variance with some random anomalies.

 

Another trend is showing after running @ 30 new measurements.  The first 3 drivers on the left channel appear to have the least random variance.  The second 3 drivers on the right channel appear to have the most variance among the 30 measurements. 

 

The back of my room is asymmetric.  Would the short rear wall reflections cause these variances vs the long/open rear wall ?

 

My DAC is configured/wired with even channels as the left channel and odd channels are the right channel. 

 

The right channel fires diagonally across the room into the short left back wall (9 ft behind mic).  The left channel fires diagonally across the room into the long/open right back wall (opens into another room).

 

Here is a typical measurement now.

 

 

Here are a couple of random anomalies.

 

0.85 ms variance (42 samples)

 

137.02 ms variance (6,850 samples)

 

I will also get a momentary hang at the end of a measurement followed by a “file open error”.  This will persist until I restart the app.

 

FWIW,  I am using 2 – SATA3 SSD drives.  One for the OS and one for Data.

 

Sincerely,

Tim

To view this discussion on the web visit https://groups.google.com/d/msgid/audiolense/07c101d6ce15%24f0f017f0%24d2d047d0%24%40lyse.net.

[Omid Mostachfi]

Bernt, 

This question stems from my own ignorance, so I apologize if it's a stupid question:

I've noticed REW uses an acoustic timing reference (a chirp sound) before it starts a sweep, and again at the end of the sweep. Would a similar chirp help against sweep drift problems in AL?

Omid.

To view this discussion on the web visit https://groups.google.com/d/msgid/audiolense/000901d6ce75%24ebde53c0%24c39afb40%24%40adelphia.net.

[Tim]

There also appears to be a volume level component at play as well. 

 

If I run at -42dB (Good Dynamic Range), one driver appears closer than the other. 

If I run at -39dB (Excellent Dynamic Range), the drivers appear to swap front to back order.

If I rerun again at -42dB (Good Dynamic Range), the drivers swap back to the original front to back order even though nothing has moved physically (other than the voice coils).

To view this discussion on the web visit https://groups.google.com/d/msgid/audiolense/CANZ9VTCW11K%2BTvhe-CG4s-TBymeRQDUf8n4xehX0_hXec9DGAw%40mail.gmail.com.

[Bernt Rønningsbakk]

The low frequency drivers can have some explainable variations since they have a rounded top, but the tweeters should be consistent from measurement to measurement.

 

The file open error is puzzling. Do you get it every time?

 

If you send me the al.ini file I can look at the latest measurement you have sent it to the main form. You could also open a file named sweepmeasurement.wav that sits in the measurement folder and examine the waveforms. You can do a visual inspection using Audacity, which is open source. The recorded sweeps should have sinus shapes from start to finish, with some noise in the silent parts and of course varying magnitude elsewhere. If there are significant glitches in the stream you should spot one or more discontinuities. You can also listen to the sweep and verify that the recording contains what it should …. And nothing else.

 

 

I believe those measurements who are inside 4 sample variation are good to go, but you seem to be having reliability issues in your streams, so you need to pay attention to these values in the future also.

To view this discussion on the web visit https://groups.google.com/d/msgid/audiolense/000901d6ce75%24ebde53c0%24c39afb40%24%40adelphia.net.

[Bernt Rønningsbakk]

If this really is created by SPL differences, you have nonlinear issues in your system, causing the drivers to respond differently at different spl level. Moving objects in the room, some sort of external noise or malfunction could potentially produce such anomalies. For now I would guess that this is a spurious correlation.

To view this discussion on the web visit https://groups.google.com/d/msgid/audiolense/004801d6ce9d%24fb5e7ff0%24f21b7fd0%24%40adelphia.net.

[Bernt Rønningsbakk]

There is a timing reference in place already. One of the tweeters is swept twice. The theoretical timing difference between the first and second sweep is known, and the real difference is calculated with very high precision. A deviation from the theoretical sample count between the two is attributed to clock drift and each pulse is rearranged and moved in time accordingly.  I believe this is the best possible solution.

 

Mvh,

Bernt

To view this discussion on the web visit https://groups.google.com/d/msgid/audiolense/CANZ9VTCW11K%2BTvhe-CG4s-TBymeRQDUf8n4xehX0_hXec9DGAw%40mail.gmail.com.

[Omid Mostachfi]

Yes of course. I hadn’t used the drift correction option for a long time: I forgot about the extra sweep!

To view this discussion on the web visit https://groups.google.com/d/msgid/audiolense/083a01d6ceed%2460a4c370%2421ee4a50%24%40lyse.net.

[Tim]

FWIW, the subs are 12” cones with 18mm XMAS.

The mids are flat planar line arrays and the tweeters are flat NEO planars.  Both planars have very small XMAS (less than 2mm).

All 3 drivers are OB/Dipoles with side nulls and back waves (figure 8 radiation pattern).

 

The “File Open Error” randomly happens after the measuring procedure is about to complete.  It hangs for a few seconds, instead of finishing and then the “File Open Error” window pops up.  This time, it happened at the end of the 4^th consecutive measurement and a few more times during this session.  If there is an error log written anywhere, I would be happy to forward it if I know where and what it is.

 

 

I have attached the Al.ini in a zip file (found it in c:\ProgramData\...).  The frequency responses, IR and Steps look reasonable (else I toss them).  I am just concerned that the random driver delays between measurements would lead to a random time/delay/phase correction filter, thus defeating the purpose of the correction.  Measure twice, cut once =).

 

I will check out Audacity.  I haven’t used it but seen it mentioned on the web.

 

I did more tests today.  I stopped various startup services, killed background tasks not essential to measuring and monitored Windows time slices using the Windows Timer Tool.  The Windows time slices are the normal 15.6ms until the measurements start when they drop to 1ms and then switches back to 15.6ms after measurements complete.  The Windows Timer Tool allows setting the slices to 0.5ms.

 

My WEI numbers are:

 

CPU 7.5,   4 cores, 8 threads, 2.9GHz base clock, 3.8GHz max clock

Memory 7.6

Graphics 7.8

Gaming Graphics 7.8

Hard Drive 7.9

 

Is there a minimum/preferred hardware spec ?

 

Thanks much.

To view this discussion on the web visit https://groups.google.com/d/msgid/audiolense/082e01d6ceec%2455e987a0%2401bc96e0%24%40lyse.net.

[Bernt Rønningsbakk]

Hi Tim,

 

In the measurement that you attached, there was a recording capture delay of 240 ms (below). It can mean that something went wrong in the streaming. When I test now I get large delays  from time to time on my laptop either way, in addition to some artificial scratching sounds. And those measurements are not OK.

 

 

When the sweep sounds clean and the streams start without any problems, I get a left/right timing variation of 0.02 ms between measurements, and usually I get the exact same timing difference.

 

The file open error is sometimes misleading. It typically appears when no audio has been capture, when the microphone capture is not working. When you use Asio4All that could happen if the microphone is not activated in Asio4All.

 

I recommend that you examine the sweepmeasurementfile.wav.

To view this discussion on the web visit https://groups.google.com/d/msgid/audiolense/000001d6cf45%24aab044a0%240010cde0%24%40adelphia.net.

[Tim]

Bernt,

 

Can you point me at some documentation that describes the “Recording capture delay”, what controls it,  what values it should have as well as the 3 sub menu options (Capture Signal Earlier/Later/Reset)?  The lowest I see it is around 140.   

 

The sweeps sound smooth during measurement, but I haven’t analyzed them in Audacity yet.  If I hear anomalies in the sweeps,  I immediately cancel the session.

 

I have pretty much exhausted options (just went into the Device Manager and disabled onboard audio and all other unused sound devices) other than trying different hardware and another PC.

 

Thanks,

To view this discussion on the web visit https://groups.google.com/d/msgid/audiolense/004201d6cf59%24f758cfc0%24e60a6f40%24%40lyse.net.

[Bernt Rønningsbakk]

There’s no documentation about the delay.

 

Sometimes there is delay in the playback chain due to usage of dsp. But more common causes is that either the play or recording streams take considerable more time getting started than the other. When this happens, the recorded impulse response will appear earlier or later than what’s normal.  Ideally the two streams will start at exactly the same time, but with separate play and recording streams this rarely happens.

 

Glitches in the stream may lead to something similar, but also to errors in the measured impulses.

To view this discussion on the web visit https://groups.google.com/d/msgid/audiolense/002701d6cf7c%24a4ff2fd0%24eefd8f70%24%40adelphia.net.

[Fon]

I´ve never seen a recording capture delay of less than 200 ms, normally i get 203 or 204 ms. ASIO4ALL, using clock drift correction, no separate streams. I don´t know how to fix it, if there is something to fix.

To view this discussion on the web visit https://groups.google.com/d/msgid/audiolense/008001d6cfa2%245d327dd0%2417977970%24%40lyse.net.

[Tim]

After reading an ASIO/FlexASIO/ASIO4ALL thread from 2019 on AudioScienceReview, I experimented with FlexASIO’s interface to WASAPI EXCLUSIVE mode in place of ASIO4ALL hoping it would behave better.

 

I was able to get it to measure using WASAPI EXCLUSIVE mode but not KERNEL STREAMING mode (which is what ASIO4ALL is supposed to use). 

 

The “Recording capture delay” dropped from @ 140ms to 80ms.  The max random latencies of a given driver over multiple measurements increased by a factor of 3 (1.xms to 3.xms max, minimums were the same).

 

FlexASIO’s WASAPI EXCLUSIVE mode also got rid of the initial studders at the beginning of the 1^st driver measurement that intermittently happens in ASIO4ALL.

 

2 steps forward, 1 step backwards.

 

From: audio...@googlegroups.com [mailto:audio...@googlegroups.com] On Behalf Of Fon

Sent: Friday, December 11, 2020 2:33 PM
To: audio...@googlegroups.com

To view this discussion on the web visit https://groups.google.com/d/msgid/audiolense/CAFw7KMotH_hBKAoD1F%2BfjG0v%2BMiEmDB%2BGXXq-mvPDjayvwFSmg%40mail.gmail.com.

[Bernt Rønningsbakk]

Not something to fix if you get repeatable and valid results. And especially not if you get more or less the same result every time.

 

Mvh,

Bernt

To view this discussion on the web visit https://groups.google.com/d/msgid/audiolense/CAFw7KMotH_hBKAoD1F%2BfjG0v%2BMiEmDB%2BGXXq-mvPDjayvwFSmg%40mail.gmail.com.

[Bernt Rønningsbakk]

FlexASIO uses the same streaming library as Audiolense. And Wasapi in Audioleense is exclusive mode. Of course the library may have been implemented slightly different in FlexASIO.

To view this discussion on the web visit https://groups.google.com/d/msgid/audiolense/001201d6d0e1%24cd254880%24676fd980%24%40adelphia.net.

[Tim]

I believe the author of FlexASIO identified the library as PortAudio. 

 

http://www.portaudio.com/

 

I can use AL’s WASAPI in stereo mode, but not in 6 or 8 channel mode.

 

In 6 or 8 channel mode, AL displays a generic mismatch error (bit rate, channel count, etc., etc.), but 6 channel works in FlexASIO.  If I select “use separate record and playback streams”, AL generates a different error.

 

I will run FlexASIO’s debug logging feature to see what PortAudio is doing under the covers and if it is modifying any of the user supplied configuration options.  I can post both the log file and configuration file if it would be of any benefit to get AL WASAPI Exclusive to work in multi-channel mode as well as the intermittent startup stutter of the 1^st driver.

To view this discussion on the web visit https://groups.google.com/d/msgid/audiolense/010e01d6d168%2486a76690%2493f633b0%24%40lyse.net.

[Bernt Rønningsbakk]

That could be very helpful, Tim. Much appreciated!

To view this discussion on the web visit https://groups.google.com/d/msgid/audiolense/005801d6d175%2457cfe6f0%24076fb4d0%24%40adelphia.net.

[Tim]

Hi Bernt,

 

I just finished a second log pass to wrap my head around what is going on.  I will zip up the logs, config file and post them in another email, but here are the highlights.

 

FlexASIO has a text based Test App, a text based Device Dump App and a text based Runtime Logging feature.  A 1 minute runtime log (just enough to do a stereo 3-way 5 second sweep measurement) generates 345 pages of log traces (which probably doesn’t help latencies when enabled =).

 

The text Device Dump listing all of the system audio devices shows the desired WASAPI input and output devices that are entered into the config file.  The dump indicates a maximum of 2 output channels instead of the actual 8 channels so some of the driver information appears to be wrong.

 

Device index: 10

Device name: "Speakers (DIYINHK USB Audio)"

Default sample rate: 48000

Input: max channel count 0, default latency 0s (low) 0s (high)

Output: max channel count 2, default latency 0.003s (low) 0.01s (high)

Host API name: Windows WASAPI

Host API type: 13 [WASAPI]

WASAPI device default format: WAVEFORMAT with format tag 65534 [EXTENSIBLE], 2 channels, 48000 samples/second, 384000 average bytes/second, block alignment 8 bytes, 32 bits per sample, 24 valid bits per sample, channel mask 3 [Front Left, Front Right], subformat {00000001-0000-0010-8000-00AA00389B71} [PCM]

 

Device index: 12

Device name: "Microphone (Umik-1  Gain: 18dB  )"

Default sample rate: 48000

Input: max channel count 2, default latency 0.003s (low) 0.01s (high)

Output: max channel count 0, default latency 0s (low) 0s (high)

Host API name: Windows WASAPI

Host API type: 13 [WASAPI]

DEFAULT INPUT DEVICE for this host API

WASAPI device default format: WAVEFORMAT with format tag 65534 [EXTENSIBLE], 2 channels, 48000 samples/second, 288000 average bytes/second, block alignment 6 bytes, 24 bits per sample, 24 valid bits per sample, channel mask 3 [Front Left, Front Right], subformat {00000001-0000-0010-8000-00AA00389B71} [PCM]

 

The code uses a “Backend API Name”, a “Host API Index”, a “Device Index” and a “Device Name”.  The log dump shows it searches through all of the “Device Names” and then tests them.   It finds the proper “Device Name” and generates a channel mismatch error when comparing the config file entry of 8 channels to the device listing information.  FlexASIO does NOT appear to take the channel mismatch error as a hard stop, but more of a warning.  It appears to proceed to probe additional APIs and discovers there are actually 8 channels that work.

 

The logs indicate that it is finding and using the main 3 options (as well as the other options) identified in the config file before performing the sweeps.  You will see in the logs FlexASIO continually checks to see if the config file has changed to incorporate any option changes in realtime.

 

·         WASAPI (“backend” Host API index 2) - 'Windows WASAPI'

·         WASAPI mic input (Device index 12) - 'Microphone (Umik-1  Gain: 18dB  )'

·         WASAPI speaker outputs (Device index 10) - 'Speakers (DIYINHK USB Audio)'

 

12:24.22483544640 Found backend: PortAudio host API index 0 (name: 'MME', type: 2 [MME], default input device: 1, default output device: 3)

12:24.22483544640 Found backend: PortAudio host API index 1 (name: 'Windows DirectSound', type: 1 [DirectSound], default input device: 5, default output device: 7)

12:24.22483544640 Found backend: PortAudio host API index 2 (name: 'Windows WASAPI', type: 13 [WASAPI], default input device: 12, default output device: 11)

12:24.22483544640 Found backend: PortAudio host API index 3 (name: 'Windows WDM-KS', type: 11 [WDMKS], default input device: 16, default output device: 13)

 

12:24.22483544640 Searching for a PortAudio host API named 'Windows WASAPI'

12:24.22483544640 Selected backend: PortAudio host API index 2 (name: 'Windows WASAPI', type: 13 [WASAPI], default input device: 12, default output device: 11)

 

12:24.22483544640 Selecting input device

12:24.22483544640 Searching for a PortAudio device named 'Microphone (Umik-1  Gain: 18dB  )' with host API index 2

12:24.22483544640 Selected input device: PortAudio device index 12 (name: 'Microphone (Umik-1  Gain: 18dB  )', host API: 2, default sample rate: 48000, max input channels: 2, max output channels: 0, input latency: 0.003 (low) 0.01 (high), output latency: 0 (low) 0 (high))

 

12:24.22483544640 Selecting output device

12:24.22483544640 Searching for a PortAudio device named 'Speakers (DIYINHK USB Audio)' with host API index 2

12:24.22483544640 Selected output device: PortAudio device index 10 (name: 'Speakers (DIYINHK USB Audio)', host API: 2, default sample rate: 48000, max input channels: 0, max output channels: 2, input latency: 0 (low) 0 (high), output latency: 0.003 (low) 0.01 (high))

 

In short, the mismatch appears not to be real but an error in the driver description.  The logs will show the channel mismatch error and the subsequent progression to utilize the 8 channels.

 

Hope this helps.

 

Sincerely,

Tim

 

 

P.S.

FWIW, the dumps also seem to suggest the WASAPI EXCLUSIVE interface may have lower latencies than the KERNEL STREAMING, but I am not certain what they are basing their low and high estimates on.  It may be related to some configuration values.

 

 

From: audio...@googlegroups.com [mailto:audio...@googlegroups.com] On Behalf Of Bernt Rønningsbakk
Sent: Sunday, December 13, 2020 2:07 PM
To: audio...@googlegroups.com
Subject: RE: [audiolense] Large Random Clock Drift Variance Solutions

 

That could be very helpful, Tim. Much appreciated!

 

Mvh,

Bernt

 

 

[Tim]

Hi Bernt,

 

Logs have been emailed to your direct account.

 

Sincerely,

Tim

 

From: audio...@googlegroups.com [mailto:audio...@googlegroups.com] On Behalf Of Tim
Sent: Sunday, December 13, 2020 7:19 PM
To: audio...@googlegroups.com
Subject: RE: [audiolense] Large Random Clock Drift Variance Solutions

 

Hi Bernt,

--

--
Audiolense User Forum.
http://groups.google.com/group/audiolense?hl=en?hl=en
To post to this group, send email to audio...@googlegroups.com
To unsubscribe, send email to audiolense+...@googlegroups.com

---
You received this message because you are subscribed to the Google Groups "Audiolense User Forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to audiolense+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/audiolense/001901d6d1c7%24d43309a0%247c991ce0%24%40adelphia.net.

[Bernt Rønningsbakk]

It looks like you have uncovered a bug in PortAudio.

 

Thank you.

 

 

Mvh,

Bernt

To view this discussion on the web visit https://groups.google.com/d/msgid/audiolense/000501d6d1d8%24cad7f4e0%246087dea0%24%40adelphia.net.