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.
An Idea: automatic audio equipment measurement
Moderators: MattKingUSA, khz
-
- 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
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.
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
Re: An Idea: automatic audio equipment measurement
That is interesting. My MATLAB stuff at this moment can simultaneously assess: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.
- 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).
Last edited by CrocoDuck on Sat Mar 19, 2016 9:26 pm, edited 2 times in total.
-
- 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
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 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?
Re: An Idea: automatic audio equipment measurement
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.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?
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!
-
- 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
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?
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?
-
- 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
Ah sorry, I replied to the wrong thread - I thought this was for the audio configuration checklist - my bad
Re: An Idea: automatic audio equipment measurement
Lol, I am making a mess with multiple similar threads.gimmeapill wrote:Ah sorry, I replied to the wrong thread - I thought this was for the audio configuration checklist - my bad
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: - 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?
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.