Okto DAC8 update with DSP

[Angaria]

Has anyone had success dealing with the variable latencies of the dac8 across different channels? Maybe it doesn't matter much for bass management, but it's a problem for active crossovers and DRC.

 

[professorpolymath]

Has anyone had success dealing with the variable latencies of the dac8 across different channels? Maybe it doesn't matter much for bass management, but it's a problem for active crossovers and DRC.

What are these measured latency differences? Do they appear even without AVDSP firmware?

 

[fabriceo]

Hello
I think @Angaria you refer to a one-sample delay difference between AES1 and the other AS2,3,4 connector which was visible in some DAC8PRO early firmware versions.
normally upgrading to firmware V1.60 addressed this.

the AVDSP version (1.61) does not show this because the connector AES2,3,4 are just routed to AES1 (multiplexer) and not decoded as such with a specific cpu task.

The new upcoming version of the AVDSP (1.62) to be released this summer (still doing some hardening test on it) is now accepting AES2,3,4 as extra spdif/aes input to be enabled dynamically in the DSP program. Due to this new feature I have recently reviewed the synchronization algorythm and the time window has been adjusted to garantee that this one-sample difference will never happen anymore, even when a decimation by 2 or 4 is used (specific to AVDSP in case the DSP prog is longueur than the time available between 2 samples).

if you see the problem on your dac8pro, please upgrade to v1.60, if you still have a use case showing the problem please report to Oktoresearch so we can reproduce and potentially enhance the algorythm for the next release.

Many thanks for supporting us

 

[Angaria]

Appreciate your note @fabriceo . I have the 1.60 firmware and will let you know how the process goes. Have Mitch Barnett working with me, and he's seen many Okto dacs, so expect to have pretty definitive feedback.

 

[Angaria]

Here's the issue I'm running into with Okto, that seems to put it out of the running for an Active XO. Quite different results from three replicates.

In the case of the front left bass at 4.90ms in the first measurement and then 0.52 in the 2nd measurement means it is off by 4ms or 4 feet. Unfortunately, this affects both the timing and frequency response. And there is no way to know if any of these are actually correct. Seems like this has come up as an issue in the past too, with Okto. Have the 1.60 firmware. @fabriceo, any ideas on this? Haven't received any response from the Okto email, so appreciate it!

 

[dualazmak]

Since your "Front Right -Tweeter" always show 0.00 msec delay, I assume you were using the room air sound of "Front Right -Tweeter" as time-zero marker, right?

Your present objective/goal, however, would be relative time domain measurements of DAC8PRO's CH-1 through CH-8 analog outputs, right? If so, you need to eliminate any possible time-domain effect(s) of your amplifiers and/or SP drivers and/or USB-ADC-microphone; I mean you need to directly measure line-level 8-channel outputs from DAC8PRO using suitable ADC device (audio interface), you should not measure the room air sounds of SP drivers by microphone.

And I believe you need to avoid any loopback analysis into your source PC/Mac; the 8-channel analog signals (not the room air sound) from DAC8PRO should be recorded/analyzed by independent second PC/Mac (or by a synchroscope).

Alternatively, if you have 8-channel-capable analog sound "mixer", you may feed all the 8-channel signals from DAC8PRO into such sound mixer, and you can analyze the recorded "mixed" signal using independent PC/Mac for time-domain discrepancies and/or lack of reproducibility (possible random delay/latency).

Furthermore, you need to "validate" your method(s) and procedure(s) of time-domain measurements for accuracy and reproducibility. I mean if you intentionally give 10.000 msec delay by your DSP software for CH-3 and CH-4 of OKTO DAC8PRO against CH-1 and CH-2, then "your method" should (need to) exactly and reproducibly show/give 10.000 msec delay of CH-3 and Ch-4 against CH-1 and CH-2.

 

[mdsimon2]

Here's the issue I'm running into with Okto, that seems to put it out of the running for an Active XO. Quite different results from three replicates.

View attachment 466224In the case of the front left bass at 4.90ms in the first measurement and then 0.52 in the 2nd measurement means it is off by 4ms or 4 feet. Unfortunately, this affects both the timing and frequency response. And there is no way to know if any of these are actually correct. Seems like this has come up as an issue in the past too, with Okto. Have the 1.60 firmware. @fabriceo, any ideas on this? Haven't received any response from the Okto email, so appreciate it!

This looks like an issue with your acoustic measurement, not the Okto, please describe your measurement setup.

Also, what mode are you using the Okto in?

I only saw variable delay when using PureAES mode, but these delays were only 1-2 samples, so 0.01-0.02 ms at 96 kHz sample rate (https://www.audiosciencereview.com/forum/index.php?threads/okto-8-owner’s-thread.13899/post-684285). I haven't seen this issue since upgrading to FW 1.6.

Michael

 

[Angaria]

What leads me to be fairly confident this is due to the Okto, is that I've used the same laptop, mic (UMIK-1), audiolense version, amplifiers and this same exact process to setup a different pair of speakers in that same room. Had excellent results and - no delays as are now occurring. The only difference was swapping the dac (and this is an active setup). That other users had this same problem with the Okto, which was also resolved when moving to a different dac, seems like replication.

 

[DWPress]

That other users had this same problem with the Okto, which was also resolved when moving to a different dac, seems like replication.

I have not experienced this in my active 4-way setup. Can you share where others have had a similar problem with the Okto?

 

[dualazmak]

I too never experienced/objectively-found this sort of time-domain issue on DAC8PRO through rather intensive time-domain measurements on DAC8PRO's analog-line outputs by directly measuring the output signals using second independent PC and/or 8-channel-capable sound mixer device.

I believe something goes/went wrong in @Angaria's measurement setup and method and your objectives, I mean what would you like to measure?

In case if you=@Angaria would like to have more worthwhile responses from people onboard here on this thread, you need to share in detail your measurement/experiment setup and methods; otherwise, we (including myself) cannot give you any further comment or suggestion...

 

[JanRSmit]

Neither have i experienced delay issues with my okto8pro

 

[mdsimon2]

What leads me to be fairly confident this is due to the Okto, is that I've used the same laptop, mic (UMIK-1), audiolense version, amplifiers and this same exact process to setup a different pair of speakers in that same room. Had excellent results and - no delays as are now occurring. The only difference was swapping the dac (and this is an active setup). That other users had this same problem with the Okto, which was also resolved when moving to a different dac, seems like replication.

Single channel USB mics like the UMIK-1 are not capable of accurate timing / phase measurements. See warning below from the VituixCAD measurement guide.

Do you have access to a 2 channel ADC? Direct electrical measurements with a 2 channel ADC are the best way to show timing issues between channels.

Michael

 

[fabriceo]

Hi @Angaria as you can read from the replies, there are chances that the problem is not on the dac8pro, and I also confirm that such a big difference is even not possible as there is a single fifo buffer for the 8 channels and the usb host driver is made in a way that the 8 channels are multiplexed at each samples with a total of 24x8 samples per microframe at 192k.this garantee full sync across the 8 channels.

Hope you will find the cause and solution. The recommendation to test the electrical output directly with a sound card is good. Also you can do this with REW, excluding the crossover software from the setup.

If you want to experiment the possibility to do your full crossover and equalisation inside the DAC with the DAC8PRODSP firmware, please contact me and I d be happy to support your efforts
best regards.

 

[fabriceo]

Hello, just a quick update from my side as we are in the middle of the summer (well in some part of the world), things are progressing on the upcoming dsp version and I m continuing extensive tests and some optimisations. If you are interested in receiving this future version (more Mips, more functions) for crossover, equalisation, bass management up to 192k, just drop a PM or email to avdspproject at gmail describing your project and serial number and you will be entitled to receive it free of charge. After septembre, the business model may change for the new commers lets see
Enjoy the summer and the music!

 

[mvorchard]

@fabriceo do you really REALLY think my system could sound any better than it does now with your perfectly customized 1.61 version?

:-D

Many thanks man for all your work!

 

[Angaria]

Hello - talked with a few other individuals who have had exactly this same problem. The solution has always been to swap to something like the motu with a common clock for the mic and dac. It's not like I want to move away from the Okto, but it's not providing the required results at the moment. The motu should arrive Monday, so I'll see if that does the trick for me as well and report here.

Appreciate the very kind offer @fabriceo - my setup is very simple to replicate - audiolense 6.21 on a windows 11 laptop, with USB cables to okto and Umik-1 microphone. Have you incorporated audiolense in your testing of this issue?

 

[DWPress]

Single channel USB mics like the UMIK-1 are not capable of accurate timing / phase measurements. See warning below from the VituixCAD measurement guide.

So

audiolense 6.21 on a windows 11 laptop, with USB cables to okto and Umik-1 microphone.

With my Umik-1 I can confirm you have a problem but it is not related to the Okto. For timing/phase measurements I use my Dayton UM6 and Focusrite 2i2.

So others on the Audiolense forum had trouble with the Okto as well? Please inform us if your move to the Motu solves your problem.

 

[mdsimon2]

Hello - talked with a few other individuals who have had exactly this same problem. The solution has always been to swap to something like the motu with a common clock for the mic and dac. It's not like I want to move away from the Okto, but it's not providing the required results at the moment. The motu should arrive Monday, so I'll see if that does the trick for me as well and report here.

Appreciate the very kind offer @fabriceo - my setup is very simple to replicate - audiolense 6.21 on a windows 11 laptop, with USB cables to okto and Umik-1 microphone. Have you incorporated audiolense in your testing of this issue?

You will never be able to clock sync the UMIK-1 and Okto, although I would argue that is an issue with the UMIK-1, not the Okto. You will run in to the same clock sync issue with a MOTU interface if you use the UMIK-1.

If you have an audio interface with an AES / SPDIF output as well a mic / analog inputs you can use it to clock the Okto (either in PureAES or USB / AES mode), so that everything is sync'd, but again you need to use a XLR mic, not a USB mic. Your software DSP may have variable latency, so I would use an analog output from the Okto looped back to analog input of the interface as a timing reference, rather than an analog output of the interface that hasn't passed through the DSP. This should be fine as you are only using 6 channels of the Okto.

Using an interface for mic input and DAC duties may simplify measurements / clocking but interfaces typically lack the nice consumer oriented features of the Okto such as a big volume knob, IR volume control, trigger output and a large display.

Good luck!

Michael

 

[Angaria]

Thanks Michael and DWPress - I should be able to do as you suggest, because I purchased a beyerdynamic MM1 mic (XLR). Agree - it will be interesting to see if I can get the Okto working with an analog mic.

Do you have suggestions for an audio interface to sync both the analog mic and Okto, or can I use the Motu for that (in addition to trying it as a dac)?

In summary, seems there are two experimental setups:
Experiment 1: Audio interface (possibly the Motu) ->XLR mic and Okto (this could help verify the umik is problematic)
Experiment 2: Motu as a dac and also power for XLR mic during measurement (this will help see if Okto is contributing)

 

[DWPress]

The Motu will work great as a mic pre IF you connect it the way Michael explained. No sense tearing all your cabling off the Okto until you can try this simple verification process. As already stated, many of us use analog mics and a pre in conjunction with the Okto precisely because of the known issue with the Umik1 but the Umik is still helpful for other quick measurements like MMM.

Good luck....