Yeah, a benchmarking patch sounds quite useful for a lot of things.
About the ARM naming scheme there are two numbering schemes for ARM CPUs. First, you'll see ARMv4, ARMv5, ARMv5TE, ARMv6, ARMv7, etc. Those are the various instruction sets. Then you'll see things like ARM9, ARM11, ARM Cortex A8, XScale, ARM9E, Apple A4, etc. Those are specific CPUs that implement an instruction set. If its got the 'v' in it, its an instruction set, otherwise its a specific implementation of the instruction set. For example, the ARM11 CPU implements the ARMv6 instruction set. ARM Cortex implements ARMv7.
.hc
On Mar 8, 2012, at 11:44 AM, Miller Puckette wrote:
This reminds me - I don't know where to go for information on how fast PD runs on various processors. For example, how does Raspberry Pi match up against Beagleboard? (I believe RP is ARM v6 and BB is ARM v7 so it's bpossible BB runs circles around RP - but the ARM model and instruction set naming scheme is extremely confusing to me.)
Would there be interest in my putting out some kind of benchmarking patch so folks can test it on their local devices?
cheers Miller
On Thu, Mar 08, 2012 at 03:30:59PM +0100, Duncan Speakman wrote:
Thanks!
we eventually got it working with a griffin iMic usb device, thanks for the tip. Having some performance issues with Pd so going to try PDa now.
d
On 5 March 2012 02:09, Miller Puckette msp@ucsd.edu wrote:
Could be a portability problem in Pd's audio I/O code or (more likely I think) some kind of limitation in the audio driver itself. Perhaps audio input only works in one channel and Pd is tring to use it in stereo? It migth help to use an external USB audio device if that's practical.
cheers Miller On Mon, Mar 05, 2012 at 12:19:04AM +0100, Duncan Speakman wrote:
Hi all,
We're running Pd 0.43 on a Gumstix Overo Airstorm with Cortex A8 architecture, using Linaro 12.02 distribution (which is based on Ubuntu 11.10 ) Pd seems to be working but audio input and output is displaying strange behaviours and processing artifacts. Simple osc~ objects play their tones at half pitch, and when we run audio into it in realtime ( connecting adc~ direct to dac~ ) we experience both lower pitch and time granulation. CPU usage reads less than 2%.
Samplerate is 44100 and blocksize is currently at 1024 (anything lower than this creates crackling, and causes CPU usage to jump to 80%)
Does anyone here know if this CPU is just unable to process floating point data at the speed required by Pd, or whether there are some processing settings/ priority settings or a different kind of kernel that would allow Pd to run correctly on this platform. We're surprised it's not working as we know PDlib runs fine on the iPhone for instance. We've already successfully run PDa on a Gumstix Verdex but really want to move to full Pd to get around the limitations of PDa.
any thoughts or suggestion welcome, we're getting desperate!
duncan
-- follow me : @ofcircumstance
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
-- follow me : @_dspk
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
----------------------------------------------------------------------------
Looking at things from a more basic level, you can come up with a more direct solution... It may sound small in theory, but it in practice, it can change entire economies. - Amy Smith