• WANTED: Happy members who like to discuss audio and other topics related to our interest. Desire to learn and share knowledge of science required. There are many reviews of audio hardware and expert members to help answer your questions. Click here to have your audio equipment measured for free!

Beta Test: Multitone Loopback Analyzer software

A new preview/test update, MTA v1.1.12: https://app.box.com/s/ue7ll9xmvwogst817x2l1xg09opvgy47

New feature added: Interval Sweep. Like all other sweeps, this one allows multiple measurements to be placed on a chart. Measurements are done on a specified time interval, and repeated a specified number of times. As with other sweeps, the plot provides for a comparison of up to three different measured values which can be selected during or after the sweep completes. This provides for a way to measure changes in the DUT due to warm-up or other time-related effects.

Please test and provide feedback on anything that isn't working or can be improved.

1714703977183.png


1714703891869.png
 
pkane said:
A new preview/test update, MTA v1.1.12: https://app.box.com/s/ue7ll9xmvwogst817x2l1xg09opvgy47

New feature added: Interval Sweep. Like all other sweeps, this one allows multiple measurements to be placed on a chart. Measurements are done on a specified time interval, and repeated a specified number of times. As with other sweeps, the plot provides for a comparison of up to three different measured values which can be selected during or after the sweep completes. This provides for a way to measure changes in the DUT due to warm-up or other time-related effects.

Please test and provide feedback on anything that isn't working or can be improved.

View attachment 367288

View attachment 367287
Click to expand...

Thanks!

A couple of findings...

The round counter goes one step late. Like this with 10 intervals:

Step: Counter:
#1 ... 0/10
#2 ... 1/10
#3 ... 2/10
#4 ... 3/10
#5 ... 4/10
#6 ... 5/10
#7 ... 6/10
#8 ... 7/10
#9 ... 8/10
#10 ... 9/10
 
There is no waiting time with every other interval period:

#1
Wait
#2
No waiting
#3
Wait
#4
No waiting
#5
Wait
#6
No waiting
#7
Wait
#8
No waiting
#9
Wait
#10
Stops

It makes the time-axis to look jumpy and the 10 minute measurement time drops to under 7 minutes:

1714713418596.png
 
Last edited:
Rantapossu said:
There is no waiting time with every other interval period:

#1
Wait
#2
No waiting
#3
Wait
#4
No waiting
#5
Wait
#6
No waiting
#7
Wait
#8
No waiting
#9
Wait
#10
Stops

It makes the time-axis to look jumpy and the 10 minute measurement time drops to under 7 minutes:

View attachment 367298
Click to expand...
Confirm the late counter.
The time thing as I tested it seems ok but I only tested with very small time,I'll repeat with longer times.

internal.PNG
 
Rantapossu said:
There is no waiting time with every other interval period:

#1
Wait
#2
No waiting
#3
Wait
#4
No waiting
#5
Wait
#6
No waiting
#7
Wait
#8
No waiting
#9
Wait
#10
Stops

It makes the time-axis to look jumpy and the 10 minute measurement time drops to under 7 minutes:

View attachment 367298
Click to expand...
That's what it looks like with 30 sec,10 intervals.

time.PNG
 
Hi @pkane !

I don't know if this is intentional, but I noticed that with the 1k, 2k, 4k and 8k FFT sizes my primary computer completely syncs the refresh rate of the waveform graph and the incoming signal. The end result is just like a traditional oscilloscope, the graph remains perfectly stationary with respect to the x-axis and the y-axis changes according to the measured signal. With 16k FFT and above the x-axis isn't synced any more and the graph jumps left and right with every refresh.

The secondary computer never syncs perfectly, but I can tweak it better by changing the FFT-sizes manually, tweaking FFT size for example from 8192 to 8184 makes it almost synced, only jumping like 10-20 pixels left or right when the graph refreshes.

If I'm just lucky and it was never intented to sync the waveform perfectly, would it be hard to implement some kind of zero-crossing trigger to the waveform view, so the waveform view would be synced regardless the computing power and FFT sizes when using a simple and repeating signal like sine?

That would be cool!
 
Last edited:
Rantapossu said:
Hi @pkane !

I don't know if this is intentional, but I noticed that with the 1k, 2k, 4k and 8k FFT sizes my primary computer completely syncs the refresh rate of the waveform graph and the incoming signal. The end result is just like a traditional oscilloscope, the graph remains perfectly stationary with respect to the x-axis and the y-axis changes according to the measured signal. With 16k FFT and above the x-axis isn't synced any more and the graph jumps left and right with every refresh.

The secondary computer never syncs perfectly, but I can tweak it better by changing the FFT-sizes manually, tweaking FFT size for example from 8192 to 8184 makes it almost synced, only jumping like 10-20 pixels left or right when the graph refreshes.

If I'm just lucky and it was never intented to sync the waveform perfectly, would it be hard to implement some kind of zero-crossing trigger to the waveform view, so the waveform view would be synced regardless the computing power and FFT sizes when using a simple and repeating signal like sine?

That would be cool!
Click to expand...

Somewhat by design :) The oscilloscope view is lower priority than waveform capture and processing, so if you have a slower computer (a laptop, for example), you may see some jumps because the oscilloscope isn't keeping up with the data coming in. Also, if you are using two different devices/clocks for DA and AD, or different sample rates for in/out, the clock drift will result in slow (or fast) motion of the sine wave across the screen, depending on the magnitude of the drift.
 
pkane said:
Somewhat by design :) The oscilloscope view is lower priority than waveform capture and processing, so if you have a slower computer (a laptop, for example), you may see some jumps because the oscilloscope isn't keeping up with the data coming in. Also, if you are using two different devices/clocks for DA and AD, or different sample rates for in/out, the clock drift will result in slow (or fast) motion of the sine wave across the screen, depending on the magnitude of the drift.
Click to expand...

I'm using a shared clock and same sample rates for both in and out, so I'm just lacking the oomph, I guess.
 
Rantapossu said:
I'm using a shared clock and same sample rates for both in and out, so I'm just lacking the oomph, I guess.
Click to expand...
That would be my expectation. Oscilloscope isn't tied to the spectrum view FFT rate. When you increase FFT size, you likely increase the load on the CPU leaving fewer cycles for the oscilloscope to process its data. I'll see if I can optimize this a little more by giving higher priority to the view that's currently on the screen.
 
With 8k FFT the processor load is about 13-14%, with 64k FFT it's something like 22-23%.
 
Rantapossu said:
With 8k FFT the processor load is about 13-14%, with 64k FFT it's something like 22-23%.
Click to expand...
Hmm. Are you sure you updated to the latest version? There shouldn't be any FFTs of the size you set on the Spectrum tab being performed while you're watching the oscilloscope plot.
 
pkane said:
Hmm. Are you sure you updated to the latest version? There shouldn't be any FFTs of the size you set on the Spectrum tab being performed while you're watching the oscilloscope plot.
Click to expand...

I downloaded it again and reinstalled. Maybe my PC was doing something in the background that made the CPU load rise last time?

Now it 13-14% load with 8k and 64k FFT. 512k FFT it's about 24% when watching the oscilloscope, so it might not be the CPU load.

But don't use too much your time with this, I can always switch to 8k FFT when watching the oscilloscope view for example to ballpark the clipping point and then switch back to bigger FFTs when doing the actual measurement with the right levels.
 
Overall the new prioritizated version is much better than the old one, you can now cut the CPU load easily to half or even lower, if you use other view than the spectrum view during the measurement.

Please keep these changes, If they do not cause any drawbacks.
 
You must log in or register to reply here.

Similar threads

Mr. Haelscheir
Measuring headphones (and others) with music as stimulus
Replies
12
Views
1K
MayaTlab
M
D
30-80Hz (1.3 octaves) vs 500-2000Hz (2 octaves) in AVR and REW test tones
Replies
2
Views
334
JohnPM
JohnPM
A
Upper limit of frequency response of $150 or so sound interfaces?
Replies
13
Views
746
Blumlein 88
Blumlein 88
C
INPUT WANTED: music tracks and methodology for testing audibility of group delay
2 3
Replies
44
Views
2K
charlielaub
C
Linards
  • Poll
How good is bad? (Raspberry Pi 4B headphone output DAC review)
2 3
Replies
54
Views
21K
m8o
M
Back
Top Bottom