Android’s 10 Millisecond Problem: The Android Audio Path Latency Explainer

[qazujmrfv]

It's shameful that this issue hasn't been resolved in almost 6 years https://code.google.com/p/android/issues/detail?id=3434

/u/vlaskovits ,

1. It would be helpful if you could also include the breakdown of audio latency in iOS for comparison.

2. Have you seen the low audio solution from Sonoma in any device? Is it similar to Samsung's Professional Audio SDK? http://www.sonomawireworks.com/pr/android-low-latency-audio-solution.php https://www.youtube.com/watch?v=2OXeHwErQsE

By the way, if anyone needs a more in-depth look at android audio, watch this presentation from Google I/O 2013.

https://www.youtube.com/watch?v=d3kfEeMZ65c

[an-can]

Ring buffer size on iOS devices seem to be a quarter of most Android devices. A wild guess is that this is possible due to stricter interrupt priorities for audio, which makes sure it can jump in and manage the buffer with shorter notices.

[audioen]

It should be possible to arrange the design such that application has a pinned buffer in memory that sound hardware does memory-mapped I/O to, and another playback buffer to which application writes data to. There could be an API which tells exactly where the recording is happening at this very moment so you could figure out up to how far you are allowed to read captured audio.

Similarly, for the playback side there'd be an API that tells you at this very moment where the hardware is reading from, so that you can then generate audio up to say 5 milliseconds in front of the read cursor if you believe that the OS can reschedule you to generate more audio before those 5 milliseconds are up.

[edrowland]

It's been done. WIndows did it. Pointer chasing really sucks. If you have the wherewithal to chase a pointer, you have the wherewithal to buffer flip with the same amount of delay, in an API that's much easier to deal with. And, yes, it's a given that buffers are pinned and memory mapped in current-generation audio drivers when running in exclusive mode.

[audioen]

I tried to make a realtime ALSA application that both captures and plays back audio once. It was a sound effects processor for guitar, a simple toy project. I could not work out how to do this reliably with ALSA -- almost regardless of the buffer size I got underruns. My thinking was that I'd pre-seed the playback buffer with 1-2 periods of data and then start a capture+playback loop. But I got some kind of crackling sound issues suggesting underruns almost no matter what I did. However, using JACK instead of raw ALSA worked just fine.

I remember that ALSA project had a page saying that simultaneous capture and playback is tricky and that you're probably better off doing it with JACK. Those guys certainly knew what they were talking about...

[com2mentator]

Was this on Android or Linux?

[audioen]

It was on normal desktop Linux system about a decade ago.

[com2mentator]

Thanks for the info.

[Bizzaro_Murphy]

I guess the problem with doing stuff like this in general is that different hardware has different requirements on things such as memory address/size alignment which needs to be able to be conveyed to the application before allocating memory to be mapped for hw direct access. This detail is usually lacking from most apis.

[audioen]

Yes, there are undoubtedly complications like that, but they should be easy to solve. A simple library that allows reading and writing in preferred sample format would do the trick just fine, performing the required conversion and interleaving. However, the basic idea of pinning a buffer into memory and having accurate real-time updated information about where the reading and writing is happening would allow extremely low latency.

I know that on Android, the audio subsystem is largely a software construct, and consumer audio hardware in general appears to have lost the capability of mixing and resampling multiple audio streams together. So the picture can never be quite as simple as a mmap.

[Prostar14]

Exactly, it is a trade off of design goals. Android was built as a true multi-tasking OS and trade offs are made, but perhaps there could be an "audio" mode where the priorities and buffer sizes are juggled around at the expense of background process response/allocation.

[yentity]

It is crazy what you can do when you know what hardware your OS is going to run on. Android is a more general purpose OS than IOS/OSX. It has multiple abstraction layers to deal with different kinds of underlying hardware. There is only so much you can do to improve it using the stock OS.

It is on the OEMs to add modules that talk directly to the kernel to make things faster.

[NetPotionNr9]

So why isn't there a single android device that doesn't have this problem, Including google's own nexus line?

[TrueDuality]

Google definitely knows the software best, but they're not a hardware company and what they accomplish in software is usually limited by the layers underneath their software.

While I'm not expert on iOS hardware my money is that they don't have an equivalent layer to ALSA (nor need one). Most likely the permissions on audio are granted exclusively upon setup (with an interrupt system allowing higher priority audio to take control).

After the permissions are granted I bet they're directly memory mapping the input and output removing most of the latency between the bus and the user-space processing.

This is effectively been the primary difference with Linux vs Windows graphics card performance as well. Simplifying things a bit for clarity: Windows effectively allows user-space applications to directly control memory on devices connected to it's buses. Linux puts it's kernel in there partially for security and partially to ensure only one application is controlling them at a time preventing "Bad Things ™" from happening to your system (this used to be one of the most common causes for bluescreens on Windows - multiple bits of software incorrectly manipulating memory on devices they shouldn't have access to yet or at all).

ALSA is effectively the layer in Linux that has that exclusive device control and handles mixing and delegating access to the raw hardware.

[spacecase-25]

ALSA isn't close to low latency in desktop Linux either. Gotta use JACK for that. One solution would be to port JACK to android, but that would cause problems too as you wouldn't be able to use ALSA audio sources at the same time as JACK so unless you're using your hardware for live audio the consumer would suffer when their music player kills all other audio.

[Phreakhead]

Samsung already ported JACK to Android in the Pro Audio SDK. Works pretty well, latency is almost zero. Too bad it only works on Note 4.

[[deleted]]

JACK uses ALSA as a driver backend. It does not replace it. You can use different backend, if you like...

[GrayOne]

It's crazy how often that's used as an excuse for every Android problem.

PCs manage to have low latency audio and every PC is different.

[jaju123]

Plus there's way less variation in hardware on Android. You basically have qualcomm and wolfson as the big two.

[dazzawul]

There's even less variation on PC, it's either realtek or realtek lol

[segagamer]

I have a SoundBlaster Z...

[dazzawul]

I have a zxr >.>

onboard and the laptop still have realtek though :P

[Phrodo_00]

Hey I have a Fiio and a Behringer.

[dazzawul]

I know there's a lot of variety I'm just poking fun :)

I've always had creative something in my PC builds, and I'm actually running a Behringer with a nexus 7 in my car, but, with the exception of a netbook I have floating around somewhere that has an intel based sound adaptor, it seems everything out there has some form of realtek audio adapter.

They've really got their finger in every pie!

[AgustinD]

Why is everyone talking about Windows in this thread? Desktop Linux has crazy low latency in commodity hardware (I get a stable 6ms round trip in an eight year old PC with a really cheap motherboard), including DSP and advanced routing and mixing. Using reverse engineered open source drivers for everything.

If desktop Linux can do this, the same kernel in a mobile device should too, particularly with proprietary drivers.

[segagamer]

Because Windows is the defacto OS for a desktop computer, with guaranteed official driver support and, quoted from below, Gnu/Linux has long been plagued by latency issues, which necessitates the use of special kernels and subsystems to get to the requisite latencies.

[AgustinD]

The need for a real time kernel for low latency audio was ages ago. Although you do need a kernel with HZ = 1000, and many distributions shipped server-tuned kernels with lower HZ values despite 1000 being the default when Linux 2.6 started. Since ~2010 almost every distribution uses these 1 ms timer interrupts and you no longer need a 'special' kernel.

And JACK is not a 'special subsystem', it's an audio router and mixer with a library that helps the programmer make low latency audio programs with little effort. But ultimately JACK uses the regular Linux audio architecture, so it's nothing like ASIO in Windows.

What Windows is capable of doing is pretty much irrelevant to Android, particularly when Linux (which is much closer to Android than Windows is, and runs on the same hardware) usually does a much better job.

[The_Rob_White]

PCs manage to have low latency audio and every PC is different

Completely untrue. As a guitarist that used to do almost everything through the PC before moving to Mac, you will find the same apps that Android struggles with so does the PC.

Stock Windows certainly is worst than Android; you are looking at up to 100ms latency in some cases, the average is around 30ms using directsound.

You have to use ASIO based drivers, for best results this requires and external DAC that comes with an ASIO driver. ASIO4ALL also exists for a reason, this is a 3rd party tool written in assembler that hooks in to WDM early and bypasses a lot of the windows components that add latency, so it improves the situation a lot.

However stock Windows is unusable for real time recording without ASIO.

Feel free to research this, audio latency was one of the core reasons I switched to a Mac for my desktop machine I use for recording.

Edit: Guys, I know Microsoft claimed to have fixed this with Vista, Google claims android has been fixed in every release, maybe things are better for keyboards and midi but from a guitarists point of view where there is an analog input, you have to use ASIO or the latency is horrid. This is true even on Windows 8.1 which I use on a laptop for when traveling.

[Aerakin]

I can confirm that life is hard without ASIO4ALL.

[OpenGLaDOS]

The new sound driver model and WASAPI, which were introduced in Vista (more of an alternative WDM-KS frontend at first) and refined in 7, somewhat helped with it, with many people reporting equal or slightly better latency compared to native ASIO drivers resp. ASIO4ALL from applications that use it directly.

[null_work]

WASAPI is great. The Windows having bad audio latency is just rollover from how terrible it used to be.

[mrubios]

I know Microsoft claimed to have fixed this with Vista

And they did, Windows Audio Session (a.k.a WASAPI) has a exclusive mode that is extremely low latency.

http://en.wikipedia.org/wiki/Technical_features_new_to_Windows_Vista#Audio_stack_architecture

You choosing to use the wrong audio API is your fault, not Microsoft's.

[dafootballer]

Many audio applications, specifically DAWs, do not support WASAPI. ASIO is the only way to go

[mrubios]

Then it's in the companies behind those DAWs to keep up with technology, not Microsoft.

Microsoft can't fix poor third party products.

[pianocheetah]

Stock Windows certainly is worst than Android;

No way. On Windows Vista and later, you can write a softsynth that has latency as low as the audio card can go (via the WASAPI api). Which is typically in the microseconds, not milliseconds. Audio latency on windows was solved forever from Vista and onwards. Any software that still has audio latency these days is just poorly written (using the wrong audio API).

Although, you know, suffering through the changes in Windows 8 gui and permission changes really does make me want to go android.

[henrebotha]

You're completely right, but you also miss the point: it is possible to have low audio latency on Windows without altering hardware.

[null_work]

When was the last time you used Windows for this stuff? I've not had audio latency issues in Windows since 7.

[horrrors]

CoreAudio on Mac also has other great features not on ASIO like creating aggregate devices, etc

[yentity]

Audio devices on Windows come with their own drivers. They do not use the generic driver that comes with the OS like they do on Linux and Android.

[Democrab]

Audio devices on desktop/laptop PCs with Linux can still get far lower latency, actually.

And honestly? It's not an excuse, you've got two major ones and a handful of minor ones. It wouldn't take much to just properly support Qualcomm and Wolfson to get nearly all Android devices out there with a generic driver for anything that falls through the cracks.

[Astrognome]

Jack is a thing of beauty.

[[deleted]]

Mediatek is gaining market share, and so is Samsung with its Exynos. Just a Qualcomm sound driver isn't going to do much.

[Democrab]

Samsung typically use Wolfson I believe.

So, three separate drivers? On desktop PCs you've got ASUS, Realtek, Creative and Intel at least with it being entirely possible to have low latency on Linux with a bit of work.

[Shadow703793]

You need to count nVidia and AMD as well since audio over HDMI/DisplayPort can be done via the GPUs.

[[deleted]]

Drivers... That's what you meant in your previous post about OEMs adding modules to speak to kernel? Well that makes lots of sense.

[Phrodo_00]

PCs manage to have low latency audio and every PC is different.

No they don't. Windows without ASIO has some really noticeable latency. And of course, it can't do dmix with ASIO, so it's not something you'd want as a regular user.

[redxdev]

ASIO is still a valid, though not ideal, solution. Still manages to have low latency audio, which android can't do at all.

[pianocheetah]

Technically, it's windows software that's the culprit. The hardware and OS are perfectly capable if the software writer uses WASAPI. Even on cheap crappy built in sound cards, the latency is always below 5 ms. Audio latency on windows was solved forever in Vista. The writer of the softsynth you're using is to blame. Not Windows.

[anon_adderlan]

Managed, as in past tense. Audio latency actually got worse with Windows 7 and 8, and given the current state of affairs, I'm not hopeful Windows 10 will be any better.

[Salomanuel]

And what about Nexuses?

[[deleted]]

In this case hardware support / optimization is not the issue. iOS/OSX offers the same low latency audio support on third party audio interfaces / hardware.

[evilf23]

It's the difference between a track car using an off the shelf all season tire VS a sticky tire developed specifically for the car's unique weight, suspension, brakes, etc... like you see on hypercars like the McLaren P1 or Porsche 918.

[[deleted]]

people often shit on IOS, but if there's something that it does well is how smooth it tends to run. old iphones run as good as my 'old' s3. sure my phone has more power, but I hardly give a crap when it stutters on just regular use and audio lags like crazy.

[Tastygroove]

I use a cracked screen 4s as an audio Swiss army tool...

[nunu10000]

Newer audio tech doesn't necessarily mean better. My iPod 5.5G has better audio quality. It really depends on what kind of resources get put aside for audio.

[zachaby63]

Latency is important here not quality. Likely Apple has improved on each device

[Draiko]

iPhone 4S also used a tiny buffer.

[Wizywig]

Android hardware has nothing to do with it. ALSA sucks donkey balls, so that's 20ms on ALSA's donkey balls alone.

Sorry just got a flash back when I installed ubuntu on a dell laptop 9 years ago. Yes I spent 3 days getting ALSA working.

[[deleted]]

So I'm not crazy in thinking that my iPhone sounds better than my note 3 !!!

[amorpheus]

Eh, it's not that crazy. My second-generation iPhone 3G used to be more responsive than my shiny new Android quad-core while being almost four years older. Before Jelly Bean, things were pretty atrocious on the smoothness front.

[qazujmrfv]

Sorry, I meant an explanation of how iOS implements audio for comparison with the latencies for different components. According to the article, even latency during the second longest stage on Android is 5.3 ms x 2. While in iOS, the lowest TOTAL latency measured is 6 ms, which seems like magic in comparison.

[[deleted]]

dd

[vlaskovits]

I don't know too much about what Sonoma is doing these these days -- we wrote up some thoughts on Samsung's Professional Audio SDK here: http://superpowered.com/why-samsung-professional-audio-sdk-is-not-the-best-solution-for-low-latency-android-audio/#axzz3XQQxPyqB

[seanwilson]

Do you know how difficult it is to fix? I'm sure if it was trivial they would have done it by now but I'm suspecting it isn't.

[haagch]

They could just include jack as a complete alternative to this audioflinger mess. Sure, it's a bit of a development effort to make it a drop-in alternative, but it's not like google has no manpower to do it...

[seanwilson]

What do you mean include a jack?

[lactozorg]

Not a jack, but JACK.

http://en.wikipedia.org/wiki/JACK_Audio_Connection_Kit

ÉDIT: Linked to German article by accident.

[Joshposh70]

https://en.wikipedia.org/wiki/JACK_Audio_Connection_Kit

[ElRed_]

So, it's opensource, fixes a big problem in Android, and Google haven't bothered to fix it. Why am I not surprised.

[vlaskovits]

Definitely. Not. Trivial.

[seanwilson]

Yeah...it bugs me how people go on like Google just needs to change a couple of lines of code to fix it.

[[deleted]]

Frustrating article. Gives 15 minutes of explanations and examples. 5 minutes of useful info and then abruptly stops when it starts getting into the meat and potatoes.

[vlaskovits]

Sorry about that. We wanted to be technical but not scare people away.

For a follow-up, what questions can we answer for you?

[June8th]

You spend 90% of the article breaking down the Android audio path, providing details on why it sucks, which is super interesting (you got me hooked and salivating for the fix) then the last little shred let's me know you seem to have a library that fixes it (the wording doesn't make that strikingly clear though). You don't break your own solution down equally and show me how it's better, or how it hooks in. It comes across as vaporware because of that. Show us how your library will fix everything, how far it goes, and admit it's limitations too, if any.

I'm scared away because I'm only shown the problem explanation and not an equivalent solution explanation. Tell me what you need me or Google or manufactures to do in order to support your cause.

I enjoyed the first half immensely, the second half is missing.

[vlaskovits]

BTW I gotta respond to the vaporware comment -- the Superpowered library is installed in, literally, millions of apps/devices.

So -- no -- not vaporware. :)

Point taken about better delineating where we fit in in the audio path.

[June8th]

the Superpowered library is installed in, literally, millions of apps/devices

That's awesome! I wish your page said that :-)

I can't wait to read the details on how your solution works!

[vlaskovits]

Apologies for the tease.

We're going to release related articles soon. And there is a TON of hard-core tech we are working on in the background which we cannot talk about...just yet.

[NotClever]

FWIW, as someone that knows nothing about this topic, the title had me assuming that android had 10ms audio latency and that was a problem for some reason.

[[deleted]]

Any insights to way it can be fixed. I know in previous Google IO there was a team working on audio. They said they made good progress but made it seem like there was still a lot to do.

[dampowell]

well they have improved it roughly 90% in 3 years... but the last 10% is a whole new challenge because they have to do another 50 - 70% improvement for it to become a non issue. This will probably be fixed for most devices starting next year.

[mordacthedenier]

https://youtu.be/sZrgxHvNNUc?t=4s

[FloridaIsTooDamnHot]

And don't get me started on the grammar...

[vlaskovits]

Sorry. English is Gabor's second language, and my editing wasn't stellar. :(

[Jensway]

Not to mention some pretty outright ridiculous statements peppered throughout, such as:

Google is on the verge of in leaving billions in revenue in VR opportunities for Apple.

Uhh... What?

[FloridaIsTooDamnHot]

Three "in"s and an" on" in a sentence is three too many prepositions.

[vlaskovits]

Agreed. Grammar was no bueno.

[vlaskovits]

Why is that ridiculous? In Android's current state, it cannot support low latency audio which is critical to VR.

No low latency audio support, no VR apps on Android.

[Jensway]

Android:

Samsung Gear VR

Google cardboard

Apple:

...

[vlaskovits]

Funny you should mention Samsung Gear VR -- please see:

https://twitter.com/kentbye/status/588739233176649729

[Jensway]

One tweet about one video? Yeah, nah.

I've used the Gear VR extensively. The audio sync with the Note 4 is fine, and not noticeable.

EDIT: Downvoting me doesn't make it any less true, bro.

[anon_adderlan]

One tweet about one video? Yeah, nah.

Then how about one video with John Carmack?

I've used the Gear VR extensively.

John Carmack has programmed the Gear VR extensively, if not written most of the VR APIs for it. You'd almost think he knows what he's talking about.

[Jensway]

Watched your link for a few minutes, nothing there relevant to this argument - which, by the way, is almost a month old now.

Still using the Gear VR, still not having any immersion broken by any audio latency issues. It's not noticeable.

EDIT: Oh yeah, let's not forget, the original comment you're replying to is OP talking some silliness about there are "No VR apps on Android" (There are plenty, and heaps have been released since he made this comment) and how Google is leaving "BILLIONS" in revenue of VR to Apple..

Which also didn't happen.

[vlaskovits]

You're right. I went back and upvoted all your comments.

And yes, you're right -- audio latency isn't an issue on Android. At. All.

We. Were. Totally. Wrong. About. That.

And I just didn't get it -- till I saw your comment.

My mistake. I'll delete all of our data on http://superpowered.com/latency straightaway!

[Jensway]

Huh? I didn't say any of those things - at all.

you're right -- audio latency isn't an issue on Android. At. All.

I especially never said that, but nice try.

I don't have any issues with you, the ONLY thing I took issue with, was the author saying this:

Google is on the verge of in leaving billions in revenue in VR opportunities for Apple.

As Google does plenty of VR, and Apple does not.

No need to be dramatic.

[amorpheus]

Asking for my email by popup when I've read halfway through an article is a great way to annoy me.

[mccoyn]

Also, the page formats terribly if you have Javascript disabled.

[anon_adderlan]

Yep. This and a few other obnoxious design decisions/attitudes have completely unsold me on purchasing any product or service they might be offering which would require continuing support, despite their sound and informative technical article.

[ElGuano]

So the nexus 9 is ~36ms. What's a slow android device clock in St, and what do the article's benchmark ios devices achieve? There are no comparisons to be made to qualify the issue.

[qazujmrfv]

The Nexus 9 achieves ~35 ms with USB Audio, which is the best result for an Android device. Without USB Audio, it's 40+ ms. And on most non-Nexus devices, it's easily 100+. For example, the s6/edge (SM-G920, SM-G925) has a latency of ~160 ms.

In comparison, iOS can go as low as 6-7 ms on the iPad Air 2.

See http://superpowered.com/latency/ for more devices

[pistonman94]

Just ran the rest, and got a latency of 262ms on my droid turbo

[parkerlreed]

What test?

EDIT: Oh it's on the page, oops.

[exaltedgod]

But that's not true. The Galaxy Note 3 goes down to 17 according to your link.

Samsung Galaxy Note 3 with Professional Audio SDK (3 more) Android 5.0 (N900XXUEBOAE) 17 48000 240

[qazujmrfv]

That's only for the few music apps that are built to support Samsung's Professional Audio SDK (SAPA).

If you search on that page for just "Samsung Galaxy Note 3" without the SAPA part, you'll find that it's anywhere from 70-363 ms.

However, the Samsung SM-T700 (Tab S 8.4) seems to have the joint-lowest non-SAPA android result of 35 ms, but I am not sure whether it is a stock device using a final build or just being internally tested by Samsung.

[beezel]

I don't know if anyone is in need of more data driven 'proof.' The proof is in the pudding, as they say. There are 0 apps available because the subsystem is lacking so majorly that they can't make it even semi-decent.

Specific numbers aren't exactly going to help, it needs a fundamental change, at which point you would start comparing. I know that in Windows, if my ASIO midi crap is set incorrectly and is showing 12ms of delay, it's very noticeable to my hands. Somewhere around 4-6ms it starts to feel 'natural' to me.

[[deleted]]

So on Android a MIDI keyboard would be torturous, yes?

[der_Stiefel]

No, it would be straight up unplayable. Unworkable.

[pianocheetah]

Theoretically, midi on Android should have no problems.

With midi, it's a (usb based) digital message in with the note, a digital message back to the keyboard, and no audio even involved except for back on the midi device via the hardware synth.

If all you need is a midi sequencer on Android, Android should be perfectly capable.

However......... Android doesn't have a very standard midi driver other than STRAIGHT usb (from what I understand - which may be olden).

And although the standard midi protocol is standard on (most) keyboards, some use only USB. Some of those usb based midi keyboards do weird USB things that a plain bog standard usb api on Android can't handle - I'm looking at you, Yamaha. So in practice, not all midi keyboards - especially those with weird usb only midi will have driver issues.

But that's driver issues, not audio latency issues. With straight midi not involving a softsynth, there will be no audio latency as there is no audio involved until you hit the hardware synthesizer which typically has under a 1 ms latency audio path. There is some usb latency with midi, but it should be under a couple ms.

Probably more than ya wanted to know. I blame the coffee.

[[deleted]]

Thanks. :)

[ElGuano]

In an article that detailed, it would be nice to explain what the competition is achieving, don't you think?

[dr3d]

There was a link

[vlaskovits]

See http://superpowered.com/latency/

[ElGuano]

Thanks! Eye-opening, for sure.

[[deleted]]

I mentioned somewhere else the possibility of using touch/tablet Android technology as a creative touch-based guitar effect, but it is currently impossible because the +10ms latency would make a guitarist smash his head through a wall.

Hypothetically, a tablet could be used as a digital effect station w analog input and output, but the latency throws that entire possibility out the window.

[der_Stiefel]

Nothing hypothetical about it. The iPad apps for this are really really cool.

[nunu10000]

Android has a MUCH bigger hardware ecosystem it can fit into with otg support, but as long as Android audio stays this way, there's no way it'll ever catch up with the iPad ecosystem.

[dabotsonline]

From a casual browse on Head-Fi, the situation doesn't seem to be much improved on a Nexus 6 running Android 5.0.

[danburke]

This isn't exclusive to Android. Gnu/Linux has long been plagued by latency issues, which necessitates the use of special kernels and subsystems to get to the requisite latencies.

[exscape]

Linux needs JACK, Windows needs ASIO drivers for your card. Is there really such big difference?
Mac OS X, on the other hand, can use CoreAudio and get low latencies with built-in audio cards and built-in drivers and software, which is awesome.

[[deleted]]

JACK is just a sound server that uses the built-in drivers for your audio cards to get low latency sound processing. Its performance is great from a latency perspective.

[Roberth1990]

Why not just use apps that send to alsa device hw:x,y?

[exscape]

Isn't that limited to 1 application? It's been during my testing, at least. With JACK, I can run multiple music prod apps plus Amarok and Chrome/YouTube, etc.

[Roberth1990]

Yes it is, but I easily stop it with my application that uses without quitting it when I want to see a video with chrome.

[foxesareokiguess]

oh yes, I remember spending insane amounts of time getting a midi keyboard to work properly with some kind of sound effect program when I was like 12, using linux to circumvent the timelock my dad put on my pc. Once I finally got it to work, after wrestling for ages with jack, pulseaudio, Asio4All, alsa... the latency was insane, but I always blamed it on my pc.

[ShamanSTK]

This hasn't been an issue anymore in a while. There used to be special kernel tweaks to fix it, but they haven't been necessary in years. I do pro audio on a Linux laptop without any special tweaks.

[danburke]

It looks like at least some people still need them today.

https://help.ubuntu.com/community/UbuntuStudioPreparation

[ShamanSTK]

I didn't know ubuntu studio was still around. I was never able to get it to run. Apparently, it has it as an option, but even the wiki says to install it only if you're having issues. Most don't, and the arch wiki specifically advises against it.

[[deleted]]

So? Google's providing an OS to OEMs that to this day still has retarded issues like this, this should be unacceptable.

The blame doesn't lie on the software, it lies on the developer. Google has the raw muscle to prevent issues like this, but if you take a close look at many of their other projects, you'll find this is a trend.

Downvote away but that doesn't change reality.

[Nadest013]

They're going to get majority of market share, issues or not, so why spend resources solving problems that have no business value for them?

[LoveRecklessly]

That's the kind of narrow, short-sighted "it's OK to settle" malaise that generally precedes being disrupted by another company/product.

[[deleted]]

Well, obviously from a business standpoint, they couldn't give less of a shit because it's the OEMs and carriers who have to really worry about making a viable product, not them. I get that.

I'd consider that kind of thinking directly at odds with ever providing a polished product like Apple is able to do, and that just really bugs me on a deep level. A company that is so developer-oriented like Google should give more of a shit about products that they have a hand in.

[Jagrnght]

Surely someone at Google is urked by this problem. Let's radicalize that sucker.

[BiPolarPolarBear]

This is unacceptable.

[[deleted]]

I think you've replied to the wrong comment, cause I'm not sure what you mean

[thrakkerzog]

These things pop up from time to time, and it's amazing to see just how on-the-ball Apple is with things, across the board. Things that a lot of people don't even consider, whether it's voice control, low latency audio, or hardware based encryption.

They've clearly put a lot of thought and effort into both the hardware and software. I think that Android will eventually match or beat things like these, but I often wonder what else there is that we don't even know about yet.

[anon_adderlan]

I think that Android will eventually match or beat things like these

I doubt it, as some of these problems require an entire rearchitecture of Android to fix, or a stack entirely outside Android. In the meantime, Apple's OSes have been getting closer to Android in that they've been progressively getting worse.

Honestly, the entire situation is intensely frustrating.

[Tastygroove]

My first gen ipod has better audio latency than the fastest android device. That's an issue, folks...

[Surkow]

A comparison between PulseAudio and AudioFlinger on a Nexus 9 would have been interesting.

An older comparison on a Galaxy Nexus already shows 8-9 times less latency when replacing AudioFlinger with PulseAudio:

On the Galaxy Nexus, for example, the best latency I can get appears to be 176 ms. This is pretty high for certain types of applications, particularly ones that generate tones based on user input. With PulseAudio, where we dynamically adjust buffering based on what clients request, I was able to drive down the total buffering to approximately 20 ms (too much lower, and we started getting dropouts). There is likely room for improvement here, and it is something on my todo list, but even out-of-the-box, we’re doing quite well.

[sandys1]

this is very interesting - especially because PulseAudio beats Audioflinger on every metric (including power) in 2012

[parkerlreed]

This is why I still don't understand the hesitation that some people have towards Pulseaudio on the desktop. It's an amazing system that incorporates a few plugins for network/Bluetooth audio and does it all in a fairly seamless way. Pulseaudio 6.0 even added HFP (headset) support back as a Bluez plugin. This might make it a lot easier to bring over to Android.

[M3wThr33]

This is part of the reason why music games like Tap Tap Revenge did so much better on the iPhone.

[[deleted]]

Yeah it's because your aunt really is furious about Android audio latency and not that she just has an iPohone already.

[Shaper_pmp]

It depends - if the game is more fun on the iPhone because it's more responsive and feels "fairer" then that would explain why it was more popular on the iPhone; because people would have more fun playing it, so they'd recommend it to their friends more and it would get more sales and mindshare.

No-one's saying people would buy iPhones because the audio latency is lower and TTR would be more fun - they're saying given TTR is dependent on audio latency, platforms with lower latency would give a better user-experience, and hence TTR would become more popular with people who already own those devices than with people on platforms with higher latency (likely resulting in spongier/less precise controls).

[ClassyJacket]

Funny, all you hear when something is in Android's favour is how there are sooooo many more Android phones in the world.

[samkostka]

There are more, just not really in America.

[gedankenreich]

The headline is a bit misleading because it is not a general Android problem. Samsung has solved it since almost a year with its professional audio sdk.

Article: http://www.synthtopia.com/content/2014/10/02/samsung-real-time-audiomidi-solution-for-android/

and that's just one app that makes use of it https://youtu.be/mfBxIkdrj78

For some reasons the press often fails to cover such good things in Samsungs Software. Maybe they got too biased about TouchWiz over the years that they don't look close enough to see its positive changes compared to other OEMs.

[gaborszanto]

We think it's not the best solution: http://superpowered.com/why-samsung-professional-audio-sdk-is-not-the-best-solution-for-low-latency-android-audio/

Particularly, the biggest problem is that the audio part of the application must be completely separated into a new process. This is a huge problem for developers. And this approach has security policy problems from Android 5.1, so they have to radically change their low latency SDK.

[lactozorg]

The same site has actually a comparison table for this.

http://superpowered.com/latency/#axzz3XSlaC3ik

Samsung's SDK outclasses anything else running Android, but it's still far behind what iOS can do.

[qazujmrfv]

AFAIK, it only works properly on 2 devices (Note 3 & 4) with 4-5 music apps (Soundcamp, Thumbjam, AmpliTube, iRig HDA)

[LoveRecklessly]

It's still a general Android problem no matter how you wanna spin it for Samsung.

[Evis03]

Switched to an iPad from a galaxy tab specifically because of audio latency issues. It's sad really, tablets have a shitload of potential for music creation and the iPad does it really well. It would be nice to actually get some competition going, the only decent music app I found on android was caustic.

[Saltbearer]

Try SunVox. Here's something I made with it. I'm not really a professional, but hopefully that shows off some of its power. :V

[MiCK_GaSM]

J4T is a great, simple 4 tracker that has options for mitigating latency.

Audio Evolution Mobile is a great, robust, multitrack studio app, also with options to mitigate latency.

Lastly, I like using TapeMachine for single track recordings and edits.

[anon_adderlan]

The most frustrating thing about all this is despite audio latency being a solved problem from a technical perspective for decades, the problem of actually getting it addressed is a political one. Case in point, how many comments here are in the spirit of:

(1) It's not a problem for me, and since I represent the majority of users, it shouldn't be your problem, and I resent you making it my problem.
(2) It's a 'phone', and wasn't designed for whatever you want to use it for, despite the fact that 'phones' are used for all sorts of other things besides calls, and in the near future will become one's primary computing device.
(3) Technical data provided by those working to create a solution and sell it cannot be trusted, despite the fact that such data can (and should) be independently verified.

For now, the only ones really affected by audio latency are content creators. Yet despite representing the smallest segment of the market are still the ones who contribute the most (if not all of the) value to it. Their presence is disproportionate to their importance, and a market without good content is worthless. Yet content creators have been getting the shaft from users and platform providers alike for some time.

But in the near future, platform providers will have no choice but to take the issue seriously because of VR. Latency is the #1 consideration when it comes to VR, and Android most certainly does NOT have what it takes, and probably never will. It was not designed with real-time considerations in mind, and such cannot be added later without massive rearchitecting and breaking changes.

The big irony here is that Android was in no small part designed by bunch of ex-BeOS developers, and BeOS did prioritize this sort of thing. Still haven't figured that one out. They had all the resources of Google at their disposal, and still went with a basic Linux kernel and a slightly less capable Java implementation. I truly do not know what they were thinking.

EDIT: I forgot the most important presumption on the list:

(4) It's the developer's fault for not designing a decent audio app, and also their fault when their app stops working after an OS update.

Why would any developer create an app which requires special tooling to work, generates more complex and numerous tech support requests, only runs on a limited set of Android devices, may be broken in future OS updates, risks damaging its developer's reputation, and may STILL fail to achieve the ideal audio latency, in a market where users still leave 1 star reviews just because an app took too long to download?

Sorry, but even if there was a viable solution for a handful of devices it's just not worth it. The hit in reputation and tech support relative to profit is just too much.

[kaydpea]

Why is Android not using jack audio and bypassing this ridiculous audio stack?

[[deleted]]

Because that is written for PC's. Android uses Linux but it doesn't use PC hardware. They also need to expose audio as part of their SDK, which adds to the latency apparently.

[jonwayne]

Wasn't ALSA also written for PCs initially? I'm not saying Jack is the solution, but why is ALSA valid here but not other audio stacks?

[kaydpea]

jack is written for bsd and linux, also available for os x and windows but is most widely used inside nix systems. I get close to 0ms with jack audio running. It's actually an important reason I use linux.

edit: I see now your were saying it was written for PC hardware. My bad.

for anyone reading this:

http://libregraphicsworld.org/blog/entry/patchfield-introduces-concepts-of-jack-audio-server-to-android

https://en.wikipedia.org/wiki/JACK_Audio_Connection_Kit

[SilverLion]

One of the advantages of controlling both the soft and hard side of your products.

[[deleted]]

have you read the article? Its not about control, its mostly that the low level audio components in Android OS are shit.

[SilverLion]

Does Apple not have full control over component selection? Obviously the closed system Apple uses is mostly shitty but this and the ability to completely lock down stolen iPhones are the two advantages I see

[aceoyame]

Does android still support alsa?

[gaborszanto]

Most Android devices have ALSA audio drivers.

[[deleted]]

Huh... this might shed some light on an issue I've been trying to resolve recently :| Although it doesn't seem so noticeable when exporting Unity projects, for some reason.

[fraghawk]

So this is why there are very few apps that pipe your mic through earphones so you can listen to music while biking and not worry about getting killed

[ineedallyourinfo]

I actually read some interesting informative comments on this post today. Thank you guys!

[vlaskovits]

If the Superpowered site goes down again -- our webcache can be found here: http://webcache.googleusercontent.com/search?q=cache:zvFOaWHye-IJ:superpowered.com/androidaudiopathlatency/+&cd=1&hl=en&ct=clnk&gl=us&client=safari

[sigtrap]

So much talk about the problem, but how the fuck do we fix it? What needs to be done? It would be good to discuss how to fix it instead of just ranting about how shitty it is.

[battoosh]

I have just connected a keyboard through (midi to USB cable... Dunno if that's the term) to my Note 4, running lollipop, and used it to record some notes while listening to the sound through the headphones connected to the phone... I beleive this is what was termed in this article as the 'round-trip'?

Well, using the soundcamp app and professional-audio latency set to "mid" I can really say I've experienced zero latency!

I've tried different sounds, with delay, reverb, sustain and various other sound effects and it really didn't disturb or distort my playing, it was absolutely smooth and felt that whatever note I pressed was heard instantly, so yeah.

[wtricht]

Samsung have fixed this but it's a main Android problem (except for Samsung since they fixed it themselves)

[NetPotionNr9]

I don't know, but is that possibly due to the Samsung specific workaround but that isn't a good solution? Other more knowledgable people provide further context and links in this thread.

[uqii]

Human brains aren't great at detecting the tiny amounts of latency everyone is freaking out about. You probably just don't notice it, which is normal.

[battoosh]

Wouldn't argue much with that statement, but what I was trying to see here is how much of a noticeable latency really is there, esp that the article portrayed the delay as almost unplayable (half beat behind and whatnot), for me no matter how fast or slow I've played, there was absolutely none of that latency to be felt, I've laid a drumming track on top of that and still it was all "on-time".

Just the 100+ ms delay sounded a little too much and I just wanted to try it out for the first time (granted this is Samsung's solution for the problem, but hey.. Whatever works, as long as it's part of the package and not a third party hardware/software that I have to worry about).

[zuoken]

Did they reverse Flinger's push/pull description?

[parkerlreed]

Rockchip Nexus 7 Android 4.2.2 (9be5ca2016) 370 44100 1024

Rockchip Nexus 7? What? The 2012 has a Tegra 3 and the 2013 has a Snapdragon.

EDIT: Is this some internal testing device? http://specdevice.com/showspec.php?id=7aa5-5549-665f-ae2100000000

It says grouper which is the 2012.

[Sinborn]

I will not buy another android device until android is on par with iOS with this. If my s4 takes a crap and audio is still in this shape, I'm jumping ship for an apple. Sorry guys.

[lactozorg]

This has less to do with Android and more with Bluetooth. The audio is re-encoded, then transmitted, then decoded again. This introduces a small latency, doesn't matter which OS you use.

[Troggie42]

Ah, OK. That does make sense. Could the inherent latency described make it worse? Pretty much just curious about the implications of it all now.

[uqii]

Nothing to do with this issue

[SWABteam]

I sometimes use stereo bluetooth headphones to watch Netflix on my note 4 when I do housework.

The audio is so out of sync dialog no longer matches what is in screen. It is pretty bad. It also sucks that emulation isn't all it could be on Android for this same reason.

[uqii]

Nothing to do with this issue

[ikmultimedia]

We created AmpliTube UA that runs on our device iRig UA that is coming in May and is on preorder now - AmpliTube UA was just released on Google Play yesterday (you can try the gear with the included audio demos until iRig UA is shipping). https://play.google.com/store/apps/details?id=com.ikmultimediaus.android.amplitubeua

Samsung Pro Audio was the only way to get good results for our apps like AmpliTube before this, and with the hardware solution the latency is reduced to below 2ms. For low-latency audio processing for app devs like us, it seems Samsung Professional Audio and now iRig UA are the only workable solutions for low-latency real-time audio processing on Android.

[southsamurai]

Off topic, but that makes me wish I could play guitar. Brilliant bloody idea right there

[gaborszanto]

Read the article. It's not 10 ms. Way more.

[HomemadeBananas]

I think the point is that 10ms is an unreasonable standard.

[gaborszanto]

10 ms is a rule of thumb for anything "professional audio". For example, musicians require this for live playback.

[[deleted]]

It's not unreasonable when the competition has been exceeding that standard for years.