exciting, but it will be completely divergent from the intel/ppc world because of the floating point issue. this is really a great shame. floating point versus fixed point samples will reach deep into most audio/music software, and certainly deep in JACK. i can just about begin to imagine how one might write a JACK and a JACK client that could run on fixed or floating point, but beginning is where i give up. --p

On Thursday 12 January 2006 16:56, Jay Vaughan wrote: Well, the only problem is that you have to write all DSP code twice, basically. Then again, the DSP code usually accounts for just a fraction of the code of a full application. And heavy duty, DSP centric applications (ie ones with lots of DSP code) probably won't be of much use without a GFLOPS class CPU anyway. I would think you can compile and run them on just about anything - but without proper FP support (that is, an extremely fast integer CPU + FP emulation, or "anything" with a proper FPU), they won't run fast enough to do anything useful, unless all DSP code is translated to integer/fixed point. I can certainly understand why someone who isn't seriously interested in the odd few platforms with enough oomph but no FP, would lack the motivation to write and/or maintain code that is relevant only on these platforms. //David Olofson - Programmer, Composer, Open Source Advocate .------- http://olofson.net - Games, SDL examples -------. | http://zeespace.net - 2.5D rendering engine | | http://audiality.org - Music/audio engine | | http://eel.olofson.net - Real time scripting | '-- http://www.reologica.se - Rheology instrumentation --'

On Thursday 12 January 2006 18:06, Jay Vaughan wrote: Still shouldn't be much code to change - but someone still has to actually do it. Well, I decided to do it the hard (integer) way in the real time part of Audiality, but as maximum portability was a requirement, I had to do it in pure C - and that's certainly no fun, especially not on compilers without long long support. (MUL and DIV are so much nicer in asm, but AFAIK, no high level languages allow you to make proper use of it. :-/ ) The more interesting part, the modular synth engine (which is to be usable in the real time context in future releases), uses FP, because 1) I didn't have much time for hacking, and I'd rather have it running on FP than not at all, 2) it seems like integer processing is slower than FP on most machines with proper FPUs, 3) at the time, I knew of no integer-only hardware where real time modular synthesis was viable, and 4) most DSP stuff is easier to code in FP anyway, at least as long as you can't throw in some asm. Of course, for maximum scalability (which is a design goal, although not the primary one at this point), it would be best to have both FP and integer versions of everything - and maybe I'll do that eventually. However, the primary target platforms for the stuff I'm working on now is - guess what - x86 and PPC, so I have to focus on getting it to work (and preferably run fast) on those, first. If you just don't have the proper motivation to hack the code, you won't do it. Goes for everything, whether it's Free/Open Source or commercial. Unless someone needs the software, thinks hacking it would be fun, and/or believes there is money waiting to be made, the code doesn't get written. Well, I'm considering getting one, though I'm not totally sure what I'd use it for. (Except plain fun, of course, which is no small part of the whole Free/Open Source thing.) Are there any restrictions WRT which Linux drivers are available? (I'm thinking external USB devices and the like.) Does it support (USB) keyboards and mice? (A foldable rubber keyboard and some sort of tracker-like sequencer could be useful. Or is there a foldable rubber MIDI/USB keyboard out there somewhere?) Another thought: Is there a market for shareware games? (Ports, at least - it'd have to be a rather large market for dedicated game designs to be viable, I think.) //David Olofson - Programmer, Composer, Open Source Advocate .------- http://olofson.net - Games, SDL examples -------. | http://zeespace.net - 2.5D rendering engine | | http://audiality.org - Music/audio engine | | http://eel.olofson.net - Real time scripting | '-- http://www.reologica.se - Rheology instrumentation --'

At 15:40 +0100 13/1/06, Sam Roig wrote: yeah, that looks like a lot of fun .. definitely will keep an eye out for that as a near-future accessory for the GP2X .. -- ; Jay Vaughan

Hello, On Wed, Jan 18, 2006 at 10:38:23AM +0100, Jay Vaughan wrote: Sounds great, but I'm a little bit confused by other information I found on the web about USB host mode support: citing from http://www.gp32x.com/board/index.php?showtopic=20717: I/O Ports: Headphones, USB (not powered), EXT, DC Power (possibly SDIO in the future) *note* it may be possible to use self-powered USB peripherals with GP2X, i.e. USB hubs & harddrives etc. USB Peripherals: Recent information unfortunately reveals the GP2X does NOT feature USB host mode due to the chip implementation used in the final design. Where can I find information on how to make such a EXT adaptor cable that provides USB host mode IO with current of-the-shelf gp2x? TIA. ciao, Jacob

I believe he is refering to if the device can operate as a USB host bridge rather than just as a usb device. OTG devices and some embedded chips can be both. -- Richard A. Smith

On Wed, Jan 18, 2006 at 01:16:55PM -0600, Richard Smith wrote: Yes, that is what I'm refering to. AFAIK I haven't any chance to access an USB 'device' (device/slave/peripheral mode, eg MIDI/audio interfaces) from another one that isn't capable to do/switch to 'host mode', be it a host controller or an on-the-go (OTG) device. Citing from http://en.wikipedia.org/wiki/USB A USB system has an asymmetric design, consisting of a host controller and multiple devices connected in a tree-like fashion using special hub devices, called USB hubs. and An extension to USB called USB On-The-Go allows a single port to act as either a host or a device - chosen by which end of the cable plugs into the socket on the unit. Even after the cable is hooked up and the units are talking, the two units may "swap" ends under program control. This facility targets units such as PDAs where the USB link might connect to a PC's host port as a device in one instance, yet connect as a host itself to a keyboard and mouse device in another instance. Jacob

At 13:16 -0600 18/1/06, Richard Smith wrote: no, you see .. the gp2x has, sorta, 'two' of everything, including USB. there's the on-chip (magiceyes) USB1 'host device' (like in your PC) routed only to EXT2 (not a standard 'flat' USB jack), and there's the additional 'slave device' USB2 chipset going to the mini-USB-socket on the side. its quite possible to put a USB-Gadget, class compliant audio driver onboard that would turn the gp2x into a 'sound device' for your PC, or Mac, or whatever .. and use the USB hosting abilities to do MIDI, other sound cards, etc... -- ; Jay Vaughan

On Thu, Jan 12, 2006 at 10:52:58AM -0500, Paul Davis wrote: JACK itself shouldn't be affected too much. Apart from the dithering it does not do any processing. The standard sample type could be a signed 32 bit, with bits 23 downto 24-N mapped to N-bit hardware. On input bits 24..31 are sign extended from bit 23, on output the values are clipped as they are now. In other words, the standard format could be 9.23 fixed point. This makes the hardware resolution transparent to clients and accomodates all hardware up to 24 bits (it's useless to go beyond that). If you look at the history of digital audio, most of it was integer or fixed point. There is a enormous amount of knowledge gathered over the years on how to do things correctly in that format. I can still remember the JAES papers on how to avoid limit cycles in IIR filters etc... -- FA

errm.. in my limited GPL'itude, i thought the rule was that we should be running GPL software wherever we can, and choose to? fact is, gp2x is nice hardware to run, 100%, your own code on. of the code that currently makes the GP2X fun and great, and great fun, there is a lot, like, a majority of it, that is open, shared, and well-orchestrated as a community resource by its maintainers. and the hardware is the right price. GPH may not be communicating too well, no, but the spirit of the GPL is hot on this box, and i really believe GPH are making GPL compatible, and thus ultra-friendly, hardware, anyway .. i don't read enough korean complaints about it, either, though i certainly wish i could. ever had kimschi, or know how to make it? -- ; Jay Vaughan