Rockbox Player - Project to design and build a Free/Open hardware audio player

[Llorean]

No offense, but saying "I just want to ban any more grumbles about the LCD" doesn't magically make the LCD a good one. We suggested from the beginning that he consider a larger one.

The problem is that he's chosen an LCD that not only looks bad in comparison to more modern LCDs, but is quite low resolution and makes several of the features (the option to choose large fonts to help poor eyesight, the option to theme the UI, games and video playback) of Rockbox difficult or pointless on this player.

There are thousands of LCD screens out there. But he was uninterested in the suggested minimum requirements. The reasoning he gave originally wasn't "this one is easiest to learn." It was "I think this player should only be for music."

If you're making something that you intend to sell, you need to consider not just what you want it to do, but what things you can add that greatly increase the potential user base for the smallest costs. His prototype, for example, has a significant amount more RAM than a flash based player needs. If it's still 64MB as the page I last read said, it's actually more than an HD based player needs too. Money could be saved there.

No amount of "just getting on with it" changes the fact that you intend to market the player, and so should consider feedback on what seems "bad" about it from potential customers who could be giving you money in the future, rather than telling them "forget it guys, if you aren't going to tell me what part to use instead, I don't want your money."

It's not a case of simple grumbling about the screen and not offering alternatives. It's a case of a product being designed "to run Rockbox" that is intentionally attempting to cripple the functionality and benefits of having Rockbox on a player.

Not to mention, it costs money and time to swap out parts and redesign. Whether or not the LCD is to be replaced should be decided at the earliest possible moment, so that integration of it can happen sooner rather than possibly delaying the project at the later stages. Especially if people are already considering production of the player, and may not be aware the impact the LCD may have on what Rockbox can really offer.

[casainho]

Here is one video, showing the firmware running. Also is show the debug session and bootloader.

http://blip.tv/file/get/Jpcasainho-RockboxPlayerLittlePrototype032008556.ogg

[notlistening]

I take all your points and agree with what your saying. I have come in half way through and started helping out, so i hold my hands up and say sorry.

The most important point that has been raised here is that we are making a prototype of something that people will not want. That is clear from the lack of support given at the moment form the rockbox core.

Can we redefine what is wanted and how. This should come from rockbox without any other considerations and comes from the guys who know their stuff. A crucial point to the sucess of this project is your support and backing. So a discussion on the hardware requirements of a player that incorportates all of the rockbox strengths is essential. As you have said it is important to start off the right way and it is very clear that  we have not done that. So I think that we should listen very carefully to what you have to say. Please all who have something to say please say it.

I think for the current project there is no harm in moving forward as proof of concept, as a demo unit and so i can learn and be semi competent when it comes to taking on the next stage.

I take your point on and think that listening to the hardware and software guys to come up with something special that your going to be proud to own will make the difference.

If we can get something on paper that sounds good and that the majority of people agree on then we can begin to move forward.

Is what we have so far unrecoverable? Are the guts of the current prototype not suitable? If we are aiming to create our own unit can the memory sizes etc not be customised to out needs in the future?

I think that it is also important to realise my reasons for doing this project. I am registered blind, i hate the face that any specialist unit for the blind is stupidly expensive. I do not like apple, I love what rockbox has to offer. I want the disabled to be able to buy a rockbox player, rather than have to buy another players and all the problems that come along with adding rockbox to it. 

Tom   

[Rockbox]

Once you get around to selling or distributing the player, we think it would make sense if the player had a name that distinguished it from the Rockbox project as something supplied and created by others. An idea could be to choose a name like "The Little Player, running Rockbox." This would help the consumer know that it's not something provided by the Rockbox project itself, and that problems they have relating to the manufacturing and hardware should be taken to the provider and not us.

As a project we don't want to seem to endorse any one player as "the" home brew player. The name "The Rockbox Player" could create confusion around whether the player belongs to Rockbox or is simply a player that runs Rockbox. We'd ask that you name it something that doesn't have the word "Rockbox" as part of the actual player's name, so that it's clear to people that it's a separate project that runs Rockbox as a primary operating system rather than as a product created by the Rockbox project. We'd like to keep Rockbox itself as a software project that avoids endorsing any specific player or players as "the" Rockbox player. Doing this could allow you to make it clear this is a separate project (possibly of wider interest to others since other firmwares could be run on it or developed for it) that is capable of running Rockbox well, rather than being an extension of Rockbox itself.


-The Rockbox Steering Board

[casainho]

Once you get around to selling or distributing the player, we think it would make sense if the player had a name that distinguished it from the Rockbox project as something supplied and created by others. An idea could be to choose a name like "The Little Player, running Rockbox." This would help the consumer know that it's not something provided by the Rockbox project itself, and that problems they have relating to the manufacturing and hardware should be taken to the provider and not us.

As a project we don't want to seem to endorse any one player as "the" home brew player. The name "The Rockbox Player" could create confusion around whether the player belongs to Rockbox or is simply a player that runs Rockbox. We'd ask that you name it something that doesn't have the word "Rockbox" as part of the actual player's name, so that it's clear to people that it's a separate project that runs Rockbox as a primary operating system rather than as a product created by the Rockbox project. We'd like to keep Rockbox itself as a software project that avoids endorsing any specific player or players as "the" Rockbox player. Doing this could allow you to make it clear this is a separate project (possibly of wider interest to others since other firmwares could be run on it or developed for it) that is capable of running Rockbox well, rather than being an extension of Rockbox itself.


-The Rockbox Steering Board

Ok :-) -- we are far from selling and distribute it. Right now I just want to finish the audio to have it working and them I will rename all the files on the patch, before commit it to Rockbox tracker.

I remember that some old developer told about the "Orpheus" name, as it were one possibility for actual Rockbox. I will tell to another developers and we will choose a new name.

[gevaerts]

I remember that some old developer told about the "Orpheus" name, as it were one possibility for actual Rockbox. I will tell to another developers and we will choose a new name.

The Orpheus name may be a bad idea : there is already open source media player software with that name: http://thekonst.net/orpheus/

[AlexJCantos]

Hi,

I don't want to sound rude, but dkamin, I can't agree more with Casainho:

I think you should talk with us at our discussion group, all other developers are there:
http://groups.google.com/group/rockboxplayer

Yes, you should definitely talk to the rest of us in the group, because this is a shared effort not an every-man-for-himself development. So it'd be nice if you could follow the rules we have, which obviously include asking the rest of the people what do we think if you did this or that.

Yes, it's ok. But don't forget JTAG port!!! Please, no micro-SD, just normal SD Card!! We have question to discuss here -- micro-SD don't have SPI bus, just SD Bus which mean we will need to pay royalties to use it :-( -- actual code is working for SD Card using SPI bus.

Again please ask, not just do whatever you think.

I want to ask some questions:
- what is your motivation?
- in what can you help on the project?
- what you do professionally? do you have some projects yours that we can see?
- will you share the schematic and board layout with a Open Source license?

Yes, you should have started introducing yourself and saying how you can help and asking for what might need doing.

Don't take me wrong, dkamin, I'm happy there's another hardware guy around but I don't want you to take completely over the hardware development because there's more people who want to take part and who have been here for longer, like me, for example.

Thanks,
Alex

[agdurrette]

hay would mined explain how you would make an mp3 player cus i would like to build one myself.


Thanks.

[gevaerts]

Hi,

I don't want to sound rude, but dkamin, I can't agree more with Casainho:

I think you should talk with us at our discussion group, all other developers are there:
http://groups.google.com/group/rockboxplayer

Yes, you should definitely talk to the rest of us in the group, because this is a shared effort not an every-man-for-himself development. So it'd be nice if you could follow the rules we have, which obviously include asking the rest of the people what do we think if you did this or that.

Yes, it's ok. But don't forget JTAG port!!! Please, no micro-SD, just normal SD Card!! We have question to discuss here -- micro-SD don't have SPI bus, just SD Bus which mean we will need to pay royalties to use it :-( -- actual code is working for SD Card using SPI bus.

Again please ask, not just do whatever you think.

I want to ask some questions:
- what is your motivation?
- in what can you help on the project?
- what you do professionally? do you have some projects yours that we can see?
- will you share the schematic and board layout with a Open Source license?

Yes, you should have started introducing yourself and saying how you can help and asking for what might need doing.

Don't take me wrong, dkamin, I'm happy there's another hardware guy around but I don't want you to take completely over the hardware development because there's more people who want to take part and who have been here for longer, like me, for example.

Thanks,
Alex

This thread has been about various attempts at building a player. You weren't first here. Please don't think you're the one who should tell the world what to do or not to do, and try to make use of contructive criticism instead of dismissing it out of hand.

[Llorean]

Within the scope of your personal project you can do whatever you want. This thread is on the Rockbox forums, and although it's mostly about a specific player, it's

A) About the software porting, since this is the Rockbox forum, and not your hardware forum.
B) About any hardware designs, not just yours, because this is the Rockbox forum, and not your hardware forum.

As it is, we could be asking YOU to communicate more here about your software development work (patches on the tracker, and such). At the moment you've basically forked Rockbox and are working on it in your own space, rather than attempting to bring your software work back to the core project (we could probably have much of your in-progress code in SVN as long as you've been trying to follow the Rockbox coding styles, etc).

Instead, we aren't coming into your space and saying "Look guys, this belongs to us, you need to do it our way." So please, don't come into our space and tell interested contributors that this project belongs to you. You've released your designs under a free license. He's not obligated to make his version of the hardware your way, and he's not posting in your space anyway.

[casainho]

(...) As it is, we could be asking YOU to communicate more here about your software development work (patches on the tracker, and such). At the moment you've basically forked Rockbox and are working on it in your own space, rather than attempting to bring your software work back to the core project (we could probably have much of your in-progress code in SVN as long as you've been trying to follow the Rockbox coding styles, etc). (...)

Llorean, I think you were talking with Alex Cantos, however I can explain this part. I am the only one working on porting the firmware and as that, I don't have time nor knowledge to make patches. Well, I just learned recently to make patches and all this technologies were new to me at begin of the project.

I am trying to make patches and am I sharing them here, like the last one: 0001-20090310-rockbox_player-r19939.patch. Before, other Rockbox developers suggest me the same and even help doing the first patches.

And I put a patch one Rockbox tracker, however, I prefer now to focus on development and in the end (that is very near) I want to work on the patch for apply it again to the tracker.

We are few developers and we have very limited time and knowledge(as me). We have being getting a lot of help on Rockbox IRC channel and others Open Source projects (for schematics, code drivers, tutorials, etc) :-)

[bluebrother]

And I put a patch one Rockbox tracker, however, I prefer now to focus on development and in the end (that is very near) I want to work on the patch for apply it again to the tracker.

A single big patch that adds a complete new target is something that is almost impossible to review. Prepare to get asked breaking that monster-patch down into smaller pieces.

The (somewhat) original is to have multiple smaller changes that even might be possible to get applied now. Which would mean less work for you (no need to maintain that piece against svn) and easier review of your patches, thus better chances to get it into svn soon. Of course, that would require to follow the Rockbox coding guidelines ...

[casainho]

And I put a patch one Rockbox tracker, however, I prefer now to focus on development and in the end (that is very near) I want to work on the patch for apply it again to the tracker.

A single big patch that adds a complete new target is something that is almost impossible to review. Prepare to get asked breaking that monster-patch down into smaller pieces.

The (somewhat) original is to have multiple smaller changes that even might be possible to get applied now. Which would mean less work for you (no need to maintain that piece against svn) and easier review of your patches, thus better chances to get it into svn soon. Of course, that would require to follow the Rockbox coding guidelines ...

So I will start working on it. Thanks ;-)

I have question, bluebrother wrote on tracker, respective to the patch:

I still find this structure for registers weird and broken. IMO registers shouldn't get accessed through a structure pointer but directly as done in the rest of Rockbox (unless I was missing something here).

Can registers get accessed through a structure pointer on our patch? Because we have a header file that have all registers like that, and it works. Can we use that file or will we really need to re-write it?

For a first simple patch I was thinking in starting on the bootloader and initialize Rockbox kernel, and with that kernel flash a LED on the dev. board. What do you guys think? Would this be a good and simple patch for start?

[bluebrother]

Can registers get accessed through a structure pointer on our patch? Because we have a header file that have all registers like that, and it works. Can we use that file or will we really need to re-write it?

Simply put: it's not the way it's done in the rest of Rockbox. Having two completely different ways sounds like a bad idea to me. Also, I haven't seen this way of doing it much -- the usual way is by using register defines.

As an example, do you access registers like register->PORTA on AVRs? No. So why should you do on the SAM? 'Besides, how do you suppose will this work if register addresses aren't consecutive?

"We already have a header file" is not a reason, it's an excuse at best. IMO.

[casainho]

Can registers get accessed through a structure pointer on our patch? Because we have a header file that have all registers like that, and it works. Can we use that file or will we really need to re-write it?

Simply put: it's not the way it's done in the rest of Rockbox. Having two completely different ways sounds like a bad idea to me. Also, I haven't seen this way of doing it much -- the usual way is by using register defines.

As an example, do you access registers like register->PORTA on AVRs? No. So why should you do on the SAM? 'Besides, how do you suppose will this work if register addresses aren't consecutive?

"We already have a header file" is not a reason, it's an excuse at best. IMO.

Bluebrother, I asked on IRC, you weren't there but Bagder help me and told that we should not use that way of structs.

We will make that patch with just kernel_init(), with that "good" scheme for defines of registers and with new name of the project.

"We already have a header file" is not a reason, it's an excuse at best. IMO.

Not, it is the reason, and I bet that is the same reason many people use it, because that header files cames on Atmel AT91 Lib.