Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

An update on Android's audio latency

android-developers.googleblog.com

Post reply on HN
Print view View original

91–100 of 171 posts

Re: An update on Android's audio latency

#91

Post by musicale »

sangnoir wrote: post #90
deadmutex wrote: post #22

Earlier quoted context omitted.

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.

Pirated copies of FL Studio on cheap windows PCs/Laptops have been the lifeline for a lot of third-world musicians for more than a decade.

I like FL studio, but.... if you're going piracy, why not add Live, Reason, Bitwig, Pro Tools, CuBase, and a stack of premium VSTs... ;-)

Reaper (free during COVID, $60 discounted license otherwise) + free plugins is pretty great though without going the unlicensed route.

Reaper also runs on Linux, natively and in WINE.

Re: An update on Android's audio latency

#92

Post by foobar33333 »

andrepd wrote: post #69
thefourthchime wrote: post #65

Earlier quoted context omitted.

What's funny is that this “open” environment of android now is nearly the opposite. With any android device openly spying on you while locking down all the open source apps you might want to install.

What does this mean? I can choose not to install google services in my phone, and use an open app store like F-Droid. Not that it counts for much in the grand scheme of things, seeing as 99% of users will never install a custom rom.

It used to be possible to dip your toes in with light modifications while still keeping everything working. Now with verified boot chains, safety net and hardware backed verification, you either have everything fully locked down or you go full Richard Stallman and have everything foss.

Re: An update on Android's audio latency

#93

Post by klodolph »

userbinator wrote: post #85

Up to now I've been referring to round-trip audio latency. Round-trip latency involves three components in the audio chain: audio input, audio processing and audio output. I read through the whole article and that's the most detail given about any testing methodology; I don't see any more description of how these numbers are being measured. My rule of thumb for computer speed measurements and efficiency has always be…

> I read through the whole article and that's the most detail given about any testing methodology; I don't see any more description of how these numbers are being measured.

The details usually aren’t that interesting. What you can do is record an input signal, pass the signal through to the output, and wire the output back in to another input.

You end up with two copies of the input signal, one delayed by the total round-trip time relative to the other. It’s fairly easy.

Re: An update on Android's audio latency

#94

Post by snvzz »

40ms is way too much. To put it in perspective, at 60Hz, that's almost 3 frames of video.

10ms would start to be useful for music, but I wouldn't call it good until it was below 2ms, which is what I run my jackd setup (which requires linux-rt) at.

I'm afraid we won't see good latency until Android moves away from Linux. The good news is that this is bound to happen, sooner or latter, as Fuchsia exists.

Re: An update on Android's audio latency

#95

Post by mhh__ »

snvzz wrote: post #94

40ms is way too much. To put it in perspective, at 60Hz, that's almost 3 frames of video. 10ms would start to be useful for music, but I wouldn't call it good until it was below 2ms, which is what I run my jackd setup (which requires linux-rt) at. I'm afraid we won't see good latency until Android moves away from Linux. The good news is that this is bound to happen, sooner or latter, as Fuchsia exists.

Is 10ms really the bounds of usefulness - especially on a phone?

Re: An update on Android's audio latency

#96

Post by userbinator »

klodolph wrote: post #93
userbinator wrote: post #85

Up to now I've been referring to round-trip audio latency. Round-trip latency involves three components in the audio chain: audio input, audio processing and audio output. I read through the whole article and that's the most detail given about any testing methodology; I don't see any more description of how these numbers are being measured. My rule of thumb for computer speed measurements and efficiency has always be…

> I read through the whole article and that's the most detail given about any testing methodology; I don't see any more description of how these numbers are being measured. The details usually aren’t that interesting. What you can do is record an input signal, pass the signal through to the output, and wire the output back in to another input. You end up with two copies of the input signal, one delayed by the total r…

It's certainly interesting because they can have a huge effect on the measurement results. For example, with HDA and I suspect other audio codec systems, what you described can be done with essentially 0 delay by configuring the codec to do the in/out mix itself. If you are measuring output from application buffers to input to application buffers, then how big they are and at what sample rates and bit depths will also affect the latency you see, etc.

Re: An update on Android's audio latency

#97

Post by bsder »

snvzz wrote: post #94

40ms is way too much. To put it in perspective, at 60Hz, that's almost 3 frames of video. 10ms would start to be useful for music, but I wouldn't call it good until it was below 2ms, which is what I run my jackd setup (which requires linux-rt) at. I'm afraid we won't see good latency until Android moves away from Linux. The good news is that this is bound to happen, sooner or latter, as Fuchsia exists.

Speed of sound is one foot per millisecond.

40ms is 40 feet. Bands play with that kind of separation all the time.

Re: An update on Android's audio latency

#98

Post by jjcon »

bsder wrote: post #97
snvzz wrote: post #94

40ms is way too much. To put it in perspective, at 60Hz, that's almost 3 frames of video. 10ms would start to be useful for music, but I wouldn't call it good until it was below 2ms, which is what I run my jackd setup (which requires linux-rt) at. I'm afraid we won't see good latency until Android moves away from Linux. The good news is that this is bound to happen, sooner or latter, as Fuchsia exists.

Speed of sound is one foot per millisecond. 40ms is 40 feet. Bands play with that kind of separation all the time.

There is a huge difference between the latency you need to feasibly pull of a live performance - and the latency you need for high quality audio production.

Why you would be considering doing that on an android though I'm not sure. Though I guess it may be a reinforcing problem, there isn't an ecosystem because the tech isn't there.

Re: An update on Android's audio latency

#99

Post by dmix »

Judgmentality wrote: post #57
dmix wrote: post #37

Earlier quoted context omitted.

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.

> There will always be a niche that wants to do music production or engineering and can't afford Apple productions. If Google cared about niches, they wouldn't have such a large graveyard of dead products - some of which were profitable and some of which were widely loved.

I was referring to App Store not Google itself...

Once the tech is capable the software will come.

Re: An update on Android's audio latency

#100

Post by Judgmentality »

im3w1l wrote: post #74
Judgmentality wrote: post #57

Earlier quoted context omitted.

> There will always be a niche that wants to do music production or engineering and can't afford Apple productions. If Google cared about niches, they wouldn't have such a large graveyard of dead products - some of which were profitable and some of which were widely loved.

Caring is not a binary. A product has a much larger ongoing cost than low latency audio, so there is more of a reason to kill it.

Features require maintenance the same as products. If this feature is enough to go after entire new categories of customers, aka musicians, this feature effectively defines a new product opportunity for Google. Also Android is already buggy as fuck, so every new feature they add actually is a big deal.

Ever since Google killed Reader I have no faith in them to ever maintain anything that isn't directly selling ads.

Post reply on HN