Re: [LAD] Android audio plugins

Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
To: <gabrbedd@...>, <list@...>
Cc: <linux-audio-dev@...>
Date: Wednesday, June 29, 2011 - 6:00 pm

--_a852ae9b-5376-4606-ba6d-bd83177688d9_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

> - Mobile processors generally do NOT have good

It can be a factor of 1000 if the binaries are built assuming there is an F=
PU.
What happens is you get a system call for every failed float operation. If =
the
toolset is geared to understand that none is available then it generates so=
ft
floating point operations that just occur in the user thread. Performance h=
it
is about two zeroes less than you are discussing here. Android appears to=20
generate softfloat code.

> - LADSPA and LV2 are built to process 32-bit

Do these systems actually process the floats though? I would have thought
most of their work was moving floating point *buffers around so that other
programs could do DSP work on them - these are plugin processors so there
is not a great demand that they manipulate the data they move between the
plugins (LADSPA is rather unfortunately named as in does seem to suggest
it does DSP which it doesn't - but I will happily stand corrected here).=20

Moving audio data around should only affect memory alloc rather than CPU=20
hits. If this code does floating point work then the basic stuff (mixing=2C=
=20
moving=2C etc) can be accelerated on the ARM FPU.

> So=2C trying to use LADSPA or LV2 in their current state will=20

Yes=2C but I don't think it has to be that big. The bigger issue is why the=
hell
would you want to do it=2C integrate LV2 and LADSPA on to this platform?
The issue is that support on Linux is already patchy=2C so are the few apps=
=20
that support it on Linux likely to migrate to Android? A lot of the audio a=
pps
that now appear on Andoid (very few of which come from a Linux heritage)
are taking a monolithic approach of having an integral package with the
synth/bass/drums/seq in the app.

There probably are arguments for doing this. The actual CPU performance
of the current ARM dual core handsets is pretty respectable and it is only
going to increase. So as the tablets start having these resources then ther=
e
are some interesting but I really think there is a difference between Linux
and something like Android - this just uses a Linux kernel=2C most of the r=
est
is way different.

Don't you think it is more likely that people who are interested will run
Linux as a replacement for Android on the ARM tablets rather than have
the apps ported over?

Regards=2C nick
=

--_a852ae9b-5376-4606-ba6d-bd83177688d9_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

&gt=3B - Mobile processors generally do NOT have good&gt=3B =
floating point power. Sometimes by a factor&gt=3B of 1000 flops=
.It can be a factor of 1000 if the binaries are built assuming ther=
e is an FPU.What happens is you get a system call for every failed floa=
t operation. If thetoolset is geared to understand that none is availab=
le then it generates softfloating point operations that just occur in t=
he user thread. Performance hitis about two zeroes less than you are di=
scussing here. Android appears to generate softfloat code.&gt=
=3B - LADSPA and LV2 are built to process 32-bit&gt=3B floating=
point PCM data=2C and have no provision&gt=3B for processing 16-b=
it integer PCM data.Do these systems actually process the floats th=
ough? I would have thoughtmost of their work was moving floating point =
*buffers around so that otherprograms could do DSP work on them - these=
are plugin processors so thereis not a great demand that they manipula=
te the data they move between theplugins (LADSPA is rather unfortunatel=
y named as in does seem to suggestit does DSP which it doesn't - but I =
will happily stand corrected here). Moving audio data around should=
only affect memory alloc rather than CPU hits. If this code does float=
ing point work then the basic stuff (mixing=2C moving=2C etc) can be ac=
celerated on the ARM FPU.&gt=3B So=2C trying to use LADSPA or LV2 i=
n their current state will &gt=3B probably cause bottlenecks (either fr=
om doing FP math or &gt=3B from doing format convervsions to do integer=
math).&gt=3B &gt=3B Is this a Real Problem?Yes=2C but I do=
n't think it has to be that big. The bigger issue is why the hellwould =
you want to do it=2C integrate LV2 and LADSPA on to this platform?The i=
ssue is that support on Linux is already patchy=2C so are the few apps =
that support it on Linux likely to migrate to Android? A lot of the audio a=
ppsthat now appear on Andoid (very few of which come from a Linux herit=
age)are taking a monolithic approach of having an integral package with=
thesynth/bass/drums/seq in the app.There probably are argument=
s for doing this. The actual CPU performanceof the current ARM dual cor=
e handsets is pretty respectable and it is onlygoing to increase. So as=
the tablets start having these resources then thereare some interestin=
g but I really think there is a difference between Linuxand something l=
ike Android - this just uses a Linux kernel=2C most of the restis way d=
ifferent.Don't you think it is more likely that people who are inte=
rested will runLinux as a replacement for Android on the ARM tablets ra=
ther than havethe apps ported over?Regards=2C nick =

=

--_a852ae9b-5376-4606-ba6d-bd83177688d9_--

Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

Messages in current thread:
[LAD] Android audio plugins, Olivier Guilyardi, (Wed Jun 29, 3:56 pm)
[LAD] Android Java stack, Jens M Andreasen, (Thu Jun 30, 7:27 am)
Re: [LAD] Android Java stack, Olivier Guilyardi, (Thu Jun 30, 9:53 am)
Re: [LAD] Android Java stack, Jens M Andreasen, (Thu Jun 30, 11:34 am)
Re: [LAD] Android Java stack, Olivier Guilyardi, (Thu Jun 30, 11:49 am)
Re: [LAD] Android Java stack, Jens M Andreasen, (Thu Jun 30, 3:57 pm)
Re: [LAD] Android Java stack, Olivier Guilyardi, (Thu Jun 30, 5:49 pm)
Re: [LAD] Android Java stack, Jens M Andreasen, (Thu Jun 30, 6:08 pm)
Re: [LAD] Android Java stack, , (Thu Jun 30, 6:30 pm)
Re: [LAD] Android Java stack, Adrian Knoth, (Thu Jun 30, 8:30 am)
Re: [LAD] Android audio plugins, Gabriel M. Beddingfield, (Wed Jun 29, 4:19 pm)
Re: [LAD] Android audio plugins, Nick Copeland, (Wed Jun 29, 6:00 pm)
Re: [LAD] Android audio plugins, Olivier Guilyardi, (Wed Jun 29, 7:55 pm)
Re: [LAD] Android audio plugins, Nick Copeland, (Wed Jun 29, 8:33 pm)
Re: [LAD] Android audio plugins, Olivier Guilyardi, (Wed Jun 29, 10:47 pm)
Re: [LAD] Android audio plugins, Gabriel M. Beddingfield, (Wed Jun 29, 6:24 pm)
Re: [LAD] Android audio plugins, Nick Copeland, (Wed Jun 29, 6:47 pm)
Re: [LAD] Android audio plugins, Jens M Andreasen, (Thu Jun 30, 7:19 am)
Re: [LAD] Android audio plugins, Gabriel M. Beddingfield, (Wed Jun 29, 7:03 pm)
Re: [LAD] Android audio plugins, Nick Copeland, (Wed Jun 29, 7:07 pm)
Re: [LAD] Android audio plugins, Olivier Guilyardi, (Wed Jun 29, 7:46 pm)
Re: [LAD] Android audio plugins, Nick Copeland, (Wed Jun 29, 8:03 pm)
Re: [LAD] Android audio plugins, Olivier Guilyardi, (Wed Jul 6, 2:01 pm)
Re: [LAD] Android audio plugins, Gabriel M. Beddingfield, (Wed Jun 29, 8:32 pm)
Re: [LAD] Android audio plugins, Olivier Guilyardi, (Wed Jun 29, 10:10 pm)
Re: [LAD] Android audio plugins, Gabriel M. Beddingfield, (Wed Jun 29, 7:18 pm)
Re: [LAD] Android audio plugins, Olivier Guilyardi, (Wed Jun 29, 4:46 pm)
Re: [LAD] Android audio plugins, Gabriel M. Beddingfield, (Wed Jun 29, 4:59 pm)
Re: [LAD] Android audio plugins, David Robillard, (Wed Jun 29, 10:36 pm)