@rpedde wrote:
The other one referenced there, the roku one, apparently runs at 2 – 3x realtime on a 300mhz mips.
Sounds like it will be touch-and-go on an underclocked slug.
I’d take a pass at building a slug package for it though, if anyone wanted to try it.
I’ll give it a run; my WMA files aren’t particularly demanding (128-192kbps CBR or somewhere downwards from 200kbps VBR), and I have enough of them I can give it a run with the Mac Mini iTunes as a client. My slug is still running at the default/underclocked speed, and it is also running Twonkyvision (but I have both Twonky and Firefly set for manual library scanning only – I don’t buy new CDs all that frequently), so it’s probably a reasonable test as to whether the speed and accuracy in that decoder would be of shippable quality.
If it doesn’t work out on the initial try, it’s probably not a big deal to most users, and could I think safely be shelved until someone (else) manages some further optimisation of the WMA decoding code (which could then be re-attempted from Firefly in some post-1.0 version). The main scenario it supports is (like mine) a user who previously hosted their music library on a Windows PC (with WMC and/or maybe Twonkyvision) with some amount of their CDs ripped to WMA and they move to a NSLU2 with Firefly for the 24*7, richer SB support, and spouse-friendly convenience, and they still want to be able to serve all their content (without re-ripping) to (1) one or more Soundbridges, and (2) various PCs/Macs in the house running iTunes. Obvious workaround for me is to re-rip the CDs previously ripped to WMA to higher bitrate MP3 instead (disc space is a lot cheaper now, and I guess I could enlist my slaves^H^H^H^H^H^H^H kids to do the mechanics of feeding the CDs in to re-rip them for pocket money), but if it could “just work” for WMA from Firefly to iTunes when running from a NSLU2 like it does from a Windows box, that would be a great result.
ted.h.