ProSoundWeb Community

Please login or register.

Login with username, password and session length
Advanced search  

Pages: 1 2 [3]   Go Down

Author Topic: Realtime latency measurement  (Read 1758 times)

Riley Casey

  • Hero Member
  • *****
  • Offline Offline
  • Posts: 1624
Re: Realtime latency measurement
« Reply #20 on: December 15, 2020, 10:23:00 pm »

You sending stereo mixes to the ISS ?

I'll need 0ms up to like 50 SECONDS...

brian maddox

  • Hero Member
  • *****
  • Offline Offline
  • Posts: 2637
  • HeyYahWon! ttsss! ttsss!
Re: Realtime latency measurement
« Reply #21 on: December 15, 2020, 10:25:27 pm »

You sending stereo mixes to the ISS ?

Actual round trip to the ISS is shorter than that. [ask me how I know...  :)]

Logged
"It feels wrong to be in the audience.  And it's too peopley!" - Steve Smith

brian maddox
bdmaudio@gmail.com

'...do not trifle with the affairs of dragons...

       ....for you are crunchy, and taste good with ketchup...'

Michael Lawrence

  • Full Member
  • ***
  • Offline Offline
  • Posts: 127
Re: Realtime latency measurement
« Reply #22 on: December 15, 2020, 10:36:39 pm »

I'll need 0ms up to like 50 SECONDS...

Yeah, then the Smaart solution probably isn't going to work for you. Once the delay time exceeds about a third of the FFT time constant it has trouble grabbing on. That'd be a hell of an FFT :D

...okay, 50 seconds @ 48kHz would be a 2.4M FFT, producing 1.2 Million data points with a frequency resolution of 0.00000083 Hz. Your computer would probably eat itself.
Logged

Russell Ault

  • Hero Member
  • *****
  • Offline Offline
  • Posts: 1123
  • Edmonton, AB
Re: Realtime latency measurement
« Reply #23 on: December 15, 2020, 11:49:33 pm »

...okay, 50 seconds @ 48kHz would be a 2.4M FFT, producing 1.2 Million data points with a frequency resolution of 0.00000083 Hz. Your computer would probably eat itself.

Would it though? I mean, it'd obviously take a while to collect enough samples, but 2.4 million samples at 24 bits would only be ~8 MB of data. I suppose it depends on how much window overlap you're attempting?

-Russ
Logged

Michael Lawrence

  • Full Member
  • ***
  • Offline Offline
  • Posts: 127
Re: Realtime latency measurement
« Reply #24 on: December 16, 2020, 09:54:44 am »

Would it though? I mean, it'd obviously take a while to collect enough samples, but 2.4 million samples at 24 bits would only be ~8 MB of data. I suppose it depends on how much window overlap you're attempting?

-Russ

At the risk of derailing this thread, it's not about the size of the data registers as much as the number of calculations we're asking the computer to do. There's a reason FFTs are commonly used for CPU heating tests (and remember, the whole point is that it's happening in realtime, which is 24 times/second in Smaart's case. In IR mode you can go up to 512k, and you can rock a 4M FFT in REW, but it takes a while.).

Operational complexity for a basic FFT is O(NlogN) so for a 16k FFT, that's just over 69,000 operations vs a 2.4M FFT would need over 15M. Plus all the per-bin thresholding and averaging buffers (between 5 and 7 per engine depending on configuration if memory serves) each holding over a million samples vs 8000, times whatever averaging depth you're using.

If you are having trouble sleeping: http://www.cmlab.csie.ntu.edu.tw/cml/dsp/training/coding/transform/fft.html

So you're talking about increasing the CPU demands of a transfer function engine by about three orders of magnitude over the standard MTW setting. (This is a silly thought experiment because as you pointed out there's no reason I can think of to run a time record that long at virtually 100% overlap, and it's just such a long time record it wouldn't be much practical use for audio purposes.)

Now, that being said - some of the "norms" when it comes to software audio analyzers have historical roots, as I'm sure most of you know, when personal computers were becoming accessible (and I was a wee lad), the CPU power was extremely limited compared to what we have today, and at that time, moving from dedicated hardware DSP cards to personal computers, a lot of decisions were made simply based on what the computer's capabilities were. That's part of the benefit behind Fixed PPO / MTW / etc. With MTW at 48kHz we're only asking the computer to handle about 800 data points at 24 fps rather than 8000 for a 16k FFT, and we still produce the resolution where we need it (LF), and don't have to deal with the excess resolution where we don't (HF). (It has other benefits, including the fact that FPPO/MTW makes the coherence trace behave in a way that is usefully representative of human perception, but that is another topic entirely.)

Silliness aside there is something worth considering here: On a modern machine, under normal use, Smaart can run multiple TF engines and a live average and still sit comfortably under 10% CPU. So the question becomes: now that modern machines have so much processing power available, what if we were able to re-evaluate some of these norms and allow the analyzer to stretch its legs and use a little more of the available power? What cool stuff would we be able to do? v9 is going to do some really neat things that just wouldn't be practical in the past, although I can't say too much more just yet :)
« Last Edit: December 16, 2020, 09:57:35 am by Michael Lawrence »
Logged

Andrew Broughton

  • Hero Member
  • *****
  • Offline Offline
  • Posts: 1810
    • Check Check One Two
Re: Realtime latency measurement
« Reply #25 on: December 16, 2020, 03:49:55 pm »

You sending stereo mixes to the ISS ?

lol.
Im sure youve by now experienced the fun of live streaming. Multi-second delays are very common.
Logged
-Andy

"Well, my days of not taking you seriously are certainly coming to a middle..."

http://www.checkcheckonetwo.com
Saving lives through Digital Audio, Programming and Electronics.

Andrew Broughton

  • Hero Member
  • *****
  • Offline Offline
  • Posts: 1810
    • Check Check One Two
Re: Realtime latency measurement
« Reply #26 on: December 16, 2020, 03:57:01 pm »

Yeah, then the Smaart solution probably isn't going to work for you. Once the delay time exceeds about a third of the FFT time constant it has trouble grabbing on.
Probably the way to do this is to use non-fft methods to create a delay for the source that gets it in the ballpark, then a smaart style fft to get the mantissa.
Logged
-Andy

"Well, my days of not taking you seriously are certainly coming to a middle..."

http://www.checkcheckonetwo.com
Saving lives through Digital Audio, Programming and Electronics.

Mac Kerr

  • Old enough to know better
  • Administrator
  • Hero Member
  • *****
  • Offline Offline
  • Posts: 6974
  • Audio Plumber
Re: Realtime latency measurement
« Reply #27 on: December 16, 2020, 06:59:13 pm »

Actual round trip to the ISS is shorter than that. [ask me how I know...  :)]
The same way I know...  Real time conversation with the crew.

Mac
Logged

ProSoundWeb Community

Re: Realtime latency measurement
« Reply #27 on: December 16, 2020, 06:59:13 pm »


Pages: 1 2 [3]   Go Up
 



Page created in 0.022 seconds with 19 queries.