11 Jan
2006
11 Jan
'06
6:48 a.m.
hi all,
well i've recently waded into the GP2X territory, fairly deeply, and
i'm enjoying it immensely:
http://gbax.com/
its a dual-processor (ARM) portable games machine, battery powered,
US$180, and .. it runs linux, has a very interesting EXT connector
which supports USB and MIDI, video and audio, and extremely active
games coding is going on, with well over 10,000 games currently
runnable on it (emulation, baby):
http://wiki.gp2x.org/wiki/EXT
it can support usb-gadget audio (already has usb-gadget serial) so it
wouldn't be terribly hard to 'integrate' it, either, with USB-based
audio outputs .. and there is SDL onboard too, for graphics, with
cairo/libsvg of course ..
so its not such a stretch to consider this to be -the- synthesis
platform of choice for linux audio hacking, and so i was wondering ..
what linux-based softsynths do you think would be worthy to port to
such a beast? i've already got sampling, a sequencer (thanks to
MidiShare), and some basic audio idea's down, but what do you guys
think about having a bit of a port-fest and turning the GP2X into a
veritable treasure trove of a softsynth platform?
--
;
Jay Vaughan
11 Jan
11 Jan
6:59 a.m.
On Wed, Jan 11, 2006 at 11:47:53AM +0100, Jay Vaughan wrote:
http://gbax.com/
its a dual-processor (ARM) portable games machine, battery powered,
US$180, and .. it runs linux, has a very interesting EXT connector
which supports USB and MIDI, video and audio, and extremely active
games coding is going on, with well over 10,000 games currently
runnable on it (emulation, baby):
How's its float performance? Older ARMs have very bad/non-existant floating
point support.
If its not up to scract it's not the end of the world, it just narrows the
choices a bit.
Does it have enough umph to run JACK? That would make it an interesting
platform for audio hacking.
- Steve
7:12 a.m.
How's its float performance? Older ARMs have very
bad/non-existant floating
point support.
i would wager that floating-point is not its forté, but rather than
give you an opinion, what would be got a good float-performance
benchmark that i can run on it to give you some real figures? is
there a preferred stdout-style C app i can run that'll give us some
real figures?
also keep in mind its dual-processor; the second processor is 100%
free to run code as fast as it can, while processor-1 is doing the
linux thing .. so while floating-point performance may be abysmal,
fixed-point math on the second CPU may just be fine ..
more details about the specs here:
http://wiki.gp2x.org/wiki/Docs_and_Papers
If its not up to scract it's not the end of the
world, it just narrows the
choices a bit.
i wouldn't put this in the class of 'high-performance hardware', but
more 'hardware worth squeezing every last bit of performance out of
it'.
Does it have enough umph to run JACK? That would make
it an interesting
platform for audio hacking.
i don't think JACK would be wise on this thing, though i could be
wrong .. its really designed to be a 'single-app running at a time'
platform, and so far supports SDL/SDL_mixer, though you can do raw
hardware i/o to the codec of course, and .. well .. there is the
matter of USB-Audio Gadget drivers, which would provide a path to
higher-power DAW upstream ..
--
;
Jay Vaughan
8:14 a.m.
On Wed, Jan 11, 2006 at 12:12:30PM +0100, Jay Vaughan wrote:
Just write some code that does a bunch of float mutiplies on an array and
time them.
The maximum peak performance of a modern CPU is 1 or 2 cycles per
multiply, but in practice memory bandwidth throttles that. 10 might be
more typical at a rough guess.
Writing DSP code for integer platforms is extremly tedious, and I dont
think you will want to port any float code to an integer only platform.
Best to look for code that allready works in ints.
- Steve
How's its
float performance? Older ARMs have very bad/non-existant floating
point support.
i would wager that floating-point is not its forté, but rather than
give you an opinion, what would be got a good float-performance
benchmark that i can run on it to give you some real figures? is
there a preferred stdout-style C app i can run that'll give us some
real figures? 
8:38 a.m.
On Wed, Jan 11, 2006 at 12:14:07PM +0000, Steve Harris wrote:
The maximum peak performance of a modern CPU is 1 or 2
cycles per
multiply, but in practice memory bandwidth throttles that. 10 might be
more typical at a rough guess.
For most intensive DSP applications, PCs are limited by memory bandwidth.
Writing DSP code for integer platforms is extremly
tedious,
Having done a lot of it (fixed point, on ARM), I'd disagree. But It is
certainly different. If you want good fixed point performance, you have
to write some of the inner loops in assembly. Not that this is a problem
- ARM assembly is a pure pleasure compared to Intel. And there a lots of
little computation that can be expressed more easily in assembler than
in C/C++.
and I dont
think you will want to port any float code to an integer only platform.
That's absolutely correct. You have to design your algorithms from the
start for integer / fixed point.
--
FA
9:31 a.m.
think you will
want to port any float code to an integer only platform.
That's absolutely correct. You have to design your algorithms from the
start for integer / fixed point.
9:53 a.m.
On Wed, Jan 11, 2006 at 01:38:45PM +0100, Alfons Adriaensen wrote:
I agree about ARM assembly, I have written some (not DSP related) many
years ago and it was quite straightforward.
Does this ARM chip have real fixedpoint hardware, or do you have to do bit
manipulations to get the numbers?
- Steve
Writing DSP
code for integer platforms is extremly tedious,
Having done a lot of it (fixed point, on ARM), I'd disagree. But It is
certainly different. If you want good fixed point performance, you have
to write some of the inner loops in assembly. Not that this is a problem
- ARM assembly is a pure pleasure compared to Intel. And there a lots of
little computation that can be expressed more easily in assembler than
in C/C++.
10:01 a.m.
On Wed, Jan 11, 2006 at 01:53:25PM +0000, Steve Harris wrote:
I agree about ARM assembly, I have written some (not
DSP related) many
years ago and it was quite straightforward.
Another ex Acorn user ???
Does this ARM chip have real fixedpoint hardware, or
do you have to do bit
manipulations to get the numbers?
It doesn't have anything specific fixed point. It's all integer, and you,
as the programmer, have to imagine a binary point somewhere in your data
and keep track of it.
What helps enormously on the ARM is that all arithmetic instructions can
include a (no overhead) shift on one of the operands. There are some
other unique things, such as the 16 conditions on *all* instructions.
--
FA
10:08 a.m.
On Wed, Jan 11, 2006 at 03:01:28PM +0100, Alfons Adriaensen wrote:
Yeah, some of my LADPSA code uses pseudo-fixedpoint to track things like
phases. I found it slightly simpler than floating point, and things like
modulos and finding what quadrant its in is really cheap.
On Wed, Jan 11, 2006 at 01:53:25PM +0000, Steve Harris
wrote:
Damn, does it show ;)
I agree about ARM assembly, I have written some
(not DSP related) many
years ago and it was quite straightforward.
Another ex Acorn user ??? Does this ARM
chip have real fixedpoint hardware, or do you have to do bit
manipulations to get the numbers?
It doesn't have anything specific fixed point. It's all integer, and you,
as the programmer, have to imagine a binary point somewhere in your data
and keep track of it. What helps enormously on the ARM is that all
arithmetic instructions can
include a (no overhead) shift on one of the operands. There are some
other unique things, such as the 16 conditions on *all* instructions.
I see, that is helpful. I imagine that coding things like IIR filters is
still quite time consuming though. I would expect that you need to switch
between different point positions a lot.
- Steve
10:20 a.m.
On Wed, Jan 11, 2006 at 02:08:05PM +0000, Steve Harris wrote:
Sometimes, yes. But it doesn't really have to complicate your code.
What I've done in most cases is to base the design of the algorithm from
the start on what I knew was possible / cheap / to-be-avoided / etc. in
ARM assembly. That's possible only if you are in the position of being the
system engineer and the coder at the same time.
--
FA
Damn, does it show ;)
You're not alone :-)
What helps
enormously on the ARM is that all arithmetic instructions can
include a (no overhead) shift on one of the operands. There are some
other unique things, such as the 16 conditions on *all* instructions.
I see, that is helpful. I imagine that coding things like IIR filters is
still quite time consuming though. I would expect that you need to switch
between different point positions a lot. 
11:24 a.m.
Alfons Adriaensen wrote:
On Wed, Jan 11, 2006 at 02:08:05PM +0000, Steve Harris
wrote:
In the near future I may be an Acorn user yet again! I'm planning to
appropriate my Dad's old A5000, find our Sibelius discs, and put the
MIDI interface to good use! Maybe use it to control my Linux audio
boxes... (back on topic, just!)
Maybe I should just bite the bullet and buy a RISC PC on eBay...
Michael Nelson
Damn, does it show ;)
You're not alone :-)
11:34 a.m.
On Wed, Jan 11, 2006 at 03:24:45PM +0000, Michael T D Nelson wrote:
Alfons Adriaensen wrote:
Hum. I can't say I'm that nostalgic. They were great machines at the time,
and ARM is certainly more pleasant that x86, but I like not /having/ to
code assembler, 500GB disks, portable machines, and many other things :)
- Steve
On Wed, Jan 11, 2006 at 02:08:05PM +0000, Steve
Harris wrote:
In the near future I may be an Acorn user yet again! I'm planning to
appropriate my Dad's old A5000, find our Sibelius discs, and put the
MIDI interface to good use! Maybe use it to control my Linux audio
boxes... (back on topic, just!) Damn, does it show ;)
You're not alone :-)
7:21 a.m.
On Wed, Jan 11, 2006 at 10:59:47AM +0000, Steve Harris wrote:
On Wed, Jan 11, 2006 at 11:47:53AM +0100, Jay Vaughan
wrote:
Non existant in ARM 9.
regards,
- Bengan -------------------------------------------------------------
- KTHNOC/SUNET/NORDUnet | http://www.noc.kth.se/~bengan | 08-7906586 -
http://gbax.com/
its a dual-processor (ARM) portable games machine, battery powered,
US$180, and .. it runs linux, has a very interesting EXT connector
which supports USB and MIDI, video and audio, and extremely active
games coding is going on, with well over 10,000 games currently
runnable on it (emulation, baby):
How's its float performance? Older ARMs have very bad/non-existant floating
point support.
6887
days inactive
6887
days old
linux-audio-dev@lists.linuxaudio.org
13 comments
6 participants
participants (6)
-
Alfons Adriaensen -
Bengt Gördén -
Jay Vaughan -
Michael T D Nelson -
Paul Davis -
Steve Harris