Rockbox Technical Forums
Support and General Use => Audio Playback, Database and Playlists => Topic started by: Davide-NYC on October 24, 2006, 03:45:08 PM
-
To all DEVS: I wish to point out an untapped resource. The users!
Currently the forums contains a lot of "audio skips/hangs/stops" posts, as in: "My audio is skipping, why?".
Many of these posts can be individually addressed by simply telling the OP to turn off peakmeters or crossfade or whatever to reduce CPU load. But it does not address the core issue.
The core issue is codec optimization, right?
What is needed is a decoder plugin with a benchmarking mode,
(see flyspray request here) (http://www.rockbox.org/tracker/task/6152)
and a standardized sample set of files for testing,
(see Twiki page here) (http://www.rockbox.org/twiki/bin/view/Main/CodecPerformanceComparison)
so that we could turn a group of confused/disgruntled users into a group of useful testers!
What we need is a decoder plugin so we can solicit easy testing from the users.
An encoder plugin would be beneficial too and seemingly easier since we already have two encoder plugins: wav2wv and mp3.encoder (which I have requested be renamed here) (http://www.rockbox.org/tracker/task/6233)
Discuss!
{edit} I changed the title from "Request" to "Discussion" before I got yelled at by Llorean. ;D
-
I actually won't yell as long as there's a feature request in the tracker, clearly linked from within the topic. :-P
-
I'm not sure how useful this would be - we know Rockbox needs optimising on the ipods, and it's not just codecs - it's also LCD drawing, disk I/O, GUI code... We don't really need testers, we need coders who can spend time improving things.
-
I can give one concrete example of usefulness even if the testing is deemed unnecessary.
A user could, with this imagined plugin, decode a wma to wav and then listen to it in real-time.
Clearly this task is better served by a PC, but on the go, away from a PC in a pinch it would be great.
And here's another (less-concrete) example.
At what point is a codec deemed "fast enough" for a specific target? This would be easier to determine if a larger number (anything more than 1 currently) of users posted data on the matter in the wiki.
Of course I concede that this all might be futile, but it is an honest attempt, by someone that speaks no ASM and little C to find a way to contribute in concrete terms.
If this is deemed totally useless I will drop it, but I'd like the matter discussed at some length first just for confirmation.
The plugin is envisioned as an eventual 'transcoder interface' allowing users to convert from any readable (even non-realtime) format to any supported encoded format. Those input formats are the currently supported ones plus WMA. The output formats are MP3, Wavpack and WAV only. I personally don't see the need to expand the number of output formats.
-
I'm not sure how useful this would be - we know Rockbox needs optimising on the ipods, and it's not just codecs - it's also LCD drawing, disk I/O, GUI code... Â We don't really need testers, we need coders who can spend time improving things.
Not all attempts at optimising, as I've quite often found out, work out as you'd think. For this reason I very much miss the ability to measure codec performance accurately (as we could with wav2xxx plugs). The only current alternative is looking at the boost factor, which I'm sure I don't need to explain is quite inaccurate and cumbersome ;)
-
Not all attempts at optimising, as I've quite often found out, work out as you'd think. For this reason I very much miss the ability to measure codec performance accurately (as we could with wav2xxx plugs). The only current alternative is looking at the boost factor, which I'm sure I don't need to explain is quite inaccurate and cumbersome ;)
You can use a profile build for that. It might be a bit cumbersone to set up (especially if you want to disable profiling for some inline functions), but should at least be more accurate. :)
-
I think there are two main benefits to this idea.
1. Getting the users to upload a ton of useful data. They want to help, they don't know how and this would be one way they could. Said data could better 'direct' developer resources. You know: To what degree do which codecs run slow on which platforms?
2. Getting non-realtime encoded files (WMA and ... ?) decoded to WAV in order to have them playback realtime *in a pinch*. By the time WMA decodes in realtime I suspect there will be some other format that needs to go through the same process.
Am I totally off? :P
-
2 is silly, in all honesty. If you know a file won't decode in realtime, decode it in advance and don't waste the battery life on it.
There's currently no way to get a WMA onto any of the software codec players without hooking them up to a computer.
-
There's currently no way to get a WMA onto any of the software codec players without hooking them up to a computer.
There is a way how to transfer files between two mass storage devices without using a computer :). Here is example of a product for doing this http://www.pricegrabber.com/search_getprod.php/masterid=3248955/.
-
There's currently no way to get a WMA onto any of the software codec players without hooking them up to a computer.
There is a way how to transfer files between two mass storage devices without using a computer :). Here is example of a product for doing this http://www.pricegrabber.com/search_getprod.php/masterid=3248955/.
I think the point was that we don't have a wma decoder in rockbox, and thus to play wma files you must first convert them into something else using a computer. It wasn't physically having the file on the disk.
-
For those that may not know, there is work currently being done on WMA decoding: http://www.rockbox.org/tracker/task/4984
-
I am resurrecting this thread to sincerely thank JDGordon for the test_codec plugin.
I wish to link to the flyspray feature request http://www.rockbox.org/tracker/task/6152 that inspired this thread.
I am still of the opinion that this will be useful to us in the future. Output to WAV is a great feature!
-
I am resurrecting this thread to sincerely thank JDGordon for the test_codec plugin.
Except that it was linuxstb's work, I think. ;)
-
Ooops! I got confused with the recording path patch.
Yes, yes! Thanks to Dave Chapman! (so sorry) :-\
JDGordon still cool as well though! ;D