Support and General Use > Audio Playback, Database and Playlists

Sponsoring a feature? (Support for HiRes-Audio, 24/96 or 24/192)

<< < (3/4) > >>

saratoga:

--- Quote from: GodEater on December 30, 2009, 09:51:02 AM ---*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.

--- End quote ---

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. 

seani:
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).

GodEater:
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.

ElEsido:
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.

Llorean:
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.

Navigation

[0] Message Index

[#] Next page

[*] Previous page