VB Matrix

[boxerfan88]

As requested by some members, starting a new thread on this recently released software called VB Matrix.

VB-Audio Matrix

VB-Audio Matrix, Real Time Audio Router by V.Burel

vb-audio.com

Setup guide:

VB-Audio Matrix Info + Setup Guide - VB-Audio's Forums

 

[boxerfan88]

<Cross-posting over to new thread.>

Just to share, in case it may help others. I managed to find a solution to the DAC clock drift issue.
I replaced ASIO4ALL with this newly released software called VB Matrix. https://vb-audio.com/Matrix/

So far so good ... no more DAC clock drift after 30-45mins of continuous playback.
Very stable and very easy to configure.

Sharing here some screenshots of the configuration...

Hopefully this could be useful to others trying to implement subwoofer crossover within foobar.
(I use the foo_subwoofer component)

 

[dualazmak]

Thank you for your starting this new important thread after our nice discussion initiated by your kind post here and thereafter on my project thread!
I have been intensively looking forward to having this kind of one-stop ASIO matrix I/O center of advanced-functionalities, stable, durable and nice-GUI!

Within a few weeks, I will test and evaluate VB Matrix in my sub audio system in my office upstairs using EKIO as one-stop DSP Center together, and if it would be OK and stable enough, I will proceed into incorporation of VB MATRIX as the replacement of ASIO4ALL (and hopefully VB Audio Virtual/HiFi Cables) in my main audio system!

I will be more than happy sharing my possible such "utilization reports" on this new thread.

 

[phofman]

There is a "master" icon with one of the output devices. It suggests the other devices are adaptively resampled to align to the master. That would be the correct way to handle multiple independent interfaces.

The same way OSX/pulseaudio+combine module/jackd + zita-ajbridge etc. do.

 

[dualazmak]

I Have not yet tested/evaluated VB-AUDIO Matrix, but will do within a few weeks.

There is a "master" icon with one of the output devices. It suggests the other devices are adaptively resampled to align to the master. That would be the correct way to handle multiple independent interfaces.

Thank you for your info; this sounds very promising and interest.

If you can kindly share your precious time for a while, would you please read my two posts on my project thread?

- Can I (we) temporarily synchronize outputs of multiple DAC units (each of them has own independent ASIO driver) in 10 micro second (0.01 msec) precision in DSP-based multichannel audio setup?: #783

- Can I (we) temporarily synchronize outputs of multiple DAC units (each of them has own independent ASIO driver) in 10 micro second (0.01 msec) precision in DSP-based multichannel audio setup? Part-2: Simplified experiments without using audio mixer: #804

Do you mean/assume that VB MATRIX can (quasi-?) synchronize multiple DAC units each of them has its dedicated ASIO driver?
If this would be really the case, we wound get much benefits from VB MATRIX for utilization of multiple different brand DAC units simultaneously in sync.

 

[phofman]

@dualazmak : Every adaptive resampling is a compromise to some extent in terms of time synchronization. Look at https://www.diyaudio.com/community/...-interface-options.395392/page-5#post-7423200 - I cannot find the source post which Henrik referred to but I read it too and AFAIR the time shift between the devices deviated around millisecs

 

[MCH]

@dualazmak : Every adaptive resampling is a compromise to some extent in terms of time synchronization. Look at https://www.diyaudio.com/community/...-interface-options.395392/page-5#post-7423200 - I cannot find the source post which Henrik referred to but I read it too and AFAIR the time shift between the devices deviated around millisecs

I am tagging @mdsimon2 as he might be the person @HenrikEnquist refers to in that post

 

[dualazmak]

@dualazmak : Every adaptive resampling is a compromise to some extent in terms of time synchronization. Look at https://www.diyaudio.com/community/...-interface-options.395392/page-5#post-7423200 - I cannot find the source post which Henrik referred to but I read it too and AFAIR the time shift between the devices deviated around millisecs

I am tagging @mdsimon2 as he might be the person @HenrikEnquist refers to in that post

OK, I already understood your point well, and I also have discussed intensively with @mdsimon2 on my thread here, here (his very detailed experiments and results showing sync drifts) and thereafter.

In any way, as I wrote here, here and here, I have already become reluctant in pursuing any further efforts for sync of multiple different brand DAC units simultaneously, since I now use OTKO DAC8PRO for full sync 8-Ch operation, and I will go into the pro-use "more than 8-Ch" DAC-ADC in case if I would seriously implement 12-Ch (or more Ch) simultaneous DAC processing in my multichannel audio project.

My coming test and evaluation on VB-AUDIO MATRIX, therefore, should be mainly focused on elimination of ASIO4ALL and possibly/hopefully also elimination of VB Audio Virtual/HiFi Cables by using VB MATRIX as ASIO routing center for feeding ASIO audio signals from any of the audio players (such as JRiver MC, Roon, Adobe Audition, Audacity, web browsers, etc.) into my system-wide one-stop DSP-EKIO, and then EKIO would feed XO/EQ/Delay-configured multichannel ASIO signals into one multichannel DAC unit through the dedicated multichannel ASIO driver, in my present case OKTO DAC8PRO having its dedicated 8-Ch ASIO driver.

I am hoping, under the ASIO domination by VB MATRIX, just similar to ASIO4ALL, EKIO would be able to select any of the available multichannel ASIO driver into target multichannel DAC unit, and it looks highly possible since @boxerfan88 has already successfully eliminated ASIO4ALL in his audio I/O routing.

 

[mdsimon2]

I am tagging @mdsimon2 as he might be the person @HenrikEnquist refers to in that post

Maybe, maybe not. I read this post and ensuing discussion -> https://www.diyaudio.com/community/...overs-room-correction-etc.349818/post-6578042 a while ago where someone attempted to use a mac aggregate device with drift correction in a crossover application and was unsatisfied with the result due to drifting stereo image.

I'll install VBmatrix on my PC and see how it works compared to mac. My guess is that it is similar in that it is probably OK for bass crossover applications but there is too much shifting at higher frequencies.

Michael

 

[mdsimon2]

Maybe, maybe not. I read this post and ensuing discussion -> https://www.diyaudio.com/community/...overs-room-correction-etc.349818/post-6578042 a while ago where someone attempted to use a mac aggregate device with drift correction in a crossover application and was unsatisfied with the result due to drifting stereo image.

I'll install VBmatrix on my PC and see how it works compared to mac. My guess is that it is similar in that it is probably OK for bass crossover applications but there is too much shifting at higher frequencies.

Michael

Gave this a try with VB Matrix, I see no evidence of adaptive resampling syncing when looking at 15 kHz tone. Not sure if there is another synchronization setting I need to use other than selecting a device as Master? As it stands now this seems much worse than mac aggregate device drift correction from a phase perspective.

Michael

 

[HenrikEnquist]

Maybe, maybe not. I read this post and ensuing discussion

That's what I was referring to! Specifically this post: https://www.diyaudio.com/community/...om-correction-etc.349818/page-87#post-6579441

 

[phofman]

Gave this a try with VB Matrix, I see no evidence of adaptive resampling syncing when looking at 15 kHz tone.

Simple adaptive resampling by sample dropping/adding a linearly-interpolated sample may result in the same capture image (what you see) and still prevent buffer issues (what @boxerfan88 sees). Many audio projects do that as it's simple to implement - e.g. gstreamer, mplayer when syncing incoming network stream to output alsa device, etc... Very likely single dropped samples would not be audible in real-world audio stream (but reliably ruin long-run averaging in REW RTA etc.)

 

[mdsimon2]

Simple adaptive resampling by sample dropping/adding a linearly-interpolated sample may result in the same capture image (what you see) and still prevent buffer issues (what @boxerfan88 sees). Many audio projects do that as it's simple to implement - e.g. gstreamer, mplayer when syncing incoming network stream to output alsa device, etc... Very likely single dropped samples would not be audible in real-world audio stream (but reliably ruin long-run averaging in REW RTA etc.)

Interesting. I looked at the RTA and it seems pretty stable but has a hiccup every 2-3 minutes.

Another data point is if I run REW sweeps and use loopback as timing reference with the "synchronized" DAC, the reported delay between the two DACs decreases over time until it resets at some point.

1:59:46: 30.7 ms
2:00:06: 29.6 ms
2:00:25: 28.5 ms
2:00:51: 27.1 ms
2:01:06: 26.4 ms
2:01:19: 25.7 ms
2:01:31: 25.0 ms
2:01:49: 24.1 ms
2:02:05: 23.1 ms
2:02:21: 22.3 ms
2:02:44: 21.1 ms
2:03:12: 20.5 ms
2:03:24: 19.0 ms
2:03:41: 18.4 ms
2:03:53: 17.5 ms
2:04:22: 16.1 ms
2:04:39: 25.6 ms
2:05:00: 24.7 ms
2:05:13: 23.9 ms

Does this behavior make sense to you? To me such drifting would indicate poor phase coherence that would make it unsuitable for a crossover application.

Similar sweeps using mac drift correction are much more stable as shown here -> https://www.audiosciencereview.com/...vice-i-need-ca-25-ms-delay.40051/post-1411908. Also, with the mac you can clearly see less drifting on the scope as well as "corrections" where the trace will move back and forth but generally stay centered with the reference output.

I also tried recording a few seconds of a 15 kHz tone being played through VB matrix to both DACs and it shows that they go in and out of phase in less than a second.

Michael

 

[boxerfan88]

@mdsimon2 may I know if the above tests were conducted with one of the DAC as the "master"? Or internal clock as the "master"?
I'm just curious.

 

[mdsimon2]

@mdsimon2 may I know if the above tests were conducted with one of the DAC as the "master"? Or internal clock as the "master"?
I'm just curious.

Ahh...one DAC as master. I see in your setup you have the internal clock as master. I'll give that a try and report back.

Michael

 

[mdsimon2]

Tried using Sync by Internal clock as Master and it behaves exactly the same.

Michael

 

[sarieri]

I thought there is no way to sync two async DACs without connecting them to some mutual clock source. Two async DACs that are exactly the same will probably behave similar and they won't drift too much away but will never at least in theory align perfectly. So is it just trying to achieve MacOS's level of drift correction on Windows?

I tried VB Matrix as well. It looks like it routes audio well with no clicks or popping. I always had some clicks/pops on voicemeeter. It could be a very good companion for some soundcards lack of multichannel WDM driver support (eg. motu Ultralite mk5). Windows recognize motu's i/o as stereo pairs and VB Matrix could route VAIO to them without drifts since they share the same clock. EIKO also has multichannel WDM driver support, so it does the same job except it occupies some channels serving as inputs while with VB Matrix you could just feed the soundcard with VAIO.

 

[phofman]

Interesting. I looked at the RTA and it seems pretty stable but has a hiccup every 2-3 minutes.

Another data point is if I run REW sweeps and use loopback as timing reference with the "synchronized" DAC, the reported delay between the two DACs decreases over time until it resets at some point.

1:59:46: 30.7 ms
2:00:06: 29.6 ms
2:00:25: 28.5 ms
2:00:51: 27.1 ms
2:01:06: 26.4 ms
2:01:19: 25.7 ms
2:01:31: 25.0 ms
2:01:49: 24.1 ms
2:02:05: 23.1 ms
2:02:21: 22.3 ms
2:02:44: 21.1 ms
2:03:12: 20.5 ms
2:03:24: 19.0 ms
2:03:41: 18.4 ms
2:03:53: 17.5 ms
2:04:22: 16.1 ms
2:04:39: 25.6 ms
2:05:00: 24.7 ms
2:05:13: 23.9 ms

Does this behavior make sense to you? To me such drifting would indicate poor phase coherence that would make it unsuitable for a crossover application.

IIUC that would fit the hypotheses that VB Matrix uses simple sample dropping/stuffing instead of proper adaptive resampling. After the buffer fill/timeshift exceeds some limit, the corrective action is fired, re-aligning the timing. That would be the reset in delay and hiccup in the RTA FFT.

IMO this time correction of 10ms every several minutes should be clearly audible.

 

[phofman]

I tried VB Matrix as well. It looks like it routes audio well with no clicks or popping.

Did you route to several independent interfaces (one master, the others slave) at the same time?

 

[boxerfan88]

I tried VB Matrix as well. It looks like it routes audio well with no clicks or popping. I always had some clicks/pops on voicemeeter.

That's my experience as well.
I encounter occasional "hesitations" or "dropouts" when using VoiceMeeter.
After three "10-hour" days with VB Matrix, I have not heard any dropouts/clicks/pops.