LWN: Comments on "Realtime group scheduling doesn't know JACK"

The bug in Ubuntu 11.04 has now been fixed.

diwic — Mon, 31 Jan 2011 19:43:51 +0000

This is now fixed in 2.6.38-rc2 kernel, and the corresponding 2.6.38-1-generic kernel in Ubuntu.

The bug was caused by the autogroup patch, which the development version of Ubuntu (11.04) applied on top of 2.6.37 for testing/experimental purposes. That's why Ubuntu got it before anyone else did.

The fix:

commit f44937718ce3b8360f72f6c68c9481712517a867
Author: Mike Galbraith <efault@gmx.de>
Date: Thu Jan 13 04:54:50 2011 +0100

sched, autogroup: Fix CONFIG_RT_GROUP_SCHED sched_setscheduler() failure

Realtime group scheduling doesn't know JACK

jrigg — Wed, 12 Jan 2011 19:33:28 +0000

FWIW I'm using realtime scheduling capabilities with a standard kernel, not an rt-patched one. Realtime pre-emption as enabled by the rt-patch is not what is being discussed here, just the ability to use SCHED_FIFO.

Realtime group scheduling doesn't know JACK

davepl — Tue, 11 Jan 2011 23:53:03 +0000

I must step in here, firstly I look after multimedia apps and libs for openSUSE and the largest and most prominent packaging "todo" I have, is a jack that just works when installed. I'm also a hardware person majoring in games, controllers and juke boxes.
Jack needs RT for latency in response time. Jack is basically a bunch of virtual wires which connect the virtual desks, effects, etc. which make up a very nice and usable array of professional audio applications that run on linux. We all know what happens if we use a defective lead to connect our dvd machine to the fancy home theater system we just bought, the same thing happens to jack if it's looking after a couple of synths, a few filters and an external midi keyboard. My pet package rosegarden won't even start jack if it (jack) doesn't have realtime rights with the kernel and as a result rosegarden doesn't produce sound.
On the other side of the card, one doesn't mix professional audio processing with servers and the like, my celeron E1200 1 gig ram and only one ide port with my dvd writer and only system hard drive hanging on it (saving up for a sata drive to clear a major system bottle kneck) is certainly not suitable as a professional anything workstation but it produces clean audio as long as nothing else is hogging I/O with a crappy HD onboard sound which uses up system resources (I've at least got a mother board with potential the E1200 is the slowest cpu it will work with). Audio is slow in frequency and doesn't have high bandwidth requirements like for example gaming 3D which is taken care of by the GFX card. A professional sound card has the audio processing and audio buffering (ram) to take the load of the system the same as a high end gaming graphics card does and I must add that the providers of this type of hardware are generally happy to stay in the unfree but profitable world of microsoft, have you ever heard of high end audio or video hardware without a shiny windows installation dvd. What the blinded by windows masses don't realize is linux has these drivers already built in to the kernel mostly and rosegarden for one has a directory full of hardware midi drivers and if you don't find yours, the developers will try their damndest to make one for you.

The only blot on linux's copybook is the connecting cables - Jack having to disconnect and reconnect (please don't take this as an intellectual statement, it's simply an attempt to simplify my explanation) to accommodate daemons with higher privileges that it isn't fast enough to keep up with and on a multiplexed system RT is a major privilege which gives the application the power to screw up kernels scheduling of other software. Linux being traditionally a server work horse and relatively new to the role of PC is naturally cautious about allowing things that can cause denial of service problems. I innocently asked about jacks rpm writing to "/etc/security/limits.conf" on installation and was met with shock from the old school packagers, well just one actually who stated "I'd veto such abuse of the audio group" and would be likely to do so if I attempted to submit such a jack to factory. It was also hard to explain that jack was started by various user programs and not the user itself. We must also take into account the fact that jack can use the network as well which makes it more of a security threat (Don't tell but I sneaked a jack2 replacement for jack without remembering the aforementioned). At the end of the day though jack isn't going to be used on an apache production server but on a box that has that side of linux "dumbed down"

Jack needs RT to enable it to respond in real time to simultaneous requests from the likes of rosegarden and hydrogen otherwise the drummer will be out of sync with the rest of the band or worse still jack will become overwhelmed by the quantity of tasks that it's waiting to perform and buckle under a denial of service attack from the kernel it trusts and just freeze up, this really happens. and the users that have had linux fervently pushed upon them will shuffle back to windows and qbase be it pirated or not, the poor have no conscience about cash before copyright whereas if jack ran in real time, linux would have converted criminals into honest people.
With my hardware hat on, most audio latency problems like "echos, pops, squeeks, pauses" can be taken care of by heaps of ram or very efficient virtual memory, a couple of raid stripes but what cannot be taken care of by buffering is jacks role of conductor in the orchestra of impatient audio apps.

It's refreshing and reassuring to read the comments of the libcgroup developer, there is a light at the end of the tunnel and I must research this further, maybe we can have a "working out of the box" jack in openSUSE 11.4.
I hope my story has enlightened the doubters as to why jack needs realtime, why? for the furthering of the open source cause, that's why.
I'm speculating that libcgroup has fresh linux blood in it that cares about linux the PC as much as linux the server.

I can assure the doubters that jack needs RT privileges due to it's role as a server, the word server as in X server not as in samba server, which connects a network of applications to create audio compilations, the word "network" not to be confused with the network which is translating my key presses to this web page but more like a network of business that compliment and help each other. Jack doesn't need RT like a custom built car needs custom parts and paint work but like a tractor needs special wheels to pull the plough through the field.

Realtime group scheduling doesn't know JACK

nye — Mon, 10 Jan 2011 14:04:41 +0000

Should have added: and the answer is that there's another variable which makes it an unfair test, strictly speaking. Nobody [sensible] is using JACK in the cases where a normal desktop system would suffice, so it's only ever used under a higher load where the variance in latency can apparently be extremely large.

Realtime group scheduling doesn't know JACK

nye — Mon, 10 Jan 2011 13:58:04 +0000

I understand that, but that wasn't the situation described by the poster upthread, who pointed out explicitly that low-latency was not the issue. For clarity's sake, this is how I interpreted the situation described, as accurately as I can manage:

There exists at least one choice of buffer size which is sufficient for at least one possible purpose, with which it is possible to get skip-free audio using other sound systems on a normal kernel, but only on a real-time kernel using JACK.

Realtime group scheduling doesn't know JACK

jrigg — Sun, 09 Jan 2011 13:55:40 +0000

>Still don't see why JACK would be much worse than common desktop audio systems in this scenario though.

Right now I'm working on a recording with over 30 separate tracks of 48kHz audio, most of which have separate instances of DSP working on them. This is a fairly moderate track count. I don't see normal desktop audio creating this level of system demand very often (if at all), but it's everyday stuff in recording.

Realtime group scheduling doesn't know JACK

xorbe — Thu, 06 Jan 2011 19:38:07 +0000

Dude. Let's run the numbers on something crazy, like an 8 channel audio with insane bitrate and huge number of streams.

192000 samples/second * 8 movie channels * 4 bytes/sample * 128 streams / 1048576

That's a whole 750MB/s ... my desktop computer has 30GB/s dram bandwidth. For the highly more common 48K * 2 ch * 2 b/sample * 32 streams, the bandwidth is a pathetically small 6MB/s.

The fact that the Linux kernel can't natively handle mixing a few audio streams for the average desktop user without trotting out the anti-DoS argument is silly.

Realtime group scheduling doesn't know JACK

dlang — Thu, 06 Jan 2011 18:23:58 +0000

because int he professional use, jack needs to get audio input, process it, and play the modified version to the same people who can hear the audio input.

that means that the total latency that can be tolorated is less than for a normal desktop app, so the buffers can't be as large.

Realtime group scheduling doesn't know JACK

nye — Thu, 06 Jan 2011 17:26:09 +0000

Thanks for clarifying - though the answer is a little disappointing :P.

Still don't see why JACK would be much worse than common desktop audio systems in this scenario though.

Realtime group scheduling doesn't know JACK

farnz — Thu, 06 Jan 2011 13:18:38 +0000

Practical, real-world example. You are playing electric guitar, accompanying a friend who's singing; you've plugged the guitar and the microphone into the computer, which is recording the raw signals (for later editing), plus acting as a guitar amp, effects box and audio mixer to give you immediate audio feedback in your headphones (basically a first cut of how the final recorded track will sound).

You can't delay the (quiet) sound from the guitar strings near you; nor can you delay the loud sound from the friend who's singing. All you can do is minimise the latency in your computer, so that what you hear in your headphones (with effects applied and mixed in) is as close in time to what you're playing to give you a decent experience.

Remember, too, that you may well be experimenting ("jamming") - if the singer changes key, the guitarist may want to follow suit (and vice-versa); as that sort of behaviour is unpredictable, you can't try and play ahead to compensate for the latency.

Realtime group scheduling doesn't know JACK

jrigg — Thu, 06 Jan 2011 11:07:59 +0000

>Or maybe you mean that without RT you occasionally get such tremendous latency spikes that the buffer size would need to be absurd to avoid them.

That's what I meant.

Realtime group scheduling doesn't know JACK

nye — Tue, 04 Jan 2011 17:51:47 +0000

>More to the point, even with large buffers I can't get JACK to work properly _at all_ without RT scheduling privileges

What does 'at all' mean? Like it won't even start? Or it runs but suffers constant underruns? Presumably not the latter since larger buffers should eliminate that problem. Or maybe you mean that without RT you occasionally get such tremendous latency spikes that the buffer size would need to be absurd to avoid them.

Just interested really since the behaviour you see doesn't seem intuitive.

Realtime group scheduling doesn't know JACK

nye — Tue, 04 Jan 2011 17:37:14 +0000

>On a typical PC JACK can get that delay down to the almost imperceptible where a typical non-realtime audio framework struggles to keep it sub-second.

Ouch. My only experience with lowish-latency audio on Linux was back in 2005 when I was trying to make WoW in Wine as responsive as possible. At the time, the buffer could be squeezed down to about 90ms, but any lower would risk very occasional underruns when under heavy load (and always caused by disk activity, not CPU) - becoming quite frequent underruns by the time you got to a target latency of 50ish. Using rt could push it a couple of 10s of ms lower but wasn't really necessary for gaming and came at a cost in throughput.

If we now need rt scheduling to avoid being several times worse than we were on cheap hardware years ago, then something is surely wrong. I wonder if this difference is due to software, or the continued decline in quality of audio hardware (eg. all mixing is done in software nowadays because the hardware can't do it).

Realtime group scheduling doesn't know JACK

tseaver — Thu, 23 Dec 2010 15:38:13 +0000

> Why is the latency between audio input -> audio output be any more
> difficult than the latency between USB input -> video output?

When doing multitrack recording, the performer is listening to the audio
output while singing / playing / speaking in time with it. Any human-
perceptible latency in the loop interferes with her ability to perform
well: lags are *incredibly* painful in this situation.

JACK-with-RT makes it possible to drive the latency down to a few
milliseconds (two on my laptop, using a decent USB audio interface),
making it again pleasant (even possible) to do multi-track work.

Realtime group scheduling doesn't know JACK

jwakely — Thu, 23 Dec 2010 11:05:28 +0000

> You're still missing the point that the latency only matters if the computer is both taking input (e.g. midi keyboard) and also creating the output (e.g. synthesized audio).

The computer could be taking multiple inputs, both midi and audio, and having to send audio output to an effects unit when then comes *back* as input again, and sending midi output to other sound modules which might be sending their audio output directly to a speaker, not back into the computer where it could be buffered to re-sync.

It's really not as simple as just lining up a few different audio sources.

Realtime group scheduling doesn't know JACK

nicooo — Thu, 23 Dec 2010 09:05:18 +0000

> But at the end of the day, for your average Joe, occasional latency spikes are not a big deal.

Not a big deal because they don't know that latency spikes shouldn't happen in the first place. Like Windows users who think it's normal to reboot the computer every time they install/update a program.

Realtime group scheduling doesn't know JACK

omez — Thu, 23 Dec 2010 06:37:29 +0000

Depending on your game, you can easily replicate the problems JACK is suffering. A player can learn to see past consistent quarter-second network latencies in a fast paced game. If the apparent latency changes because the kernel wants to contemplate its navel for 100ms, however, all bets are off. You will be a sitting duck, fragbait.

Realtime group scheduling doesn't know JACK

quotemstr — Wed, 22 Dec 2010 23:04:19 +0000

What's the big deal? Just allow realtime privileges for all cgroups by default and use rlimits to control access. Why bother trying to restrict realtime access by default using cgroups when we already have unlimits?

Realtime group scheduling doesn't know JACK

jrigg — Wed, 22 Dec 2010 21:01:39 +0000

Low latency can be useful as you say. On my own systems I've never worked that way, but I'm aware that many do.

More to the point, even with large buffers I can't get JACK to work properly _at all_ without RT scheduling privileges, so low latency is a bit of a distraction in this argument IMO. JACK needs RT privileges just to work reliably without being pushed aside by anything else the system might be doing.

Realtime group scheduling doesn't know JACK

dlang — Wed, 22 Dec 2010 20:59:36 +0000

I wasn't thinking in terms of micraphones, but in terms of digital instraments that only output MIDI and it's not until much later that there is any analog.

but I agree that low latency isn't the only reason.

Realtime group scheduling doesn't know JACK

jrigg — Wed, 22 Dec 2010 20:42:34 +0000

Yes things are increasingly digital, but I've never seen a situation in my work where there wasn't an analog signal available somewhere, even if it's only a microphone preamp output. I'm aware that there are microphones that give a digital output, but so far their market penetration in pro audio is very small.

My main point was that low latency isn't the only reason for requiring RT privileges.

Realtime group scheduling doesn't know JACK

jebba — Wed, 22 Dec 2010 20:41:50 +0000

> There seems to be quite an emphasis on low latency in this discussion. When recording, the issue of latency can be side stepped by monitoring direct from the mixing desk or microphone preamp, or if your interface permits, low latency monitoring from its internal hardware.

Yes, it can be done that way, but if you *do* have low latency it can be easier to do it all in ardour's mixer. I would set up an ardour channel for each set of headphones and send a different mix depending what the person wanted (e.g. a bassist and vocalist may want to have different instruments emphasized).

Realtime group scheduling doesn't know JACK

jrigg — Wed, 22 Dec 2010 20:09:55 +0000

>I'm trying to understand exactly what the audio use cases are that make processing 48 KHz data so difficult.
If you're processing a lot of tracks simultaneously the throughput can be quite high. In film soundtrack work it's not uncommon to be working with a hundred or more tracks at once.

Realtime group scheduling doesn't know JACK

dlang — Wed, 22 Dec 2010 19:56:18 +0000

that assumes that you have an analog signal at some point to tap into and monitor.

increasingly things are digital for large portions of the path, and may only become analog when they go to the amplifiers.

Realtime group scheduling doesn't know JACK

jrigg — Wed, 22 Dec 2010 19:52:31 +0000

There seems to be quite an emphasis on low latency in this discussion. When recording, the issue of latency can be side stepped by monitoring direct from the mixing desk or microphone preamp, or if your interface permits, low latency monitoring from its internal hardware. These methods aren't always available, but in a pro recording situation they often are.

The most important reason for realtime scheduling privileges IMO as an audio engineer is to ensure that nothing gets in the way of audio throughput or processing. Just increasing buffer size is not an option beyond a certain point, as it is limited by the interface hardware. JACK was designed for pro audio (the fact that hobbyists and non audio engineers also use it is a side issue) and needs to perform reliably enough for those of us whose jobs depend on it.

Realtime group scheduling doesn't know JACK

jrigg — Wed, 22 Dec 2010 19:07:49 +0000

>Can you provide a more specific example setup where you'd see the problem you describe?

Recording musicians. If there's no way of monitoring what is being played direct from hardware (which is sometimes the case) there needs to be minimal latency between a musician playing something and hearing it back from the recording system, otherwise the musicians can't play in time with each other. If you're paying top money for studio time and session musicians, what might be near enough for a "Guitar Hero" type game isn't good enough. A 20ms delay is enough to cause a problem (musicians don't tend to stand 20 feet from each other in a studio).

There's also the situation when recording or mixing a lot of tracks, possibly with lots of DSP going on, you need certain things to happen within a short deadline to avoid audible dropouts. Large buffers help, but if your system decides to put audio on hold while it does something else it's pretty inconvenient (and in professional audio, inconvenience = cost).

Realtime group scheduling doesn't know JACK

Cyberax — Wed, 22 Dec 2010 16:24:25 +0000

>The speed of sound in a low humidity environment is going to be something like 350 to 400 meters per second. I've heard that humans can't distinguish 10msec from instantaneous. That would be somebody standing about 4 meters away from you making a sound.

Human ear can distinguish about 500 microsecond difference. I.e. a difference in distance of about 20 centimeters. Humans use this for directional hearing.

That's why smallest possible latencies are so important.

Realtime group scheduling doesn't know JACK

drag — Wed, 22 Dec 2010 12:25:21 +0000

> That's my whole point -- there is a whole world of other systems that (to me) seem much more demanding than audio processing, like video input and output, and gaming, that don't seem to have the realtime requirements or problems of JACK. I'm trying to understand exactly what the audio use cases are that make processing 48 KHz data so difficult. And it seems like the answer is the specific case of live looping back audio from input->output which needs low latency.

It's not just _LOW_ latency.

Realtime configurations give you the ability to _CONTROL_ latency.

That's the point.

Often stuff running realtime will have significantly worse performance then if you had them in the normal configuration.

Linux is designed to provide high throughput and work efficiently under high loads. The design choices and compromises that goes into making Linux behave well and perform well under high loads is COUNTERPRODUCTIVE to providing good realtime performance.

It's not a question on how demanding the workload is, it has to do with your ability to control how often something happens and when it happens.

THAT is what realtime performance is about. Not making your system work faster, quicker, or perform better... it's just a question of being able to control latencies. Without realtime configurations you can see latency spikes up to 250msec or more on a regular basis for Linux. It's just a nature of the beast.

And of course even with Linux in 'realtime mode' it's not perfect and can't guarantee you with 100% latency control.. Linux is far too complicated for that, but it does help tremendously.

Realtime group scheduling doesn't know JACK

nix — Wed, 22 Dec 2010 12:00:59 +0000

Actually one of the ways to play it *is* with headphones that pick up what you're hearing and rebroadcast it to you delayed by just enough (a changing delay): then all you have to do is keep what you hear from becoming phased! (Another common way, and probably the more effective one, is to play the second part without a tape of the first part at all, just with a metronome beat defining when the first part's beats are, then mix the two together later. But you can't do that live and it feels obscurely like cheating. Live performers generally have to do it without any artificial assistance at all, and that *is* hard.)

Realtime group scheduling doesn't know JACK

tetromino — Wed, 22 Dec 2010 10:12:30 +0000

> which latency is the concern?
The problem is with the latency between the moment a musician hits a key or a string, and the moment when he hears the result played back to him. This latency has to be low and predictable enough to be unnoticeable for a professional musician, who expects his new-fangled smart musical instrument with Linux inside to respond perceptually instantly, just like an old-fashioned mechanical device.

Realtime group scheduling doesn't know JACK

baldridgeec — Wed, 22 Dec 2010 02:04:07 +0000

(Just looked them up, never heard of them before, interesting! I'll have to find some recordings)

From what it says on Wikipedia, it's played as a duet - i.e. the music you play is still in time with itself; your part is in phase with the other part.

Still hell to play, yeah, but it would be pretty much impossible if the sound from your own piano were to come at you with an audible delay. It would be easier to play if you were deaf - at least then nothing would interfere with the rhythm in your head.

Realtime group scheduling doesn't know JACK

nix — Wed, 22 Dec 2010 01:51:41 +0000

Actually you *can* train yourself to do it: I can think of several works in which you have to (the Phase works by Steve Reich, for example). But they're rare, and it's difficult, and you really wouldn't want to do it for everything.

Realtime group scheduling doesn't know JACK

jebba — Wed, 22 Dec 2010 00:39:57 +0000

> Surely you would agree that latency doesn't matter at all if you are e.g. recording singing from a microphone to accompany a guitar track you are playing back.

Not if you are sending that voice back to them so they can hear it in the mix, which of course they have to. Send it to the singer with high latencies, and he looks at you like "WTF??!" because it throws them off rhythm, which is kind of important.

Realtime group scheduling doesn't know JACK

baldridgeec — Wed, 22 Dec 2010 00:35:48 +0000

Composing, even electronica, is also "live" unless you're doing it in a MOD editor from the 90s.

When I'm playing my electronic drum kit using Hydrogen to provide the samples, BELIEVE ME, there is a very very noticeable difference between hearing your snare strike 10 ms after your stick hits the pad and 50 ms after your stick hits the pad. 50 ms is still playable if it's consistent, and if you practice at it a bit - some people use Windows, after all, so it obviously works, even if it's not ideal. :)

But 100 ms is not usable at all. A tenth-second gap means there is no relation whatsoever between the part of the phrase in your head (that is currently being conveyed through your hands to the equipment) and the part of the phrase coming into your ears and being interpreted by your brain as "what I'm playing right now." You can't force half of your brain to work 1/16 note in the past at the same time as you play what you need to for the present. It just won't work.

Realtime group scheduling doesn't know JACK

chad.netzer — Tue, 21 Dec 2010 23:21:32 +0000

"Surely you would agree that latency doesn't matter at all if you are e.g. recording singing from a microphone to accompany a guitar track you are playing back."

Nope. Singers like to hear some of their voice fed back to them. It's not uncommon for unconstrained musicians to move to the corner of a room, to best hear the reflection of their voice and instrument (at low latency). If they are using headphones, the audio equipment has to provide that feedback loop. It is not an "offline" operation, where latencies could be ignored (or corrected).

Realtime group scheduling doesn't know JACK

sfeam — Tue, 21 Dec 2010 21:50:42 +0000

"Surely you would agree that latency doesn't matter at all if you are e.g. recording singing from a microphone to accompany a guitar track you are playing back."

Next time you go to a performance with amplification, pay attention to what happens during the sound check. Pay particular attention to the small monitors near the front of the stage that point back at the performers so that they can hear the mix of what they are singing into the mic with the rest of the input. Chances are that you'll hear the performers request more or less feedback from the monitor, because getting it right makes it a whole lot easier to perform. You can't just sing, or play, into a vacuum and somehow know that it's coming out right. The feedback of your own mechanical actions, voice or fingers, to your ears is crucial.

Realtime group scheduling doesn't know JACK

jimparis — Tue, 21 Dec 2010 21:44:12 +0000

You're still missing the point that the latency only matters if the computer is both taking input (e.g. midi keyboard) and also creating the output (e.g. synthesized audio). Surely you would agree that latency doesn't matter at all if you are e.g. recording singing from a microphone to accompany a guitar track you are playing back. They can be perfectly synchronized in software to match what you heard while singing.

I think my only real error was underestimating how frequently people need to either apply live digital effects or otherwise play live synthesized audio from live external triggers, which sounds like "always" from what people are saying here.

Realtime group scheduling doesn't know JACK

sfeam — Tue, 21 Dec 2010 21:36:19 +0000

You are clearly speaking from the perspective of someone who is not a musician. If you're the one playing the keyboard, you really do notice and suffer from a lag in response on the order of 10-20 msec. Buffering in the computer doesn't help; you'd need the buffering to happen in your brain. Yes, you can train yourself to deal with it up to a certain point. It's like playing as part of a live ensemble split between two sides of a large stage. You are focusing on the path after the signal enters the computer, forgetting that the human brain is on both the input and output side. The musician needs what the ear hears to be in sync with that the hands play.

Realtime group scheduling doesn't know JACK

jebba — Tue, 21 Dec 2010 21:35:54 +0000

> It really seems to me like the approach of audio guys is to try to get latency to zero, rather than accepting variable latency and simply accounting for it with larger buffers and proper timestamping

Uh, no. In fact, you can't do jackd with 0 latency and that isn't the goal. RTFS. Your scenario is FAIL and it is clear you have never used it in production. Why not actually listen to the people that actually have done this?

Realtime group scheduling doesn't know JACK

tialaramex — Tue, 21 Dec 2010 21:25:28 +0000

Not just audio input, any case where input passes through the JACK system to become output. That's what latency is! For example, from thumping the concert A on a MIDI keyboard to hearing the sound from the software instrument. The larger the buffer, the longer it takes.

Or consider DJing. Suppose we just have a 2 second buffer. So I hear the end of track A, there's a boring instrumental lead out, I want to play track B - must I wait 2 seconds before it begins? That's a long time. OK, so maybe we provide the DJ a separate mix. Now I can hear where track B will start playing, but it takes 2 seconds before I hear my own decisions. This is very difficult to work with.

You can play with this, if you have lab audio equipment, create a 2 second delay audio loop, where what you say is recorded and then played back quietly through headphones (so it doesn't feed back). You won't be able to hold a conversation properly, because you must concentrate very hard just to override a built-in audio-cognitive mechanism that tells you you're being interrupted. Reduce the loop to 15ms. Now it's fine. The much shorter delay resembles environmental echo, which was present when our audio cognition evolved. Latency matters.