Ask HN: Android low latency audio in 2023 | Hacker News Reader

Ask HN: Android low latency audio in 2023

54 pointstechon42 comments

With the desire to clarify what's going on with Android low latency, see the links below from around 2018-2021, with a third link from an unknown date, however which claims devices that can go down to around 13ms round trip latency.

On March 11th of the first link, the author talks about using a MIDI device to be able to focus mainly on the output latency only, does that mean using another input device other than the screen can generally get Android output latency down to 20ms or lower!?

Any clarification gratefully received.

https://news.ycombinator.com/item?id=26388441

https://news.ycombinator.com/item?id=18199290

https://chromium.googlesource.com/external/github.com/google...

View on HN

i interviewed for a role to solve the latency issues. i brought 20 years of experience to the table. i could not solve their cute leetcode question in 2 min so i was out. i had the solution to their latency issues in my pocket. good luck to the team.

I wonder how many stories there are out there like yours. Personally I’ve heard enough to be discouraged from ever applying.

It's not some mysterious thing; you have to study for interviews.

No you don't. You just have to demonstrate your competency to do the job. Running the gauntlet is only meant to winnow the massive number of applications the FAANGs get from unqualified people. Inevitably it fails to capture the best talent because they aren't going to waste time studying for leetcode junk and subject themselves to a callous, dehumanizing screen. It isn't a normal part of a proper hiring process and it is a disservice to the industry to normalize such behavior by suggesting otherwise. It's absolutely comical when small companies think it's a good idea to replicate this and force applicants through an excessive number of interviews stretching over months.

Speaking as someone who is very good at these questions: they’re not a good predictor of dev capability. They are, however, pretty good at determining if you put several weeks of work in. Which you might think is a good proxy for determination but you’d be wrong: it’s a much better proxy for privilege.

I went through a phase where I could always get through the interview with: (i) look it up in the hashtable or (ii) look it up into the literature.

Which, considering the PMC capture, is probably the point.

this is just wishful thinking. There is shit ton of people who can write some code by copypasting stackoverflow and kicking it until "it works on my machine". leetcode helps to filter at least those.

While I appreciate your faith in LeetCode, let's not pretend it's the be-all and end-all of coding assessment. Just because someone questions its effectiveness doesn't mean they're a StackOverflow copy-paster. Maybe some of us understand there's more to software development than algorithmic puzzles. Let's not oversimplify the discussion.

do you think i have time or energy to go grind leetcode for 6 months?

I really has fun doing the Python course at Hacker Rank as I was already proficient at Python but also open to learning more. Sometimes I think some leetcode grinding would be a break from my daily grind and grinding JRPGs but when I code on my own account I have so much fun doing things that are really unique and creative and frequently I’ve gotten jobs on the strength of my side projects.

That’s the impression I got, and that’s why I haven’t applied. I don’t want to work somewhere that makes me jump through arbitrary hoops just to get in the door. I’m not a college student, I have a busy full time job and a family to take care of. I’m not going to take time away from that to read a book about how to ace a deliberately esoteric job interview.

It’s akin to asking an experienced architect to draw a blueprint instead of asking to look at their prior buildings.

If we're making all kinds of unsubstantiated claims on the Internet, I was also out. I had the solution to P=NP in my pocket. Good luck to the team.

If you were real deal you'd be interviewing for quite high level and most likely targeted hire, without any of leetcode. It seems that you were considered drone.

Large companies follow the lawnmower principle. I interned at a large company a few years ago, my code is in their public repos, had an offer from them on two prior occasions (that I did not accept), and still when I get calls from their recruiters, they want me to do coding assignments. I would point the recruiters to my code in their repos, my own public repos, papers etc., but no dice. Computer says no. On the last such call, I told them that I've done these before and that they may have them somewhere. The recruiter said they changed their systems many times over and there is no record. I was tempted to dig up my own laptop to find their old assignments, but decided to fck it. Ain't nobody got time for that.

The real deal often gets treated like a drone by potential employers. You make the mistake of believing they know how to accurately assess who is the real deal.

Plus, people who are the real deal are "coming up" all the time and they need to start somewhere.

That’s the thrill of the aqui-hire but that person is frequently out as fast as they can get out because they can’t stand the new culture. If it is Google they are going to trash all your old code and re-write it in a hurry to make it scalable but unmaintainable anyway.

they shortcut me to just a few interviews rather than the full 7 interview cycle. but i failed the typical leetcode trick question so no deal.

> i could not solve their cute leetcode question in 2 min so i was out. i had the solution to their latency issues in my pocket. good luck to the team.

Why do some Google engineers make $500k-$3m/yr?

unfortunately ads sell but low latency audio applications don't?

it’s more like they don’t understand what matters in mobile because ads is all they know

and as long as they can sell ads nobody cares

Clearly, it is because they were able to answer that lertcode question the fastest.

I mean, thats what its for right ?

Mabye mobian has this cracked already with pipewire, but hopefully you'll share your expertise over there. ;-)

The initiative seems to have been abandoned. The results they managed to achieve were nowhere near adequate for live performance. The best results they got on the best possible hardware was about 14ms, which -- as you know -- isn't adequate for real-time audio performance.

My guess, based on experience with Rasberry Pi's: to do better than that, you need all drivers on the phone to have PREEMPT_RT patches, and contention with GPUs may be a deal-killer.

You might be interested in this approach:

    https://play.google.com/store/apps/details?id=com.twoplay.pipedal

    https://rerdavies.github.io/pipedal/

PiPedal delivers sub-4ms latency (measured using loopback) without dropouts using a Raspberry PI that's accessed from a phone using Wi-Fi direct. (disclosure: I'm the author).

A few observations:

- An SMP_PREEMPT or SMP_RT Linux kernel is mandatory. Audio threads need to run with high real-time priority.

- Real-time and audio and GPUs don't seem to play well together. PiPedal delivers stable low-latency audio -- I think -- primarily because it runs headless.

- On Raspberry pi, GPUs have a dire effect on low-latency audio. Using non-GPU graphics drivers helps.

- SD card i/o has a moderately dire effect on low-latency audio. Ethernet and Wi-Fi i/o seems to have little to no effect on low-latency audio. Drive i/o to USB-connected storage devices is less of a problem with the caveat that the USB 2.0 ports share a bus, and USB 3.0 ports share a separate bus. The storage device should be on a USB 3.0 port, and the UBS audio device should be on a USB 2.0 port.

- All of this requires a Linux kernel later than ~5.15. Round about that time, the kernel ingested a significant portion of the PREEMPT_RT patches; and USB audio is essentially unusable prior to 5.10. This disqualifies a lot of ARM SOCs which still have 4.x kernels!

Contention with SD card i/o may just reflect the fact that full PREEMPT_RT patches haven't yet been propagated into mainline device drivers for that i/o path. Or that the patch set doesn't exist at all. A PREEMPT_RT kernel doesn't fix the problem.

Significantly, the Linux 5.1x audio and SMP_PREEMPT improvements post-date the Android real-time audio initiative. It might be time for Google to take another kick at the can. But in the meantime, real-time audio on Android remains borked.

the initiative was spearheaded by some internal eng who had a side interest in live music / DJing and really hated how iOS had lower latency audio and a better music production app ecosystem vs. Android. I left Google before this initiative was finally killed so no idea what happened to it

Very interesting, thank you.

As someone who plays instruments via audio interface:

I'm really confused by their definition of low-latency. For me, everything above 10ms is not low latency and I can -feel- that things get sluggish and a little less responsive.

And btw. I've achieved ~5ms latency on Windows devices 10+ years ago.

It's too bad, because as of today you cannot really use Android devices for live-music making on them.

As someone who once plays games very regularly, I get laughed at when I say that I can feel the different keyboard input latency between wired and the bluetooth stack in windows / Mac OSX.

Other people -swear- that its impossible to feel the difference, however I can't provide evidence other than 'blind testing' which I have passed. How do you know if you're feeling input latency or response latency with your devices ?

It’s funny but I think am unusually sensitive to latency in games.

I had a “gaming” laptop which had about 30 ms of latency on the screen which I measured by hooking up multiple monitors, running a clock, and photographing the screens. (I got photos where there were different numbers on different screens!)

I was playing League of Legends at the time and it always seemed like I’d get hit and there was nothing I could do about it. Once I started playing on the external monitor I started playing a lot better.

Earlier I was playing Titanfall on a Samsung TV and just getting killed despite Titanfall being forgiving to players who suck. Sure enough I put the TV in “game mode” and all of a sudden I’m “in the game”.

I’m a weeaboo so I play a lot of turn-based games, Musou games and others that are not twitchy but I find there are occasional of single-player games such as Sword Art Online: Fatal Bullet that I just can’t progress on without the TV being in game mode.

This is despite the general advice that you shouldn’t use game mode for single-player games. Now I don’t know if other people can anticipate the future better than I can and tolerate latency better (I am a schizotype) or if a lot of people play multiplayer games with high latency and suck at it and don’t know why or if a lot of people try multiplayer games and quit because of their monitor or TV.

I 100% believe you, I understand exactly what you mean.

>Other people -swear- that its impossible to feel the difference, however I can't provide evidence other than 'blind testing' which I have passed. How do you know if you're feeling input latency or response latency with your devices ?

Its not just you. Someone gave me a keychron keyboard to test out because they thought my using 'mainstream' brands that weren't lubricated or whatever was bad, and even wired the input latency on the keychron was worse than relatively cheap logitech (G613) and razer (blackwidow mini v3) keyboards on 2.4ghz. I don't know if its their USB polling or what but these well reviewed keychron keyboards were basically completely unusable to me.

RTings.com usually includes tests of latency in their keyboard reviews under 'typing experience' which is helpful if shopping.

Maybe one day if keychron cares enough to fix it I'll give them another try.

If you're playing 128th notes at 178bpm each note is 11 ms. If your BT headphones have a 30 ms latency everything you play will be off. The only BT headphones that work for music are AIAIAI headphones which require their own transmitter and receiver. They still have a 16ms latency and barely work.

General BT is useless for music.

There are measurements here for Google devices from the Nexus One to the Pixel 1. Unfortunately it doesn't include later pixel models, but the Pixel 1 is listed as 18ms

https://source.android.com/docs/core/audio/latency/measureme...

More info here [1]/[2] about device requirements.

[1] https://android-developers.googleblog.com/2021/03/an-update-...

[2] https://source.android.com/docs/compatibility/13/android-13-...

That sucks. Some musicians can feel 1ms of latency. Anything less than 10ms is unacceptable.

Just buy Apple gear. Apple did the work of getting the latency low, plus, all your musician friends will be using it.

Some work has been completed in 2018 after having this issue open for 9 (!) years: https://issuetracker.google.com/issues/36908622

5 years ago is more than half of 9 years. either way it doesn't seem important to google, because the subset of customers who would buy an android tablet/phone for low audio latency specifically is so small.

Last I heard device fragmentation made low level audio practically impossible. As the brands offering Android die maybe that will change.

I used to want it for music production but modern mac airs are both cheaper and better devices to make music on while being ultra portable.

It shouldn't be impossible on google's own devices. And once switching to recommending laptops its sort of a large open field for the most part as there's nothing about the macbook air specifically that matters.

The last edit to Devices.md is from October 2018.

The file also appears in this Github repo in the branch devicelist: https://github.com/google/oboe/blob/1c95aa99177d25bd573bf398...

Reply on news.ycombinator.com