while (1)
{
#ifdef WIN32
Sleep (250);
#else
usleep (250000);
#endif
if (mtdm.resolve() < 0) printf ("Signal below threshold...\n");
else
{
jack_nframes_t systemic_latency;
if (mtdm.err () > 0.3)
{
mtdm.invert ();
mtdm.resolve ();
}
systemic_latency = (jack_nframes_t) floor (mtdm._del - (capture_latency.max + playback_latency.max));
printf("%10.3lf frames %10.3lf ms total roundtrip latency\n\textra loopback latency: %u frames\n\tuse %u for the backend arguments -I and -O"
, mtdm._del, mtdm._del * t,
systemic_latency, systemic_latency/2);
if (mtdm._err > 0.2) printf (" ??");
if (mtdm._inv) printf (" Inv");
printf ("\n");
}
}
Where mtdm is a class within that file (I'll spare you pasting a few hundred lines of code into this thread), that basically just runs a bunch calculus stuff from math.h for no apparent reason. I don't see how it is really timing anything, and like I had stated previously, any x86 CPU isn't capable of benchmarking anything that occurs in the span of a few milliseconds. But hey, don't let me rain on your parade
jeffh wrote:there's a whole bunch of users who have been convinced that they can "feel" a difference at those sub 1ms latencies, which must mean that their advanced brains can process over 1000 events a second.
I wish I could find a proof link, but I remember reading an article a few years ago about how in studies done, even the most discerning ear can't tell the difference in anything under 10ms. Once you get your round trip latency within a few ms of that number, it really doesn't matter anymore IMHO. And latency is only as bad as the engineer working with it. Say you're running on a PC/interface that won't reliably go below 1024 buffer, and you end up with 40+ms. You can still do great audio work, you just need to know your latency, know how to work with it, and figure it into calculations for reverbs, delay's and really anything being side-chained. I understand this is moving away from the point of the discussion of finding ways to reliably drive your latency down, but I felt it was worth mentioning.
jeffh wrote:there's a whole bunch of users who have been convinced that they can "feel" a difference at those sub 1ms latencies, which must mean that their advanced brains can process over 1000 events a second.
I wish I could find a proof link, but I remember reading an article a few years ago about how in studies done, even the most discerning ear can't tell the difference in anything under 10ms. Once you get your round trip latency within a few ms of that number, it really doesn't matter anymore IMHO. And latency is only as bad as the engineer working with it. Say you're running on a PC/interface that won't reliably go below 1024 buffer, and you end up with 40+ms. You can still do great audio work, you just need to know your latency, know how to work with it, and figure it into calculations for reverbs, delay's and really anything being side-chained. I understand this is moving away from the point of the discussion of finding ways to reliably drive your latency down, but I felt it was worth mentioning.
Spot on... Most of the "need" for insanely low latency is the work of people selling custom-built audio PCs, and audio interface vendors. I seem to recall fine music coming out of the 90s off early Protools on a Mac dual 1ghz G3, which we know couldn't run 16 samples of latency... Yet so many are convinced that the only way to win a Grammy is by getting your latency down to some ridiculous figure...
It also reminds me of a thread I stumbled upon yesterday. Somebody compared the Zebra VSTi to an Access Virus TI hardware synthesizer for aliasing from their default saw wave. The Zebra saw wave had almost no aliasing, and the Virus TI had full-blown unmitigated aliasing. Therefore, the people posting in the thread concluded that "ERMAGAHD! TEH ZEBRA HAZ BETTER OSCILLATORZ AT 1/10th THE PRICE!". Seriously, do people these days even attempt to listen to things first before interjecting "theory" into what they hear, Zebra sounds terrible compared to the TI
jeffh wrote:Most of the "need" for insanely low latency is the work of people selling custom-built audio PCs, and audio interface vendors.
Live audio applications? Routing, recording, automation of live fx? In that case I would want a super-stable xrun free low-latency powerhouse. But for everyday mixing and electronic type music creation(unless you're actually using one of those old fangled hardware MIDI synths[*take as sarcasm*}), latency is mostly a moot point if you're a halfway compitent musician/engineer.
falkTX wrote:I've seen some random plugins doing nasty things... I use locks in my Carla host processing code, and most likely any other decent app. The trick is to limit the locked time as low as possible (just to safely change a variable, for example).
Meh, I'm not so sure. The specs of course flat-out forbid this. Personally I'd say an app that uses those calls in the process() is basically broken, and there's no amount of distribution tuning you can do to fix a broken app...
Oh, something else though: clearly you're producing Working Code(tm) and you've made way more contributions to the linux audio landscape than me. So I'm in no position to criticize. The above is just a technical standpoint, not criticism of you specifically. As said, you're in good company (eg Ardour) and I don't like that either .
while (1)
{
#ifdef WIN32
Sleep (250);
#else
usleep (250000);
#endif
if (mtdm.resolve() < 0) printf ("Signal below threshold...\n");
else
{
jack_nframes_t systemic_latency;
if (mtdm.err () > 0.3)
{
mtdm.invert ();
mtdm.resolve ();
}
systemic_latency = (jack_nframes_t) floor (mtdm._del - (capture_latency.max + playback_latency.max));
printf("%10.3lf frames %10.3lf ms total roundtrip latency\n\textra loopback latency: %u frames\n\tuse %u for the backend arguments -I and -O"
, mtdm._del, mtdm._del * t,
systemic_latency, systemic_latency/2);
if (mtdm._err > 0.2) printf (" ??");
if (mtdm._inv) printf (" Inv");
printf ("\n");
}
}
Where mtdm is a class within that file (I'll spare you pasting a few hundred lines of code into this thread), that basically just runs a bunch calculus stuff from math.h for no apparent reason. I don't see how it is really timing anything, and like I had stated previously, any x86 CPU isn't capable of benchmarking anything that occurs in the span of a few milliseconds. But hey, don't let me rain on your parade
good, the goal was to show you that I ran 8 frames/period.
And the goal of showing it wasn't "parading" but prooving that low latency doesn't depend on OS loaded to RAM.
falkTX wrote:damn you guys, I can only get min 64 frames with my crappy laptop HDA card... (and it's very unstable at 64)
I'm jealous...
I need to get a pro card someday... do they need external power source?
well, Auto used an onboard card.
yes, but its a soundblaster (SB) one, which afaik doesn't come in laptops.
SoundBlaster cards are not pro, but good enough I think, at least better than Intel HDA.
I have a Intel HDA on my motherboard. perhaps I enable it in bios later just to compare it to my pro device
falkTX wrote:yes, but its a soundblaster (SB) one, which afaik doesn't come in laptops.
SoundBlaster cards are not pro, but good enough I think, at least better than Intel HDA.
The SB card is my onboard soundcard, it's a very common combination with other AMD hardware.
yes, but its a soundblaster (SB) one, which afaik doesn't come in laptops.
SoundBlaster cards are not pro, but good enough I think, at least better than Intel HDA.
I have a Intel HDA on my motherboard. perhaps I enable it in bios later just to compare it to my pro device
just tested this, I only got it stable at 128 frames/period!!!!
so, yes: buy a professional card
btw: this kind of proofs my running 8 frames/period on my firewire device are true, too
Maybe your PC does run Hydrogen at 8 samples, 32 sounds more realistic for a real world workload..
I just know for sure that QJackCtl is lying to me when it tells me that I'm benchmarking a full PyDAW project at 192khz/16samples without any additional CPU overhead compared to 44.1khz/512samples
.
