Hacker News Reader

Audio latency might not event be the main issue here: Touchscreen latency is far worse which makes any input almost useless for someone trying to actually play notes. Note that changing parameters of filters, synths,... is fine because changing these does not require the same precision as playing.

Btw if you're looking for a subjective number for tolerable latency I'd say ~5ms. This could be output latency if you're playing notes via midi or round-trip latency if you're processing incoming sound and output it again. In my experience you don't get that acceptable latency on notebooks with the onboard sound cards either :)

5ms is bit on the low side. If you're playing from guitar amplifier that's 4 meters from you, you get 12 ms latency just from sound propagation (and most amps introduce additional latency). As extreme example of what the brain can compensate, church organ players have to deal with 100ms+ latency and they still manage to play Bach.

You can compensate for latency with a lot of practice, but playing anything with a sharp attack is not joyful when it's over 10-20ms -- especially so if you are used to playing an instrument which doesn't much of it (i.e. pretty much anything but a church organ :) )

And guitar (and piano) are classified as percussive instruments, for though they have strings, the strings are struck.

> church organ players have to deal with 100ms+ latency and they still manage to play Bach.

but they don't play Bach on pipe organs with a drummer

No, they play it with a choir.

Though perhaps they should.

Can confirm— I'm a piano player who did organ a few times for funerals and the like without having had formal training. If you try to match what you're hearing like on a piano, you'll end up just playing slower and slower; you basically have to play to a click track, either an actual one or the mental equivalent.

When using MIDI, its maximum bandwidth is going to be a huge bottleneck in achieving that kind of latency. At 31250 baud with eight effective data bits per 10 bit packet you're going to get an additional 0.32 ms of latency per byte.

So let's say that you are playing a simple three-note chord. Optimally, MIDI encodes this as a single status byte followed by three note+velocity pairs of data bytes. Just that is going to make something that should be instantaneous take 2.24 ms. Now add some CC messages, maybe a couple more channels, sync bytes etc. concentrated around rhythmic subdivisions and it's easily going to add up to 5-10 ms latency. And not just fixed latency, but jitter since the messages of course come in at different times.

Then, if you use a computer running Windows/Linux/OSX, you should probably account for MIDI driver latency and jitter as well. Maybe you are running a couple of instruments chained, at which point you'll also have to account for the latency between the input and the through output.

I easily hit the threshold where it's not only perceptible for the player but for a casual listener as well, but it's hard to say that it isn't "tolerable" when so much music has successfully been played and recorded with these limitations. Seems weird though that the industry has settled on this 80s protocol built for 80s machines. There's OSC (which is quite underspecified for the problem MIDI intends to address), some individual efforts by manufacturers (e.g. Turbo MIDI by Elektron) and recently talks of a "MIDI HD" protocol. I hope something happens soon that all manufacturers can hop on board.

This is correct but multiport interfaces don't add up those latencies: it is very rare that although a midi data line can drive 16 channels and corresponding instruments, all of them are chained or paralleled via MIDI thru boxes over a single data line (ie, a single MIDI OUT). Data is a lot faster inside the PC and the DAW, so that if you have a multiport MIDI interface, connecting your expanders on different outputs - although not necessary if they use 16 channels or less - will indeed reduce the total latency.

Totally agree about the limitations of MIDI, but it was conceived when I think the only alternative was the Roland DCB which would was even more limited and would cost a fortune in connectors. Today I would use "something" over Ethernet phy: open, very cheap, very fast and near realtime.

> This is correct but multiport interfaces don't add up those latencies:

Well, it still adds up as far as you use the individual ports. If have a single keyboard controller with modulation and pitch bend wheels connected to one port I don't think it's far fetched to say that the latency of the MIDI messages for some instant action can add up to >5 ms on its own. Might be hard to notice, but that's my point! At that latency you might as well be discussing how close you should sit to the speakers. If you're 1.72 m from your speakers, that adds +5 ms latency. I'll reach that distance if I stand up playing with a stage monitor at my toes.

That said, I think that 5 ms here and there does matter. For example, 5 ms vs 10 ms audio buffers on a PC felt like night and day to me. The total time from finger to ear was probably already twice that, but it seems that shortening the audio buffer crossed some threshold where it suddenly didn't feel like I needed to adjust my playing for the latency.

I agree that Ethernet would have made sense today, and I think that some manufacturers already support something like that.

> The "lowest possible" on android might not be low enough for musical instuments (<10-15ms). It's revealing that they don't reveal latency for any devices at all. (If I sound cynical, this isn't the first low-latency offering for android.) It's just "low" for android.

That's probably because talking about "the latency" for Android varies with actual hardware capability. It's like talking about "the latency" for Windows and Linux and forgetting that it's very bound to the actual hardware lying underneath. There are Android devices that achieve your desired level of latency, but obviously they're rather high-end and new.

The cross-platform audio app library JUCE has a benchmark on mobile audio quality published for a lot of phones. Basically only the Pixel and Nexus phones are even close to Apple devices, and for most android phones, the situation is abysmal.

https://juce.com/maq