From: Brad M. <bmi...@xm...> - 2005-04-14 15:28:00
|
Hi I see soft float is turned off in the master makefile. Is the kernel intercepting fp calls and handling them or are we only allowed integer math? Our stereo-audio-over-bluetooth codec ("SBC") implementation currently uses floating point and I don't know enough about fp->integer or the codec to convert it to integer ops. (fwiw, it doesn't need libm) Brad |
From: kuehnle <ku...@ti...> - 2005-04-14 15:59:45
|
Hi Brad, i needed softloat support in the environment, because of dependencies of other applications, and switch to SOFT_FLOAT YES in the main Makefile and i had no problems in creating the soft float variante. A new buildroot and root_fs image will be created, so the old configuration should not be touched. Clemens Brad Midgley wrote: > Hi > > I see soft float is turned off in the master makefile. Is the kernel > intercepting fp calls and handling them or are we only allowed integer > math? > > Our stereo-audio-over-bluetooth codec ("SBC") implementation currently > uses floating point and I don't know enough about fp->integer or the > codec to convert it to integer ops. (fwiw, it doesn't need libm) > > Brad > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > |
From: Craig H. <cr...@hu...> - 2005-04-14 18:51:27
|
On Apr 14, 2005, at 8:27 AM, Brad Midgley wrote: > Hi > > I see soft float is turned off in the master makefile. Is the kernel > intercepting fp calls and handling them or are we only allowed integer > math? > > Our stereo-audio-over-bluetooth codec ("SBC") implementation currently > uses floating point and I don't know enough about fp->integer or the > codec to convert it to integer ops. (fwiw, it doesn't need libm) Kernel FP emulation is on (but dog slow). Hopefully the codec doesn't use much FP processing... C |
From: Brad M. <bmi...@xm...> - 2005-04-14 19:46:18
|
Craig, the codec does a lot of fp during encoding (eg any time you are sending an mp3 to a headset), so it can't be trapping into the kernel for every op. We could pre-encode stuff like music but sbc takes about twice the space of mp3 and most tools don't know what it is. I will plan to turn on soft float for this. if there's a space issue, the kernel emu could even be turned off, eh? no app should be issuing fp if everything is rebuilt with soft float. Brad Craig Hughes wrote: > On Apr 14, 2005, at 8:27 AM, Brad Midgley wrote: > >> Hi >> >> I see soft float is turned off in the master makefile. Is the kernel >> intercepting fp calls and handling them or are we only allowed integer >> math? >> >> Our stereo-audio-over-bluetooth codec ("SBC") implementation currently >> uses floating point and I don't know enough about fp->integer or the >> codec to convert it to integer ops. (fwiw, it doesn't need libm) > > > Kernel FP emulation is on (but dog slow). Hopefully the codec doesn't > use much FP processing... > > C > > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users |
From: Craig H. <cr...@hu...> - 2005-04-15 02:49:34
|
On Apr 14, 2005, at 12:46 PM, Brad Midgley wrote: > the codec does a lot of fp during encoding (eg any time you are > sending an mp3 to a headset), so it can't be trapping into the kernel > for every op. > > We could pre-encode stuff like music but sbc takes about twice the > space of mp3 and most tools don't know what it is. > > I will plan to turn on soft float for this. > > if there's a space issue, the kernel emu could even be turned off, eh? > no app should be issuing fp if everything is rebuilt with soft float. Yes, I have built soft-FP buildroots with the kernel FP emulation disabled, and everything I tried works fine. It's somewhat faster than kernel FP, but not enormously so -- realtime audio might or might not work very well; be interesting to see. Do you have the source/algo description for the codec? Might be worth a shot at rewriting it in integer math. I'd be happy to take a look. C |
From: Brad M. <bmi...@xm...> - 2005-04-15 04:08:17
|
Craig, The encoder is in sbc/sbc.c from the bluetooth-alsa project cvs. http://bluetooth-alsa.sf.net I also looked at it with the intention to eliminate some fp ops but it is complex enough that you would need to test with the unmodified decoder to make sure any changes are still correct. It's really just amazing that it works at all :) A lot of stuff could be single not double precision. That would help. brad Craig Hughes wrote: > > On Apr 14, 2005, at 12:46 PM, Brad Midgley wrote: > >> the codec does a lot of fp during encoding (eg any time you are >> sending an mp3 to a headset), so it can't be trapping into the kernel >> for every op. >> >> We could pre-encode stuff like music but sbc takes about twice the >> space of mp3 and most tools don't know what it is. >> >> I will plan to turn on soft float for this. >> >> if there's a space issue, the kernel emu could even be turned off, eh? >> no app should be issuing fp if everything is rebuilt with soft float. > > > Yes, I have built soft-FP buildroots with the kernel FP emulation > disabled, and everything I tried works fine. It's somewhat faster than > kernel FP, but not enormously so -- realtime audio might or might not > work very well; be interesting to see. Do you have the source/algo > description for the codec? Might be worth a shot at rewriting it in > integer math. I'd be happy to take a look. > > C > > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users |
From: Dave H. <dhy...@gm...> - 2005-04-15 04:53:02
|
hi Brad, > A lot of stuff could be single not double precision. That would help. Using single precision often makes things slower, rather than faster. Make sure you profile! In C, double is the "natural" floating type, and by default floating point numbers are promoted to double. For example 1.0 is a double, 1.0F is a float. Sometimes using float is a false economy because of all the conversions back and forth. --=20 Dave Hylands Vancouver, BC, Canada http://www.DaveHylands.com/ |
From: Vivek G <vi...@ga...> - 2005-04-15 05:09:41
|
Has anyone done it? It appears that the waysmall case has enough room to fit the pcb (except where it juts out the side of the case), so all that needs to be changed in the case is: 1) cut the case in the area where the compact flash socket is soldered in. 2) cut part of the case's side to allow the cfstix pcb to stick out. I'm planning to measure and cut the case this weekend, but was curious if anyone else has done this and if they have any pointers. If you're wondering why I'm doing this in the first place, my application (a small robot) requires wireless feedback, but I don't have time/all the materials to make a custom case and/or PCB to support the gumstix + cfstix + the waysmall stuart. Cheers, Vivek Gani |
From: Craig H. <cr...@hu...> - 2005-04-15 05:18:18
|
On Apr 14, 2005, at 10:09 PM, Vivek G wrote: > I don't have time/all the materials to make a custom case Duct Tape! C |