An Idea: automatic audio equipment measurement

Discuss your workplace, instruments, amps, and any other gear.

Moderators: MattKingUSA, khz

Post Reply
CrocoDuck
Established Member
Posts: 1133
Joined: Sat May 05, 2012 6:12 pm
Been thanked: 17 times

An Idea: automatic audio equipment measurement

Post by CrocoDuck »

Hi cool people!

I have a thing in the back of my head.

Problem: Most of the audio manufacturers do not publish meaningful specs about the hardware they sell. Often they do not report the measurement conditions. Often they present the data in a way that do not allow to properly understand what they represent. It even happened that they omit the units!

Solution: create a piece of software that can run automatically and perform measurements of electronic audio equipment. Upload the results to a community website. Now people know what they are gonna buy.

I wrote a kind of automatic measuring script in MATLAB as part of my master in Audio Acoustics. The user is needed only for calibration. However, I am rubbish at coding in real programming languages. Also, I pretty much feel like I don't have time to port it, say, to C++. However, I am interested in hearing from you if you think it could be a nice idea.
asbak
Established Member
Posts: 897
Joined: Thu Sep 11, 2014 3:04 pm
Has thanked: 71 times
Been thanked: 64 times

Re: An Idea: automatic audio equipment measurement

Post by asbak »

Sounds nice, if you know how to code it.

FWIW, I can take a Behringer UMC404 down to 2ms latency (32 frames) at 48K (according to qjackctl) without xrunning. But realistically it would be safer to run at 4ms / 64 frames.
Some Focal / 20.04 audio packages and resources https://midistudio.groups.io/g/linuxaudio
CrocoDuck
Established Member
Posts: 1133
Joined: Sat May 05, 2012 6:12 pm
Been thanked: 17 times

Re: An Idea: automatic audio equipment measurement

Post by CrocoDuck »

asbak wrote:FWIW, I can take a Behringer UMC404 down to 2ms latency (32 frames) at 48K (according to qjackctl) without xrunning. But realistically it would be safer to run at 4ms / 64 frames.
That is interesting. My MATLAB stuff at this moment can simultaneously assess:
  • Frequency response, magnitude and phase (this would be much more useful than the figures like "20 Hz - 20 kHz +/- 1 dB" usually published).
  • Latency (usually not specified by manufacturers).
  • THD as a function of frequency (that is much more useful than the pretty pointless 1 kHz A-weighted THD that manufacturers throw at us).
I think I could probably add impedance (magnitude and phase) as well, but this would require further pieces of equipment I think. Well, for the time being I will keep on prototyping in MATLAB. If any of you guys have good references for audio programming in C++ I am all ears. I think I cannot share my code with you guys at this stage though, as it has been submitted to the uni that owns copyrights on it for a year or two (if I reckon). Shouldn't be too much of a problem as I think that it would take at least that time to get a real program barely working if I started coding real software today. I was thinking about a JULIA port as well. It is not C++ but it is high level, so the port should be straightforward for the most part. It is much faster than MATLAB and, more important, it is an opensource project. However, I have the feeling that I have to go low level to make a good software project out of this whole stuff...
Last edited by CrocoDuck on Sat Mar 19, 2016 9:26 pm, edited 2 times in total.
gimmeapill
Established Member
Posts: 564
Joined: Thu Mar 12, 2015 8:41 am
Has thanked: 44 times
Been thanked: 8 times

Re: An Idea: automatic audio equipment measurement

Post by gimmeapill »

Sounds like a useful idea.
I like also the concept of having a "one stop shop" to evaluate and tune system performance for audio.
Maybe you could contribute that part as a module for the RT scan https://github.com/raboof/realtimeconfigquickscan?
CrocoDuck
Established Member
Posts: 1133
Joined: Sat May 05, 2012 6:12 pm
Been thanked: 17 times

Re: An Idea: automatic audio equipment measurement

Post by CrocoDuck »

gimmeapill wrote:Sounds like a useful idea.
I like also the concept of having a "one stop shop" to evaluate and tune system performance for audio.
Maybe you could contribute that part as a module for the RT scan https://github.com/raboof/realtimeconfigquickscan?
I think it would be possible, but the dependencies count for realtimeconfigquickscan would increase. I have started the JULIA port as it seems to work well, so JULIA would have to be added.

However, probably for the scope of realtimeconfigquickscan measurements of audio frequency response and distortion are not needed. We actually just need latency. A perl script can handle jack_iodelay easily (I have written a bash script already that launches jack_iodelay, connects it to ports and logs the latency values in a .cvs file). So, I should be able to have realtimeconfigquickscan able to asses latency with accuracy (jack_iodelay is accurate) ithout adding dependencies (a part for jack). But first, I will learn perl!
gimmeapill
Established Member
Posts: 564
Joined: Thu Mar 12, 2015 8:41 am
Has thanked: 44 times
Been thanked: 8 times

Re: An Idea: automatic audio equipment measurement

Post by gimmeapill »

Yeah, perl is not my one true love either...and I hardly have any time to do anything helpful (because real life...) - just procrastinating at work ;-)

I'm not sure if jack io delay would be the right tool for that (I'm really starting to feel like the bad guy):

- jack io delay needs a patch cable to bridge input and output. That will probably not work out for most users, especially those with a notebook and an integrated sound card. Do we really want to include external hardware latency measurement or just assess what the internal stuff (computer + operating system) are capable of, latency wise - mostly sticking to the scope of the original quick scan?

- Assuming the second option: measuring internal latency only. You may manage to trick jack io delay into measuring round trip latency between 2 internal ports (maybe by adding an application in the middle), but I wonder what the latency figures reported would be good for, compared to what jack says. Also, latency figures are only useful in relation to xruns and jack io delay has no clue about that. Unless you have a way to measure xruns from jack logs at the same time?
gimmeapill
Established Member
Posts: 564
Joined: Thu Mar 12, 2015 8:41 am
Has thanked: 44 times
Been thanked: 8 times

Re: An Idea: automatic audio equipment measurement

Post by gimmeapill »

Ah sorry, I replied to the wrong thread - I thought this was for the audio configuration checklist - my bad
CrocoDuck
Established Member
Posts: 1133
Joined: Sat May 05, 2012 6:12 pm
Been thanked: 17 times

Re: An Idea: automatic audio equipment measurement

Post by CrocoDuck »

gimmeapill wrote:Ah sorry, I replied to the wrong thread - I thought this was for the audio configuration checklist - my bad
Lol, I am making a mess with multiple similar threads.
gimmeapill wrote: - jack io delay needs a patch cable to bridge input and output. That will probably not work out for most users, especially those with a notebook and an integrated sound card. Do we really want to include external hardware latency measurement or just assess what the internal stuff (computer + operating system) are capable of, latency wise - mostly sticking to the scope of the original quick scan?
Measuring the rountrip latency can be useful to configure jack tho but yeah, probably it is better to leave this "advanced" thing to the user. We should probably edit the documentation and make clear that math derived latency (given by jack) and actual whole chain latency are two different things. A lot of people, including myself few years ago, were thinking the jack figures said it all.
gimmeapill wrote: -Assuming the second option: measuring internal latency only. You may manage to trick jack io delay into measuring round trip latency between 2 internal ports (maybe by adding an application in the middle), but I wonder what the latency figures reported would be good for, compared to what jack says. Also, latency figures are only useful in relation to xruns and jack io delay has no clue about that. Unless you have a way to measure xruns from jack logs at the same time?

That was in part the idea. Also, I have noticed that usually xruns are associated to latency values sudden changes, so you can get info about them from jack_iodelay, although the logs should be the best source of info. I feel like it should be straightforward to implement, but I still have to try (during my master project I was used to inspect Ardour for xruns markers, I did not read logs with my script).

From the jack_iodelay man page:

Code: Select all

Although  the hardware loopback latency is the expected use, it is also possible
to use jack_iodelay to measure the latency  along  any  fully  connected  signal
path, such as those involving other JACK clients.
Latency is related to DSP operations, as such clients might alter it. According to my understanding, the jack prediction is related just to the sampling - buffering operations (is that right?). Probably is not a bad thing to measure it but yeah, the smaller the math derived latency the smaller the actual one, so the two parameters serve the same purpose and there is not really a need to use the cannon (jack_iodelay) to shoot at little birds...
Post Reply