Thanks for the info, Dave. Speed is a very important feature, but there might be some risk choosing the FFmpeg decoder. They've had trouble with their encoder in the past, which tells me it's possible your users might one day run into a valid FLAC that the FFmpeg decoder won't handle correctly. A better suggestion might be to start with libFLAC, optimize as needed, and then submit the optimizations back to the FLAC project where they will be more widely useful. But that's just my opinion. Brian Willoughby Sound Consulting On Feb 25, 2009, at 03:10, Dave Chapman wrote: I'm a developer with the Rockbox project - http://www.rockbox.org - which is a written-from-scratch operating system and application suite designed for portable audio players. We of course support FLAC, and have a small, well-optimised (for embedded targets, including ARM) decoder which I think would be perfect for the devices Android runs on. It is based on the decoder from ffmpeg, and hence is licensed under the LGPL, with Rockbox specific code licensed under the GPL. I don't know if the GPL will be a problem with this part of Android. If the LGPL is compatible, then I'm sure the relevant Rockbox developers (including myself) would be happy to donate their code under that license. We initially implemented FLAC playback in Rockbox using libFLAC, but achieved significant speed gains (and reduced code size) when switching to the smaller ffmpeg decoder. I'm afraid I don't have exact figures to hand, but can try and dig them out if people are interested. Our current decoder can decode a typical FLAC file using about 13MHz of an arm7tdmi core. On portable (battery-powered) devices, performance is very important. The Rockbox source code can be browsed here: http://svn.rockbox.org/viewvc.cgi/trunk/ See apps/codecs/ for our codecs. If I was going to attempt to implement this, I would definitely go for the ffmpeg decoder, rather than libFLAC, assuming the license is OK. Regards, Dave.
On Wed, Feb 25, 2009 at 2:23 PM, Brian Willoughby <brianw at sounds.wa.com>wrote:> A better suggestion might be to start with libFLAC, optimize as > needed, and then submit the optimizations back to the FLAC project > where they will be more widely useful. > > But that's just my opinion. > > Brian Willoughby > Sound Consulting >I agree. This way the DirectShow filter for Windows Mobile (based on libFLAC) will also benefit from those optimizations. Cheers, Cristian. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.xiph.org/pipermail/flac-dev/attachments/20090225/4eb65ed6/attachment.htm
Cristian Adam wrote:> On Wed, Feb 25, 2009 at 2:23 PM, Brian Willoughby <brianw at sounds.wa.com>wrote: > >> A better suggestion might be to start with libFLAC, optimize as >> needed, and then submit the optimizations back to the FLAC project >> where they will be more widely useful. >> >> But that's just my opinion. >> > > I agree. This way the DirectShow filter for Windows Mobile (based on > libFLAC) will > also benefit from those optimizations.When Rockbox switched from libFLAC to the ffmpeg decoder, FLAC turned from one of our slowest codecs, to the fastest. The difference was extremely dramatic. libFLAC is the _reference_ implementation of FLAC, not one that is designed to be the ideal decoder everywhere. That's the advantage of open codecs - the specification is public, and third-party encoders/decoders should be encouraged, not immediately rejected without consideration. I'm not talking about things that can be achieved by optimising libFLAC. One of the reasons the Rockbox version of the ffmpeg decoder is so fast on our target devices is because it is very tightly integrated (no abstract layers of API). i.e. we created a FLAC codec designed specifically for the Rockbox codec API. This involved extracting the FLAC decoder from ffmpeg, using the core decoding parts of that code, and writing new code just for Rockbox. Whilst this was a lot more work to do than simply linking libFLAC, the end result was very worthwhile. Regards, Dave.
On Wed, Feb 25, 2009 at 5:23 AM, Brian Willoughby <brianw at sounds.wa.com> wrote:> A better suggestion might be to start with libFLAC, optimize as > needed, and then submit the optimizations back to the FLAC project > where they will be more widely useful.I know ARM and Thumb assembly code - Thumb is a compressed subset of ARM that has greater code density. Both are very important for embedded applications. A while back I did an Advanced Encryption Standard hard disk drive encryptor that ran entirely on-board the Oxford Semiconductor OXFW911 FireWire/IDE bridge chip. Unfortunately, the 911's ARM7TDMI CPU only runs at 50 MHz, and AES requires several rounds of encryption to process a block, so my first C implementation was as slow as molasses. I was able to speed it up by a factor of 10 or so by implementing the encryptor/decryptor in assembly code. There are several ARM simulators available. You don't need actual ARM hardware to test ARM machine code! A very helpful first cut at optimization is to have the simulator simply count the number of instructions executes during the run of a program. A better runtime profile can be had by writing a memory map for the simulator to use, that specifies the read and write access times and bus width of each memory region in the target you're simulating. Typically RAM is 32-bit and fast, while Flash is 32-bit for higher-end devices and 16-bit for lower-end devices like the 911, and is generally slow. I think there is an ARM simulator that can be integrated into GDB, so that you can debug your code on the desktop platform of your choice. What I would suggest you do to start, is get an ARM compiler/simulator toolchain set up on whatever kind of box you use, and get libflac, libogg and the flac command line program to build for it. I'll get back to you with some tips on ARM assembly code, and lots of links for ARM programming tips. I recommend the book I used to learn ARM assembly... let's see... ARM System-on-Chip Architecture 2nd Edition by Steve Furber, published by Addison-Wesley: http://www.arm.com/documentation/books/5651.html Ideally you will want *both* ARM and Thumb implementations. ARM is faster if you have a 32-bit bus and lots of Flash, but Thumb is faster - and will fit at all - if you have only a small amount of 16-bit Flash. Besides having higher code density, Thumb machine code instructions are fixed at 16-bits wide, whereas ARM opcodes are 32-bits wide. An ARM CPU can execute Thumb code if there is a "T" in its model number, such as the ARM7TDMI, which is very popular for very low-power, physically compact applications such as the Oxford 911 - the whole chip, including an IDE core, a FireWire Link-Layer core, 64 kb of Flash and 1800 bytes of RAM is about the size of a dime! You can also mix both kinds of code; there are assembly code instructions to switch back and forth. That's what I did with my encryptor; I loaded my machine code into RAM, then used ARM instructions for the innermost loops. Hope this helps! Mike -- Michael David Crawford mdcrawford at gmail dot com GoingWare's Bag of Programming Tricks http://www.goingware.com/tips/