Rockbox Technical Forums
Support and General Use => Audio Playback, Database and Playlists => Topic started by: ElEsido on December 28, 2009, 07:53:32 AM
-
Hi all
The request for support for high res audio without downsampling/bit truncating has kept coming up at regular intervals. However for various reasons this appears to be a low priority for the people with the technical knowledge and programming skills to actually do it.
Would anyone be willing to implement support for 24/96 (or higher) audio if he/she were sponsored for it or if a donation to rockbox were made?
I personally would be glad to throw up some $ if my H120 could send real 24/96 through the optical out. I'm confident that others would donate as well, but before opening threads in hifi-forums to look for other sponsors I wanted to check here if someone would dedicate some time and energy.
Best
ElEsido
-
Paying specific developers to implement certain features is probably frowned upon somewhat; we are all standing on each others' shoulders, it's not entirely fair to chuck money at the most recent person to touch a particular bit of code because that happened to be the change that made something you want work :)
Promising to donate is also unlikely to motivate people particularly, to be honest. Your best bet really is just to look for someone who can code who actually thinks it's a worthwhile feature.
-
It might also be worth pointing out that there's nothing to stop you from engaging whoever you like, and paying them whatever you like to grab the source from SVN and build you a version with exactly the features that you want.
But you might want to consider that even if you want to feed those changes back to the trunk, they aren't guaranteed to be accepted.
So if you need to take advantage of further features / bugfixes upstream, you might be faced with reapplying / rewriting the changes you've already arranged.
-
See this page in the wiki, and specifically the bit at the bottom for how we feel about bounties : http://www.rockbox.org/wiki/DonatedMoney
-
I personally would be glad to throw up some $ if my H120 could send real 24/96 through the optical out. I'm confident that others would donate as well, but before opening threads in hifi-forums to look for other sponsors I wanted to check here if someone would dedicate some time and energy.
I *think* we can do 20 bit via the optical out already. Rockbox itself does all audio processing in full 32 bit precision, so its just a matter of the optical out hardware supporting >16 bit. Though I'm not 100% sure, I don't have an H1x0.
For what its worth, lack of interesting in implementing 96k is largely due to it not being very desirable for an MP3 player. 96khz is very mildly useful for recording, mixing and editing, but for playback via optical is just a marketing gimmick, and one that would significantly reduce battery life at that.
But you might want to consider that even if you want to feed those changes back to the trunk, they aren't guaranteed to be accepted.
Unless very poorly implemented, I think people would be interested in seeing this code. Although you're right getting it accepted would mean that it would have to have minimal impact on performance in the typical 44.1kHz case, which could be difficult. I'm not sure how flexible the PCM and DSP code is about sampling rate.
-
See this page in the wiki, and specifically the bit at the bottom for how we feel about bounties : http://www.rockbox.org/wiki/DonatedMoney
Hi Godeater,
Actually, it was that new section that prompted me to comment. I can understand the intention and the consensus amongst core developers, but that leaves someone who would like a particular feature or change at something of a dead end.
I don't think I'm suggesting anything other than "you can fork the project, then it's up to you how you get your changes in". At least that was what I wanted to convey.
Cheers
Sean
-
Sure, and I agree with what you said :)
*I* just want to convey to end users how miffed our developers would likely feel if someone else were to profit from their hard work.
-
Sure, and I agree with what you said :)
*I* just want to convey to end users how miffed our developers would likely feel if someone else were to profit from their hard work.
Fair enough. I've just donated a modest amount on the strict understanding that it isn't used for any constructive purposes. Seems fair :)
-
*I* just want to convey to end users how miffed our developers would likely feel if someone else were to profit from their hard work.
Personally, I don't think I'd be too bothered about this. There's also GSoC as some sort of precedent.
Anyway, the main reason I don't think this sort of thing can work is just economic reality. Features tend to be a lot more involved than a casual observer might think, especially if the code is meant to be svn-ready. While I've not seen numbers in this particular thread, I'd say that the offered amounts I've seen in similar discussions are usually between 10 and 100 times too low.
edit: Basically as far as I'm concerned (and I suspect I'm not alone in this) I work on whatever I feel like. If you want me to work on something you specify, you pay normal hourly contractor rates.
-
Fair enough. I've just donated a modest amount on the strict understanding that it isn't used for any constructive purposes. Seems fair :)
Awesome - I promise to help drink some of it at the next Rockbox DevCon :)
-
*I* just want to convey to end users how miffed our developers would likely feel if someone else were to profit from their hard work.
I don't agree with the statement on the wiki. That wiki page seems to say that we expect users to follow a non-commercial license when in fact we are a GPL project. Putting additional restrictions on source, even if informal and unofficial, is clearly against the spirit of the GPL and probably not what we actually mean to say.
If someone is getting paid to work on Rockbox, good for them. When you release code under an open license like the GPL you're intentionally saying things like that are ok, and its ridiculous to complain if people decide to do what you've told them they can do.
Furthermore, Google has already paid a few of us for various rockbox features, and I haven't heard a single complaint, so I am skeptical that very many Rockbox developers have any serious problems with commercial involvement. I think that page should be clarified to explain the economic argument gevaerts just presented instead of whats there right now.
-
The GPL is certainly a double edged sword, regardless of your perspective.
Would it be fair to say "please don't solicit for paid work / bounties in these forums" and explain why?
That seems like an honourable restriction that can be definitively traced to a consensus of core developers / site maintainers, independently of the hundreds of direct / indirect contributors who may have a different view (or likely don't care much).
-
After more discussion about this on IRC, the wiki page will be changed again to reflect the fact that whilst it's possible to sponsor someone to provide a feature in Rockbox, it remains unrealistic unless you're willing to pay the actual going rate for a programmer's time.
It would also require the use of some sort of escrow service to guarantee that both parties were happy.
-
Hi all
Thanks for clearing this. It is clear that if a bounty is promised it would have to be kept in escrow by someone and be delivered when the goals are met.
Can anyone give a rough estimation on how much work *might* be spent to have rockbox output high-res audio, or would making such an estimation already take a lot of time? (IANTech person) And what are the going rates for dev jobs?
saratoga, you said that rockbox might be able to output 20bit through SPDIF. Someone tested this here with an iriver ( http://www.head-fi.org/forums/f15/who-has-iriver-h1xx-dac-amp-shows-bitrate-optical-spdif-input-465137/#post6294363]) and only got 16bit.
As for the desirability of high-res capabilities: There are some almost religious discussion on the audibility of the differences between CD quality and higher. I have a more geeky approach to this: High-rez files are available, disk space is no longer an issue for hard disk DAPs, there are external dacs and many DAPs have dac chips that decode 24/06, so why not do it. A DAP that outputs a good signal (over optical or for example usb audio) might even replace a home media tank.
-
Many things are built under the assumption of 16/44.1 audio. For example, the PCM buffer size only makes sense at that rate, and it's not dynamic. A solution that would allow playback of different sample rates depending on the song would probably require some significant rework to the playback engine.
Basically, even if you manage to hire a programmer for the job (either directly, or by way of bounty) it also needs to be done "well enough" to get into Rockbox. There are probably several workaround ways to get this job done, but it needs to have a minimal impact on the majority of users who'd have absolutely no use for it, so it needs to not cause degradation to the existing playback system. So whatever bounty you set should be for a fully working verrsion, not just a version that succeeds in a minimal sense (since that version will likely break the instant anything else playback related changes in Rockbox, and you're stuck having paid for the choice between upgrading your Rockbox install for improvements, or 24/96 playback, but never having both). It needs to be able to get into the main build if you wish to keep using it, most likely.
So they're going to need to do bug testing, interact with existing devs to find out what problems it may have and fix those, and then probably follow it in SVN for a while and make sure nothing unexpected pops up that gets it disabled again later.
So look at average programmer hourly rates, and assume quite a decent number of hours of work. Then realize these people most likely already have jobs, so you're trying to tempt them to spend their spare time on this rather than with their families and friends, so bump it up to something resembling overtime rates. Then overestimate because you don't want them quitting because they realized it looks like it's going to take longer than the money is worth.
That's just my suggestion, but basically the number is probably going to be a lot more than you're comfortable with if you want it to significantly alter the odds of something happening. Lower numbers of course still alter the odds, but probably not enough that something wouldn't happen anyway given enough time and patience.
-
Thanks Llorean!
-
saratoga, you said that rockbox might be able to output 20bit through SPDIF. Someone tested this here with an iriver ( http://www.head-fi.org/forums/f15/who-has-iriver-h1xx-dac-amp-shows-bitrate-optical-spdif-input-465137/#post6294363]) and only got 16bit.
Ok then my assumption would be that the hardware is not 20 bit capable.
I have a more geeky approach to this: High-rez files are available, disk space is no longer an issue for hard disk DAPs, there are external dacs and many DAPs have dac chips that decode 24/06, so why not do it.
96khz is very mildly useful for recording, mixing and editing, but for playback via optical is just a marketing gimmick, and one that would significantly reduce battery life at that.
Basically 'because its completely useless and has serious costs associated with it'.
That said supporting 48k makes a lot of sense and we don't do that, so eventually making the PCM system more independent of sampling rate would be a good idea.
-
Ok then my assumption would be that the hardware is not 20 bit capable.
The datasheet for the specific hardware used in the H100 is available from the Wiki. I've had a scan and as I read it the Codec hardware should be capable of outputting 24 bit at 96k, now there are plenty of other bits (like the output hardware and the ability of the CPU to shovel data at the codec fast enough) that may meant that the overall system may not be able to do it.
Not that I'm in the slightest bit interested in high res audio... Just intrigued by the discussion.
-
I seem to remember also being told that the upper limit factoring in everything was 20/44 or 20/48 (I can't remember which) for the h100 series.
-
The way things are now, everything gets converted to the native format of 44.1k/16 when it comes out of the DSP process. The internal format is frequency and bit depth flexible (set by the codec), so a lot of the code just doesn't care about it. It is *possible* to output other formats, but right now everything past the DSP (playback, PCM buffer, hardware drivers) expects the native format in order to function properly. With all that said, given hardware/driver that accepts other formats (and adequate RAM for buffering), I see nothing at first glance that would prevent a fairly trivial rewrite that would allow basic playback of deeper formats. Some things (crossfade comes to mind) would require a lot more RAM, but could be disabled or limited in function to allow the PCM buffer to expand adequately. You might also need to give up some DSP effects that may choke on high data rates. Some codecs might be capable of decoding high res audio correctly without significant modification but then cause underruns due to high data rates. It's hard to say for sure until it's tried.