Bugzilla – Bug 230
Native FLAC Decoding at Squeezebox
Last modified: 2008-05-15 08:58:44 UTC
For several reasons native FLAC decoding is desirable. For starters it will approximately halve the bandwidth required required to transmit lossless audio to the Squeezebox and double the buffer depth at the Squeezebox. These two reasons have significant advantages for wireless Squeezeboxes. FLAC is particularly suited for decoding on a low powered appliances such as the Squeezebox. The codec's philosophy is asymmetric: larger CPU load on encode, low load on decode. Indeed if/once FLAC is implemented on the Squeezebox it could also become the lossless transmission format of choice. I.E. wav/pcm/etc. could be encoded on the fly to FLAC before being streamed to the Squeezebox to conserve bandwidth. 'Back-of-envelope' calculations suggest that realtime FLAC encoding would take under 5% CPU utilization for most desktops; probably under 2% for the average Squeezebox owner ;-). It also an open source codec and thus freely available in source and compiled format and, as far as I understand, there would be no licensing fees. FLAC seems to be on it's way to become the defacto standard for lossless, DRM free, encoding. Finally it appears, anecdotally at least, that many of the audiophile (or better than mp3phile) Squeezebox users have adopted FLAC as the archive format of choice for their Slimserver library.
*** Bug 360 has been marked as a duplicate of this bug. ***
Native FLAC decoding would also allow seeking (fast-forward and rewind) on FLAC files. Currently seek isn't an option for any transcoded file.
Alas, SB doesn't have enough horsepower to do FLAC, but SB2 has this feature.
I appreciate you would not really want to devote any effort to implementing FLAC on the SB1 with it available on the SB2. I am however curious: for the record was it ever actually tried or just abandoned in favor of the SB2 path?
A practical implementation was never attemped on the 120Mhz 8-bit ip2k processor, but the cpu and memory requirements were estimated - at the time it looked "quite difficult" but not "absolutely impossible". After doing the 250Mhz 32-bit ip3k implementation and learning more about the CPU and memory bandwidth requirements for FLAC, it was concluded that an ip2k implementation would not be feasible. The other approach was to try and do it in the MIcronas DSP, which almost certainly would have been within its capabilities. However, the Micronas is sold as a closed, fixed function architecture, and although the chip is reprogrammable, we were never able to get access to the tools or documentation needed to do it (we tried hard).
Sean wrote: > The other approach was to try and do it in the MIcronas DSP, > which almost certainly would have been within its capabilities. > However, the Micronas is sold as a closed, fixed function architecture, > and although the chip is reprogrammable, we were never able to get > access to the tools or documentation needed to do it (we tried hard). Thanks for the recap. It is frustrating to the have the horsepower but not be able to use it because of the the application specific nature and proprietary tools. That is the attraction of the SB2 in terms of giving yourself a reasonably general purpose CPU and DSP and adequate memory. You can then reconfigure, tweak, and fix to your hearts content. I'm going to order myself some SB2 goodness this week since Kawatha gets them in tomorrow. Say you never did say if the free pony was going to be available as a rebate ;-).
Hmm.. do we need a category for sales and marketing bugs? No I don't think we have a FREEPONY program abroad.
> Hmm.. do we need a category for sales and marketing bugs? That might be a first for Bugzilla! > No I don't think we have a FREEPONY program abroad. I understand; with quarantine regulations and all. :)