The latency(different type I believe) of Spotify applications and even YouTube applications is pretty bad compared to an Apple device. Sometimes the audio just fails to respond for half a second or so. This is not an interface bug from my experience.

Edit: I've been thinking about this and a touch-to-tone latency below 10ms seems imposible, even with the 120hz digitizer on newer iPhones. I would be very interested in seeing some experimental data as well.

[0] https://juce.com/discover/stories/Mobile%20performance%20ind...

The audio processing latency seems to be single digit on both systems.

In any case, I don't think these differences are big enough to argue that "Android can't be used for instruments".

Well financed developers like ROLI already have instruments on android. I think the incredible instruments available on iOS are also there because the App Store promise actually kind of works for them. They write a great application, upload it to server and people buy it for more than 2.99$, upfront. And unlike VSTs, no one even pirates it. The general idea/stereotype is that no one wants that on android. An open source port of VCV Rack would be feasable and wonderful though. That's the only free instrument I have installed on my music iPad.

Edit: nevermind, that was not free either.

We should not forget that our brain is great at adjusting to latency. In the old days, when I was excessively playing Quake 3 Team Arena it took me just a couple of minutes to adjust to network latency depending on the server I was connected to.

Professional musicians do this constantly and are much better at that.

There’s this video around that puts people in a VR helmet playing A/V with a delay, even the lowest setting completely destroys any form of efficiency.

Anything below 60Hz in VR has a significantly increased chance of giving motion sickness due to latency.

Playing Super Mario Bros in an emulator is strangely subtly harder than on the real NES hardware, just because of a slight lag added (can’t recal on NES but on SNES buttons literally bit-flip the RAM, hard to beat that). You can train all you want on an emulator, when you get back to the real thing it’s obvious it was just so crippling.

Try Guitar Hero / Rock Band with various audio / video latency settings. 10ms is obviously impactful, anything higher borderlines on unplayable, and even 5ms has a subtle impact increasing missing notes.

As for pro musicians, they absolutely loathe latency. This is why bassists (tempo) / drummers (rhythm) / conductors (tempo) exist: they serve as a single source of truth to sync on. In fact, we’re so sensitive to latency that the slightest deviation is unbearable, hence why following them put you back in sync. Same for effect pedals, amps, feedbacks... any latency is destroying.

Try playing on Zoom, it’s absolutely impossible (unless you assume latency is fixed, which it is not, and play in a tempo matching latency exactly, and follow the lead but time-warp your play by one beat, which I imagine is possible as a sort of canon but absolutely horrendous) unless you completely ignore the other part and find a common time source to sync upon.

Now you mention Quake 3, and it might just be you were severely misled by several critical innovations that game introduced, like network prediction and frame interpolation, negating most of the practical effects of latency.

https://www.jfedor.org/quake3/

Lag comes from video. If you do not use FPGA emulators like Mister the video delay is enormous.

I don't understand what you are calling 10ms lag. Have you measured the delay between your computer and your screen? It is way bigger than that, in any computer or NES console(console-TV).

Are you maybe referring to 10ms NETWORK packet delay? All TVs or projectors use buffers, and it takes time for information to travel around serial cables.

Network delay is inconsistent, but electronic delay is not.

That’s exactly what I said ;) By virtue of being a different platform, emulation introduces a lag that is just not present on the real hardware (and can’t be lower by virtue of literally being a wire to memory). USB alone often introduces an astoundingly high minimal floor on latency.

> I don't understand what you are calling 10ms lag. Have you measured the delay between your computer and your screen? It is way bigger than that, in any computer or NES console(console-TV).

Yes I have measured it (on all my devices, accurately so) in order to minimise it as much as possible (I can work with but can’t stand latency, even in a terminal).

Rock Band, which I used to be an avid player of, allows you to adjust a relative delay (audio and video separately), timewarping A/V so that all three are perfectly in sync relative to real-world input.

> Network delay is inconsistent, but electronic delay is not.

I agree (and agree to buffers as well), but by and large any modern device is far removed from being just electronic, from USB (USB 2.0 has a 125us polling loop for multiplexing, USB 3 is point to point so can fare much better at 30us, but even then there’s kernel context switch to read and process that data) to HDMI (packet based with loads of multiplexing), many things end up being surprisingly subject to soft-real-time firmware/software before it hits the display itself. Hard real time stuff probably exists because the specs now allow for it but good luck finding that in consumer space where it’s much easier (read: cheaper) to push a best effort implementation.

But my point isn’t about the minutiae of lag source, it’s that the human brain is severely impacted by lag, can adjust to some extent but the cost is paid heavily at multiple levels and with various efficacy crippling consequences; and that Q3 and subsequent games have increasing numbers of facilities to create the illusion that everything happens in sync so that we’re not so impacted by it.

The brain can compensate for lag/latency up to a point. Church organ players often have to deal with >100ms of delay between pressing a key and hearing the note produced through those big pipes.

If you have an app which produces a sound when you tap on the screen, and there's a delay of say 70ms between tapping and sound being produced, it's easily possible to play in time with an external clock source, like a metronome, as long as the delay is fixed.

In the 1968 paper "Response time in man-computer conversational transactions" actions which occurred within 100ms the human input were perceived as instantaneous. In my experience this holds true with musical instrument apps, although one must first learn how much latency is present in order to compensate for it when synchronising with other clock sources.

The fact that the effects are laggy doesn’t mean you need to sync on them, you’re mostly listening whether the sound envelope is correct (e.g adjust for overshoot/undershoot a bend). Checking the output of effects only matters at timescales of whole beats/measures in terms of how you have to react, definitely not like keeping up with tempo, which has to be precise across the band.

You don’t get delay on drums, and exceedingly rarely so on bass, which is what you have to react agains efficiently, plus the instrument you’re playing provides its own subtle and not-so-subtle haptic feedback. On a guitar, this means the moment you pluck the chord is based on your internal clock synced by listening to the tempo giver (usually bass).

Source: amateur musician myself, wife is pro.

Zoom's latency isn't fixed, so that won't work. On the other hand, it is possible to do something like this over the internet by measuring latency and then adjusting for it: www.jefftk.com/p/bucket-brigade-singing

I think there is a subtle difference between fps (avg) and latency. I would say that a 'stable' latency is always better than a high fps.

> Try Guitar Hero / Rock Band with various audio / video latency settings. 10ms is obviously impactful, anything higher borderlines on unplayable, and even 5ms has a subtle impact increasing missing notes.

Do you mean that you set an additional latency for both video and audio? Or you delay only the audio by 10ms?

Yup, I only mentioned 60Hz, because 16.667 ms is more obvious WRT latency but less known.

> Do you mean that you set an additional latency for both video and audio? Or you delay only the audio by 10ms?

No, RB allows you to set up the audio and video latencies, and since the track is fully known, it’s able to apply negative latency to everything but the input (which, being physical user input, is the only thing that can’t be altered).

So you set up input->audio latency and input->video latency values and the game will internally play them ahead, so that they appear exactly in sync in the physical world.

A physical piano with a 1.2" hammer blow distance played at soft velocity (~2.2mph), assuming distance of closest resonating surface to ear is half meter, would have around 35ms latency.

My impression is that Android has more latency variance than iOS. If that's true then it's important to be clear what the reported numbers represent.

Also from talking to an engineer who worked on earlier generations of iphones, who said that every team had a latency budget that they could not exceed.