Re: [Jack-Devel] Fwd: [andraudio] Google I/O: High performance audio talk

PrevNext  Index
DateWed, 22 May 2013 14:51:47 +1000
From Patrick Shirkey <[hidden] at boosthardware dot com>
Tojack-devel devel <[hidden] at lists dot jackaudio dot org>
Cc[hidden] at android dot com, [hidden] at gmail dot com
In-Reply-ToPatrick Shirkey Re: [Jack-Devel] Fwd: [andraudio] Google I/O: High performance audio talk
Follow-UpFelix Homann Re: [Jack-Devel] Fwd: [andraudio] Google I/O: High performance audio talk
Follow-UpFelix Homann Re: [Jack-Devel] Fwd: [andraudio] Google I/O: High performance audio talk
On Sun, May 19, 2013 8:28 pm, Patrick Shirkey wrote:
>
> On Sun, May 19, 2013 8:06 pm, Stéphane Letz wrote:
>>
>>
>> Début du message réexpédié :
>>
>>> De : "Patrick Shirkey" <[hidden]>
>>> Objet : Rép : [andraudio] Google I/O: High performance audio talk
>>> Date : 19 mai 2013 11:16:02 UTC+02:00
>>> À : "A discussion list for Android audio developers"
>>> <[hidden]>
>>> Répondre à : A discussion list for Android audio developers
>>> <[hidden]>
>>>
>>>
>>> On Sun, May 19, 2013 5:59 pm, Felix Homann wrote:
>>>> The video of the High performance audio talk is now available:
>>>>
>>>> http://www.youtube.com/watch?v=d3kfEeMZ65c&feature=youtube_gdata_player
>>>
>>>
>>> That might be the most frustrating thing I have ever seen.
>>>
>>> systrace, mutexes, variable buffer sizes, ringbuffer....  OMFIngG!
>>>
>>>
>>
>> Well it seems they are making "some" progress: finally allowing
>> SCHED_FIFO
>> threads for the audio stack, understanding priority inversion issues,
>> how
>> to avoid them..etc…
>>
>> But I still understand that only their audio stack can create SCHED_FIFO
>> threads for their own needs (so still don't see how a JACK like system
>> that needs to create RT threads for clients could be ported then…) and
>> they still speak about this crazy 5% CPU budget for all audio stuff….
>>
>> Hum.. iOS still have some huge advantage here.
>>
>
> At least we know who's responsible for cleaning up this mess now. It might
> even be possible to get one or both of them to actively participate in
> Linux Audio Development instead of just working within the Google
> ecosystem.
>

Please Note, I have cc'ed the two main presenters in the video above in
case they feel the need to respond and justify their decision making
process.

As a follow up to this exhilarating story of corporate intrique and
musical shenanigans I did indeed contact all three of the presenters in
the video and the reply I got was that they have of course read the JACK
code but they cannot use it because of unspecified licensing issues and
because it is power hungry.

If we dissect the situation and the presentation we can see the following
points:

- They have chosen the fast mixer approach which effectively hands off the
mixing to the hardware level
- Time that they took to get to this point (2 years by their own admission)
- n00b mistakes like writing their own profiler instead of using systrace,
etc...
- Their inability to see the point of allowing people to run PA or JACK if
they choose to ( Yet, no problems with OpenSL or various other corporate
backed industry projects)
- JACK is lgpl which is an extreemely permissive license
- The complete lack of participation in the Linux Audio Development
community choosing instead to figure everything out on their own, sucking
up Googles corporate dollars and wasting everyone elses time

My conclusion is these guys are not only out of their depth in terms of
ability to make rational decisions about the direction of Realtime audio
on the Android platform but they are purposefully blocking the open source
community. Google is therefore wasting a lot of time and money on them and
the person responsible for hiring them should absolutely be fired.

Until then it would appear that they have no real intention of actually
making any progress when it comes to enabling JACK on Android or any other
realtime audio tools.

The good news in this story is that people at the Intel OTC are actively
working on their own fork of Android where they are looking at this
specific issue and of course there is also Tizen (Intel/Samsung) which
already supports Pulse Audio and has a couple of dedicated PA developers
on salaries. Also there is picuntu and any number of other real Linux OS's
that we can use if we feel the need.

However as professional developers targeting Android as a business
platform it looks like we are all just going to have to accept that the
version of Android running on billions of devices all over the planet will
not support realtime audio and therefore JACK at anytime in the near
future and quite possibly never meaning we are not unable to port our
software to the platform and reap the rewards of the business or service
potential.

As a company director having worked with several professional audio
companies over the past 15 years including some OEM manufacturers and
various legends in the industry I feel completely let down by the Google
Audio team and cannot recommend to my clients that they develop for the
Android platform.


--
Patrick Shirkey
Boost Hardware Ltd
PrevNext  Index

1369198318.25351_0.ltw:2,a <57944.188.26.171.156.1369198307.squirrel at boosthardware dot com>