[HN Gopher] An update on Android's audio latency
___________________________________________________________________
An update on Android's audio latency
Author : ingve
Score : 79 points
Date : 2021-03-05 19:47 UTC (3 hours ago)
(HTM) web link (android-developers.googleblog.com)
(TXT) w3m dump (android-developers.googleblog.com)
| AdmiralAsshat wrote:
| Too little, too late, I'm afraid.
|
| The improvement is great, but I think the audio professionals
| jumped ship long ago to Apple, and they're not going back. I know
| of several music professionals plugging into their Macbooks or
| iPads as part of the pre-amp, but I don't know if _any_ using
| Android. Google sat on this for way too long while Apple courted
| the creative professionals, and for any that have already made
| the upfront buy-in for Apple hardware, I don 't see them taking
| the risk of switching ecosystems to save a few dollars for
| performance that _still_ won 't match what they're used to.
| deadmutex wrote:
| Perhaps. Though I wonder if every musician afford Macbooks or
| iPads. These things are not cheap, especially if you consider
| earnings of non-US based musicians, etc.
|
| Disclaimer: Googler, but opinions are my own.
| Hemospectrum wrote:
| Musical instruments aren't too cheap either. Drummers and
| guitar players can get good stuff secondhand, but most
| synthesizers will run you way more than a mid-range MacBook
| and a copy of Logic. God help you if you need a piano...
| ocdtrekkie wrote:
| This is where Apple's far superior product lifecycle comes
| in: Buying a four year old Apple product is affordable, still
| runs the current OS, unlike Androids that old, and has the
| audio performance down.
| zachruss92 wrote:
| This is a valid point, but it's hard to place the blame on
| Google/Android. I think the challenge is less of Android
| itself but a refusal of the OEMs to support newer OS
| versions. This makes business sense, but sucks for
| consumers.
|
| I think Google is doing a better job with their Pixel
| devices. I honestly hope they try to lead the Android
| industry more with them.
| dmix wrote:
| There will _always_ be a niche that wants to do music
| production or engineering and can 't afford Apple productions.
| Newbies or living outside the western world for example.
|
| Just because the pros have merged towards a single brand
| doesn't mean that the only other smartphone monopoly won't
| benefit greatly from offering other high quality solutions.
| Jeff_Brown wrote:
| The figure of most interest to someone playing an electronic
| instrument is "tap-to-touch latency". The article indicates a
| minimum of 43 ms for that (28 round trip latency - 5 audio input
| latency + 20 touch latency). That's like ten times what you'd
| hope for.
| hnuser123456 wrote:
| deleted
| thomasahle wrote:
| In case of audio it doesn't really matter how fast the
| display updates though? Unless your numbers are for the
| digitizer and not the screen.
| fireattack wrote:
| We're talking about tap-to-audio-output latency though, so it
| has nothing to do with display part of the screen.
|
| And there is no "touch" on PC generally speaking.. input
| latency would be on mouse or keyboard.
|
| I think you're talking different thing from the topic.
| Drakim wrote:
| Emulators of old retro games also care about audio latency, as
| the emulated audio is generated on the fly by a turning
| machine, which makes it very hard to match visuals to audio if
| there is inherent audio latency.
| mellosouls wrote:
| Would be nice if they could do something - presumably far simpler
| - about the lack of fine-grained volume control.
|
| It might be a niche case, but it's really frustrating using the
| various sleep-related audio apps at night with earphones and not
| being able to select a minimum volume that is both loud enough to
| hear but not so loud it keeps you awake (example: Audible with a
| sleep timer).
|
| I'm sure there are other uses for the finer control as well.
| Kuinox wrote:
| "Popular smartphone" list only samsung smartphone.
| wffurr wrote:
| That's true for the 2017 chart and probably was true in 2017.
| The 2020 chart lists Huawei, Oppo, Xiaomi.
| Kuinox wrote:
| In 2017 huawei was huge (in popularity), even bigger than
| samsung.
| bitmapbrother wrote:
| Perhaps you should read the article in full. It clearly says
| the most popular Android smartphones in 2021 are:
|
| Samsung
|
| Redmi
|
| Oppo
|
| Huawei
|
| Vivo
|
| Which probably account for the majority of Android smartphone
| sales.
| Kuinox wrote:
| Perhaps you should read the article, "Latency of the most
| popular android phones in Jan 2017" list only 20 samsungs.
| Robotbeat wrote:
| Responsiveness and low input-to-result latency was why I chose
| iPhone over android 10 years ago even though I prefer a more open
| environment like android. Sounds like things haven't changed a
| whole lot on that front.
|
| Sometimes I wonder if these increased levels of abstraction and
| even digitization itself (or at least the Internet-ization of
| things) is a mistake for human-machine interface. Watching drone
| racing pilots use analog controls and analog video headsets in
| spite of the potato resolution because WiFi/digital/etc just add
| too much latency is kind of eye opening and makes you sort of
| reconsider the last couple decades. (Improvements have been made
| so digital isn't so high latency and VR has served to address a
| lot of these latency concerns, but it's still kind of
| interesting...)
| karlding wrote:
| Andrew Huang recently made a YouTube video [0] that provides some
| insight from the perspective of a music producer and someone who
| recently created a music production app. It's not overly
| technical, but it highlights some of the challenges one might
| face.
|
| As the article says, there is room for improvement, so I guess
| it's good to see that the long term goal is 10ms round trip.
|
| [0] https://youtube.com/watch?v=-sPbcTcUmcI
| Naac wrote:
| That was a strange video. It seemed like he started talking
| about latency between Android and IOS devices, which makes
| sense given that this article talks about response time of just
| under 40 ms like you said. The article says this is "well
| within the range required for real-time applications" if you
| define real-time applications as non-pro-audio stuff. If you're
| playing an instrument and it takes 40 ms for you to hear back
| the sound, that's Not Good.
|
| But then the video takes a strange turn and starts talking
| about "Stability" of mac vs PC, and I had to turn it off. It
| made the argument that "I haven't seen any professional
| producers use anything except macs" as its main argument.
|
| It would have been nice to hear some more technical information
| like mentioning core-audio, or something else.
|
| Regarding the article itself. I'm excited that Android is
| target less than 20 ms round-trip latency. I'm hoping that this
| work can be brought back to the Linux Desktop. Messing around
| with Jack and dealing with xruns is something I wish I could
| stop doing.
| Daho0n wrote:
| >"I haven't seen any professional producers use anything
| except macs" as its main argument.
|
| Yeah that is both totally irrelevant to the topic at hand and
| also a bit strange. I have only seen PCs in the pro studios I
| have used but that doesn't make me believe nothing else is
| used.
| smoldesu wrote:
| Same here. I've even seen an increased number of Linux-
| based studios, oftentimes running Bitwig or Reaper. I don't
| doubt that audio latency can be a little high on some
| workflows, but I've honestly had a less laggy experience
| with Pulse than Coreaudio. Out of the box, Bitwig has a
| latency of ~8ms on my (Linux) machine, as opposed to 20ms
| on my Macbook.
| ubercow13 wrote:
| Linux audio can be real bad but the one thing that could
| possibly make it worse is taking anything from Android.
| Android is the only computing platform I have ever used that
| was unable to play a simple audio file through without the
| audio dropping out at least once (I had the same experience
| on multiple devices, 5+ years apart).
|
| Have you looked at Pipewire?
| Naac wrote:
| I've started to. But I haven't done enough research on how
| all the other applications I use ( Carla, Ardour, soft
| synths, etc ) will play along with Pipewire instead of
| jack.
| com2kid wrote:
| It'd be nice if something was done about the extra 100-200ms (!!)
| of latency that Bluetooth headsets can add[1]. I understand this
| is largely a problem from the manufacturer problem, but I'd love
| to see Google lead the way with some sort of certification
| program, or even make their own low cost BT chipset for 3rd party
| headphones to use, to improve the situation.
|
| Of course Android is already world's better than desktop, where
| 200ms is seemingly closer to average than an outlier.
|
| It is also kind of cool that perusing that chart, it seems
| headsets connected to Android have, on average, lower latency
| than when connected to iOS!
|
| https://www.rtings.com/headphones/tests/connectivity/bluetoo...
| kevingadd wrote:
| There are low latency bluetooth protocols, if you sort by
| latency on rtings for aptx-LL you can see some headsets are
| down below 40ms. Of course, this relies on both the host and
| the headset having support for the protocol and being
| engineered well. SBC and aptX just aren't designed for low
| latency, and low latency is something that can't be hacked into
| every codec after the fact.
| com2kid wrote:
| I'll argue that an device meant for phone calls (which is
| where bluetooth audio started out!) should aim for low
| latency by default. I also understand that the
| CPU/Latency/Memory trade offs made over a decade ago are not
| the same one's we'd make now.
|
| Doesn't change the fact that the same device can have a 3x
| latency difference between platforms with the same codec.
|
| Google went and developed VP9 as a royalty free codec in the
| AV space, they should do something similar for Bluetooth.
| Right now if I'm on a video call with someone and we both
| have BT headsets, it is very possible that there is a 500ms
| audio latency!
| summm wrote:
| apt-x is designed for ransom extraction via "intellectual
| property" licensing.
| matchbok wrote:
| 5 years of work, and still bad compared to what iOS had 10 years
| ago. Impressive.
| AceJohnny2 wrote:
| Usually, "an update on [blank]" is euphemism for said product
| getting cancelled.
|
| More to the point, one of PulseAudio's claims was that they
| consumed less CPU than Android's audio pipeline. With the recent
| hyped PipeWire, I wonder how that compares to Android's Oboe.
| alpb wrote:
| At Google it typically manifests itself as "Advancing our
| amazing bet" https://news.ycombinator.com/item?id=12792928
| raphlinus wrote:
| That's actually the joke here, which got a chuckle out of me.
| The idea is that excessively large audio latency itself has
| gotten cancelled.
|
| I haven't played with it myself (it's been a few years since I
| was actively involved in Android audio latency), but from what
| I've seen, AAudio is pretty good, probably close to what the
| hardware is capable of. I'd very much encourage people to do
| empirical measurements against, for example, PipeWire (which
| also looks good). Do keep in mind that constraints are
| different on mobile, and things like power management can and
| do get in the way of down-to-the-wire latency.
| jancsika wrote:
| > I'd very much encourage people to do empirical measurements
| against, for example, PipeWire (which also looks good).
|
| A rule of thumb from reading linux audio mailing lists but
| which probably works generally-- _completely_ disregard any
| claim of measurement of latency that isn 't prefixed.
|
| For example, the Google blog labels the Y-axis with "round-
| trip time in milliseconds." They're clearly and explicitly
| measuring round-trip latency. They then piggy-back on that
| well-understood concept to introduce the concept of "tap-to-
| tone latency" and show measurements for that.
|
| Almost to the case, the times I've read a back-and-forth
| conversation where the word "latency" is used unprefixed, the
| commenters might as well be describing the warmth of vinyl
| recordings. Often they are simply describing an integer they
| typed into a widget or config file.
|
| On several occasions I've witnessed users insert Jack between
| a single application and ALSA because "that's what the
| professionals use." These are knowledgeable users who want as
| little latency between the system and their ear as possible.
| adamnemecek wrote:
| 28ms is still like twice as much than one would want. And
| accounting for fluctuations, it's like four times as much.
| fireattack wrote:
| I chuckled at the fact that their figures still have spell
| checker wavy underline :p
| AndrewDucker wrote:
| What's the equivalent latency on an iPhone?
| leecb wrote:
| The most common results on this page indicate that it varies
| with buffer size, but could be 9-11 ms for iPhones.
| https://superpowered.com/latency
| fireattack wrote:
| I feel like their app (or method) is flawed in some way. It
| can't be that many phones have 300~400ms+ latency.
|
| Anyway, the number we have here should only be compared with
| the number of Android in the same post, not the one mentioned
| in OP's post since the methodology won't be the same.
| apecat wrote:
| Can't wait for Roland, Yamaha et al. to build awful Android-based
| touchscreen UIs for all upscale music gear with built-in control
| dashboards
| nkozyra wrote:
| Versus the bad custom linux flavors & UIs they currently use?
|
| I'll take it.
| apecat wrote:
| You have a point, but my main concern is just the inevitable
| internet-connected app ecosystem for expensive and cool
| devices that are going to have a security patch lifecycle of
| 18-36 months with an expected lifespan of 15 years for second
| and third owners
| jefftk wrote:
| This is way better than it used to be (I measured half a second
| latency in 2012: https://www.jefftk.com/p/android-sound-
| synthesis-and-latency) but it is still too high to let you use an
| Android device as a musical instrument. This is something iPhones
| have always been able to do, and one of my biggest
| disappointments with Android.
|
| (Disclosure: I work for Google, speaking only for myself)
| limeblack wrote:
| I agree audio at minimum should have been done differently on
| Android.
|
| 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.
| thomasahle wrote:
| What are the equivalent numbers for iPhone? Touch to audio and
| round-trip times?
| jefftk wrote:
| https://superpowered.com/latency has messy data, but it looks
| like typically single-digit latency.
| S_A_P wrote:
| I think typical newish (2014+) devices have between 5-9ms
| latency. Having core audio from the start was a huge leg up
| for iOS for sure. I am mostly platform agnostic unless I am
| working with audio where I pretty much only use Apple
| products.
___________________________________________________________________
(page generated 2021-03-05 23:00 UTC)