why porting ? kinda waste of time and just have fun only

[powerpan]

it's easy to make a good hardware using ROCKBOX, and with very good sound quality, why bother porting to different platform?

for fun, rockbox does not support network, and could not beat smart mobiles
for sound quality, a lot far away from professional equipment

why not just make it a professional combo software/hardware ?

[bluebrother]

I'm not sure what you're trying to discuss here.

There was a project some time back that tried to create a hardware to run Rockbox on. It seems to be dead these days. See http://sourceforge.net/projects/lyre/

Creating custom hardware to run Rockbox on is a lot of work, and it's almost impossible to get it into a mechanical state mass production hardware (i.e. cheapish players Rockbox supports like the Sandisk ones) reaches. Unless you're a company big enough to have the money getting things developed / produced / sold.

Besides, from my point of view Rockbox itself is fading -- people have smartphones these days that can do music playback good enough, so there is no need to carry another device around anymore. At least for most people.

[powerpan]

sonos is hot sale.
we have this kind of hardware. the reason to compare with smartphones is:
1. turnkey with good enough sound quality that could easily beat smartphones in seconds.
2. more format supported like SACD ISO/DFF, also DVDAUDIO ISO
3. could put more function in it like UPNP/AIRPLAY.
......

that's all.

rockbox is fading is because it doesn't  support network and could not be easily be DIY.

compared with open source 2440 project, it could not output high enough sound quality music cause it just supports 16bit output and hard for developed countries DIYers to make a specified hardware.

[[Saint]]

If anyone was even vaguely interested in monetizing Rockbox, it would've been done well over a decade ago (but...no one is stopping anyone else from forking the project and trying to do so).

This is a hobby project, nothing more.

The Lyre project failed, frankly, because it was ridiculous.

The idea is fine if one or two people want to spend a ridiculous amount of money printing their own PCBs and cases and end up with a product that costs easily twice as much (if not substantially more), and is three times bigger than, a mass produced offering from another company that is more suited to the task.

I'm not sure if you've noticed, but, people haven't stopped using digital audio players (yet), and as long as they keep doing so and the manufacturers of such players keep on making reasonable quality hardware with crappy firmware - Rockbox will always have a niche. In saying that, however, Rockbox was never really meant for the public. No effort goes into marketing it whatsoever. If people find it and use it, great. If they don't, that's fine too.


[Saint]

[saratoga]

There's already an enormously popular open source media player is with networking support that runs on low cost arm devices: Android.

If you want to port something to a network device you should absolutely use that. Adding network support to rockbox would make very little sense when you could just use Android.

[powerpan]

1. ROCK for android is fine, but not good for sound quality, nor open remote control interface
2. compared to other codecs, rockbox is the fastest one, a lot better then ffmpeg
3. yes, I agree specified hardware is kinda hard to make but what we could do if we could have this kind of hardware easily?
   (our company is making this but too expensive like Linn's play, but I am the hardware designer, so I could submit a good enough hardware platform easily)
    mess production is based on order. everything is possible, right?
4. raspberry pi could be wide spread, why not rockbox just work on it a little bit more?

professional player is not niche...

I mean if we could have a kinda of good platform, rockbox could be a lot better then ever!

[saratoga]

1. ROCK for android is fine, but not good for sound quality, nor open remote control interface

Its really no different than just running it as firmware.  And anyway, if you're talking about porting Android to a device, you can make any changes you want to it to accommodate a remote control interface or whatever.

2. compared to other codecs, rockbox is the fastest one, a lot better then ffmpeg

Yes of course, since we are optimized for ARM, but you can use our codecs on Android/linux too.

4. raspberry pi could be wide spread, why not rockbox just work on it a little bit more?

The raspberry pi has a pretty lousy DAC, its not really meant for audio.  You can use a USB DAC with it, but that is much easier in Android/linux.

Basically, its a matter of effort.  If you want to use things like networking you probably want a more complex operating system that uses things like virtual memory, preemptive multitasking, etc.  You could hack them to work in rockbox, but its much easier to just port rockbox as an application to something like Android or linux and use the underlying OS for these functions. 

[powerpan]

function of rockbox firmware is limited
linux+rockbox codec is ok, but one thing to notice, android only supports 16bit output like rockbox original fixed to 16bit.

and any comments to a professional audio playback machine like squeeze box /sonos something? please not that's professional ones, not just low cost players.

[saratoga]

linux+rockbox codec is ok, but one thing to notice, android only supports 16bit output like rockbox original fixed to 16bit.

If you're going to port Android to something, add support for a different bit depth while you're porting it.  Or don't even use the Android apis, just talk to the linux bits directly.

Or don't even bother since I don't know of anyone ever making a portable device with >16 effective bits.

[powerpan]

linux+rockbox codec is ok, but one thing to notice, android only supports 16bit output like rockbox original fixed to 16bit.

If you're going to port Android to something, add support for a different bit depth while you're porting it.  Or don't even use the Android apis, just talk to the linux bits directly.

Or don't even bother since I don't know of anyone ever making a portable device with >16 effective bits.

--------------most embedded linux limits to 16bit.

http://www.colorfly.net/product_index.html
C4

[saratoga]

linux+rockbox codec is ok, but one thing to notice, android only supports 16bit output like rockbox original fixed to 16bit.

If you're going to port Android to something, add support for a different bit depth while you're porting it.  Or don't even use the Android apis, just talk to the linux bits directly.

Or don't even bother since I don't know of anyone ever making a portable device with >16 effective bits.

--------------most embedded linux limits to 16bit.

Well yes, because its generally stupid to use 24 bit in embedded applications, so very few people do.  But if for some reason you want to, there is no technical reason you cannot. 

[powerpan]

linux+rockbox codec is ok, but one thing to notice, android only supports 16bit output like rockbox original fixed to 16bit.

If you're going to port Android to something, add support for a different bit depth while you're porting it.  Or don't even use the Android apis, just talk to the linux bits directly.

Or don't even bother since I don't know of anyone ever making a portable device with >16 effective bits.

--------------most embedded linux limits to 16bit.

Well yes, because its generally stupid to use 24 bit in embedded applications, so very few people do.  But if for some reason you want to, there is no technical reason you cannot.

but don't know why rockbox codec always missing LSBs
when our player plays DSD, it use 32bits output for DSD64/DSD128 playback

[saratoga]

but don't know why rockbox codec always missing LSBs
when our player plays DSD, it use 32bits output for DSD64/DSD128 playback

Which codec are you referring to?  Most of our decoders use 32 bit output and then truncate to 16 bit in the driver for efficiency reasons. 

[powerpan]

but don't know why rockbox codec always missing LSBs
when our player plays DSD, it use 32bits output for DSD64/DSD128 playback

Which codec are you referring to?  Most of our decoders use 32 bit output and then truncate to 16 bit in the driver for efficiency reasons.

most lossless codec like flac/ape/wavpack, including wav
and WAV's id3v2 doesn't support unicode

[saratoga]

but don't know why rockbox codec always missing LSBs
when our player plays DSD, it use 32bits output for DSD64/DSD128 playback

Which codec are you referring to?  Most of our decoders use 32 bit output and then truncate to 16 bit in the driver for efficiency reasons.

most lossless codec like flac/ape/wavpack, including wav
and WAV's id3v2 doesn't support unicode

You mean they don't decode or they decode with lower precision?