Principles: Time of Arrival Delays, vs Phase tuning ?

[-Matt-]

more relevant

Torn between AVR room correction and Hi-Fi sound quality.

I'm really struggling to find a solution that gives me both: good room correction (e.g., Dirac Live) and the sound quality of a separate Hi-Fi system (streamer/DAC + amplifier). From what I've read on ASR, most AVRs (like Denon X3800H/X4800H) have significantly worse audio performance compared...

www.audiosciencereview.com

 

[john61ct]

Not at all, to me.

I see an opinion that AV gear has lesser SQ, I have never thought that.

Please just stop

 

[john61ct]

Bit over my pay grade but seems related

New RME ADI-2 Pro EX DAC

Totally right. Here is the second unit. This one broke on the right side top corner. Seems like a fairly serious design flaw to have happened multiple times to the same product line. Sketchy for sure.

www.audiosciencereview.com

 

[john61ct]

A pair of collocated Wiim "Pro Subs" may well serve as MBM Couplers, not bass-managed xovers by the Ultra but fed wired from Outlaw ICBM-1 stereo sub outputs.

Apparently they should give decent SPL right down to 50Hz, so likely only one bottom-most "trueSub1" needed to get the Front L-R stacks down below 20Hz, better AND "simpler"?

Main LS50s above, might get away with analog HPF only, since these as-MBM units have their own internal DSP (10x PEQ, bass boost needed)

which would save FOUR output channels off the dedicated DSP units.

So the miniDSP can perhaps get dedicated to the MSO managed group of mono trueSubs.

This front MBM pair is very unlikely to go mono, hence not part of the MSO managed group (except Center ofc)

Maybe an 8-port RPi5 is enough for DSPing the Center stack plus rear, FR Surround pair even testing Stereo subs for side L&R and/or rear center.

I think the two Wiim Pro Subs have their own dedicated RoomFit ? maybe that will help more than the Wiim Ultra's - unlikely one would use both, LOL.

I've posted nominal supposed specs (best I can tell so far) here, so best discuss those there, but my proposed system #1 here

Wiim Sub Pro

"We", kemo sabe? :) Yes, that's a limited definition, but not what would necessarily qualify as a true sub to me at least. Then as I say, you’re guilty of high redefinition. Any dictionary definition, or common usage if the term ‘subwoofer’ is the one I offered, more or less. Companies...

www.audiosciencereview.com

...

 

[john61ct]

I've become very interested in Ethernet AVB protocol for passing tightly syncronized music streams between converter/interfacii and distributed RPi DSPs

8ch DSP on a shoestring? (SURE WONDOM AA-AB41173)

The Sure Wondom AA-AB41173 is essentially a multi-channel DAC with USB input. A Bravo SA9128 chip provides USB input, as well as 4 I2S outputs for the bottom board. A connector then routes the I2S signals to four PCM 5121s and provides eight output channels. You only need to provide 5V and data...

www.audiosciencereview.com

 

[-Matt-]

Probably not suitable for a low cost audio system, however, if you are genuinely interested in network time synchronisation then you may find White Rabbit an interesting rabbit warren to explore!

White Rabbit Project - Wikipedia

en.wikipedia.org

 

[john61ct]

yes interesting

So far I'm thinking sub ms is enough to strive for

for many contexts, couple-few ms tolerance for some.

But sub-NANO ? Nope! 8-D

 

[john61ct]

Relevant

How Much Current Capacity do we Need from our Amplifiers?

Therefore clearly these 60 A peak output current claims (if these claims were actually made) cannot have any real world relevance and are enitrely bogus. I think the person claiming the 60A output capability misunderstood the magazine article to which he provided the link. The article states...

www.audiosciencereview.com

 

[john61ct]

In researching my ideas for "Modularised DSP ™ " system using distributed RPi5 nodes

From AVB, I'm now looking at different, more "open" AoIP protocols

using Intel i210 + PTPv2 "network clock" sync'ing across independent RPi5 nodes

Google says:

A DSP output mismatch of just 1 millisecond shifts the audio alignment by roughly 13 inches (34 cm) in physical space.

This completely destroys the crossover alignment.

What say y'all ?

 

[Keith_W]

A DSP output mismatch of just 1 millisecond shifts the audio alignment by roughly 13 inches (34 cm) in physical space.

This completely destroys the crossover alignment.

What say y'all ?

The statement that a 1ms shift equals a 34cm shift in physical space is correct.

But whether it destroys crossover alignment or not ... that's frequency dependent. For example, 1ms is one whole period of 1kHz. So if your HF driver is 1ms ahead of the LF driver at 1kHz, it is not time aligned, but it is phase aligned.

So yes, Google gave you the right answer but it wasn't the full story.

 

[john61ct]

Aha, so for crossovers down below in LF, less audible / consequential ?

Apparently so long as the wired network is stable not flooded, expectations of sub-millisecond variance is reasonable.

I'm thinking the ADC input RPi5 as Grandmaster Clock for ptp4l, do all the xover/ bass management DSPing there

then 3-4 slave nodes each with 8 ports, DA conversion / outputting only.

One node for Left signals, one for Right, then all mono ( center(s) + trueSubs) on a third.

That way, even if there is a little variability, it should not be as big a deal, as if it were within the same stack.

Only the output node converters get sync'd via BNC Word Clock.

So far pipewire-aes67 is leading contender, much cheaper than interface-based AVB even secondhand trying to keep under $20-25 per analog port for the interfacii.

If I can do FireWire might not need multiple RPi5 at all, this is a much more expensive belt to those first-choice much cheaper suspenders.

 

[Keith_W]

Aha, so for crossovers down below in LF, less audible / consequential ?

Correct. 1ms is relatively inconsequential at 50Hz. One period of 50Hz = 1000/50 = 20ms. So a 1ms phase misalignment is 360 * 1/20 = 18 degrees. But 1ms is huge at 10kHz. So the same time delay has different consequences at different frequencies.

As for the rest of your post, I have no idea what you are talking about. If we are talking about latency jitter, it is typically in the order of microseconds (1/1000 of a millisecond).

 

[john61ct]

If we are talking about latency jitter, it is typically in the order of microseconds (1/1000 of a millisecond).

Yes network jitter is one factor, and usually as you say not a big one.

But each RPi5 node in the DSP "cluster" running its own clock, hence drift over time is more consequential. Also DSP taking place for the same domain / layer on more than one node.

So I'm trying to do exact TIME based sync of the Linux system clock rather than rate based synchronization algo's that some AoIP protocols use

e.g. microscopically adjusting each local sample rate / playback speed, to keep the buffer levels identical across all nodes

apparently not sync'ing precisely enough for proper phase alignment.

Just FYI, feel free to ignore anything outside your domain of interest

I appreciate any feedback especially correcting my misunderstandings.

I need more learning resources about time domain / phase alignment / delay issues, especially practically oriented wrt creating / tuning / fixing crossovers.

I did find this https://sengpielaudio.com/Calculations03.htm

 

[3ll3d00d]

just in case you thought the project couldn't get more complicated, we now have a diy ptp timeserver so when you say the pi will be grandmaster, do you mean something like https://www.jeffgeerling.com/blog/2025/diy-ptp-grandmaster-clock-raspberry-pi/ ? and since you're outside, you actually plan to feed it with gps signal or similar?

 

[Keith_W]

I need more learning resources about time domain / phase alignment / delay issues, especially practically oriented wrt creating / tuning / fixing crossovers.

Do you have a computer yet? If so, download REW and create a simulation. This is what you need to do:

1. Make a subwoofer. Go to EQ, click on "EQ filters", scroll all the way to the right. Choose Butterworth 4th order, HPF 20Hz, LPF 80Hz.
2. Make a main speaker. Follow the same steps but HPF 80Hz, LPF 20kHz.
3. Go to "All SPL", right click on the graph, and choose the alignment tool. Play with the "Fine delay adjustment" slider and watch what happens to the summation when you change the delays. Make sure you switch between the impulse view and phase view so that you can see what effect delay has on those.

Alternatively you could go download this guy's MDAT and play with his system. A simulation is much easier to understand than a real measurement though.

 

[OCA]

Yes network jitter is one factor, and usually as you say not a big one.

But each RPi5 node in the DSP "cluster" running its own clock, hence drift over time is more consequential. Also DSP taking place for the same domain / layer on more than one node.

So I'm trying to do exact TIME based sync of the Linux system clock rather than rate based synchronization algo's that some AoIP protocols use

e.g. microscopically adjusting each local sample rate / playback speed, to keep the buffer levels identical across all nodes

apparently not sync'ing precisely enough for proper phase alignment.

Just FYI, feel free to ignore anything outside your domain of interest

I appreciate any feedback especially correcting my misunderstandings.

I need more learning resources about time domain / phase alignment / delay issues, especially practically oriented wrt creating / tuning / fixing crossovers.

I did find this https://sengpielaudio.com/Calculations03.htm

Perfect is the enemy of good. 99% of DSP deals with the room effects which none of your hardware optimizations will change.

 

[rjp]

Perfect is the enemy of good, but it's so shinny

 

[john61ct]

Perfect is the enemy of good. 99% of DSP deals with the room effects which none of your hardware optimizations will change.

This thread is just wrt crossovers and driver / speaker EQ at the "anechoic" layer, nothing to do with DRC.

Remember this is a mobile system, rarely in a "room" per se, often to be used outdoors, so the DRC stuff to be learned / tested later as final "polish layer"

The local CamillaDSP (or Hang Loose) might be handling local EQ, crossovers, both magnitude and phase tuning, also intra-stack time of flight delays, all the stuff that does not change by location, based on as anechoic as possible measurements.

While the central overall DSP (likely RPi5) handles the DRC, stuff that changes at each new location.

 

[john61ct]

when you say the pi will be grandmaster, do you mean something like https://www.jeffgeerling.com/blog/2025/diy-ptp-grandmaster-clock-raspberry-pi/ ? and since you're outside, you actually plan to feed it with gps signal or similar?

Adjacent yes using PTPv2 but different goals. Grandmaster is just that protocol's term, same as designating Master with BNC Word Clocking. Apparently using the Input node is ideal.

Intel i210 NICs are the usual "network clock" tool for sub-ms precision with AoIP, the i226 is newer, looks like issues there.

And no need in this case I believe, for getting the ACTUAL time so precisely using GNSS, just all the system clocks to be in sync, no drift allowed.

It's all about ensuring the analog output nodes are coordinated at the sample level via direct timestamping rather than variable software buffering, to prevent shifting phase skew.

 

[john61ct]

relevant https://www.audiosciencereview.com/...essons-learned-tips-tricks.39953/post-2633176