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

[mzandrew]

Matt i appreciate your efforts on the TWiki, but i think the tone in the writing should not contain anything which indicates that one person is building it single handedly.

Casainho, There is nothing such as "my" schematic or "your" schematic. The beauty of working together is to have "our" schematic. it doesn't matter who does the drawing. A good schematic is a result of many inputs from different people.

I've changed the instances of "I" to "we" on the wiki to be more diplomatic.  And I changed "main designer profile" to "developer profiles."

However, _I_ will be drawing the schematic and drawing the parts and producing the layout and fabricating the board out of my own pocket and assembling the board out of samples I requested and parts that I bought.  Just to be fair.

Of course, what spark means is that the basic design itself wasn't mine alone, and that's true.  I've already gotten a lot of help from others.  For starters, I read this post http://forums.rockbox.org/index.php?topic=6751.msg52891#msg52891 about 6 months ago and that's shaped what I want to do almost entirely.  Also, I checked out the datasheet for the audio codec that cashainho and others decided on for the regular RockBoxPrototype and it seems like an excellent choice, so I borrowed it.

Everyone who's contributed or plans to contribute should add their names to the "developer profiles" section at the end of the twiki page in question:
http://www.rockbox.org/twiki/bin/view/Main/RockboxPlayerPrototypeB

[spark]

mzandrew, keep uploading parts of the schematic as you prepare them so that we can learn and suggest.
keep up the good work!!!

[mzandrew]

I have a couple of questions for everyone that I've asked on IRC and either gotten an answer but wanted to discuss here or didn't get any answer.

First, to solve the problem of not using mobile sdram but still keeping the not-in-use power extremely low, I think that powering down the dc-dc converters that power most everything on the board (except the arm9 wakeup functionality) is a good solution.  The problem is that this is the same as turning it off.  Rockbox would have to boot up again as soon as someone presses a button.  That's fine, but if you pause your player and wait a while and the device puts itself in this low-power mode and then you hit unpause/play, you naturally expect the music to start right back up again.

From IRC, scorche implied that if you pause rockbox and then shut it down, rockbox would save where it was in the song that's playing so that when you booted back up, it would be ready to start from where it left off.  Also that Rockbox would boot up quickly enough (on a 180MHz arm9, which is approximately 2x as fast as the single used core on a sansa e200 target) so that the user wouldn't mind or even notice this happening.  Alas, my hand-me-down broken ipod first gen broke before I ever learned of Rockbox, so I've never gotten to play with it except in the ui simulator, otherwise I could probably answer some of these questions myself.

My question to this forum is first, whether I got the right message from what scorche told me, and second, when Rockbox boots up, can it be set to a mode where it won't be obvious that's it's booting back up before starting to play the music again? (I know we COULD program it to do that, but how much of a code change would this require?)  To say it another way, do any of the other targets do what I'm intending (to power off the ram so that a reboot would be required)?

[spark]

I can visualize the following scenarios.

[Player is in Play mode and user presses PLAY/PAUSE button to pause]

This mode is used when user wants to pause the player for a very short time, maybe to attend a phone call or something. After a while, when he presses PLAY, he needs to have instant playback.
To implement this we should not power down the player. All we need to do is put the CPU & peripherals in low power mode and keep the SDRAM in self-refresh. (so that it's contents are preserved)
(in case the user forgets to press play for a long time, then we will have to power down the player completely as mzandrew suggested above. now the user will not mind a few seconds for startup)

[Player is in Play mode and user presses STOP/OFF button]

We need to either shut off DC/DC completely. The next boot will be a clean boot. Alternately we can save only the player state (song and position) and resume after a clean boot. (not a priority). I don't know how it is done in Rockbox?

[Player is switched OFF and USB is plugged]

Device must power up, enumerate on USB, ask for 500mA current, and start charging. It can then enter idle mode and wake up on host requests.

[casainho]

About saving power, I don't know. I can't help.

I would suggest to have a message on TWiki page for people discuss here and not on TWiki page, to have it clean. Matt, can you add the link for this message and remove comments on page?

touch/click wheel
controller for proximity/touch sensing -> not good choice for a recorder/audio player. People must be able to feel the keys, to have it on pocket and put play/pause, volume, without the need to look for the display!! Also I think that it's very important for visual impaired users of RB!

[AlexP]

Rockbox will resume the currently playing song after booting if so desired, and also supports bookmarks.  You can set it to resume automatically on startup, or go to the menu, or filebrowser, or database (plus more) and then resume manually if you like by pressing play. All of our current players shut down after a user specified time out (with the exception of the 1st and 2nd gen iPods that cannot shutdown).  Rockbox does not currently support a sleep mode like you are talking about.

[casainho]

Rockbox will resume the currently playing song after booting if so desired, and also supports bookmarks.

I think RB write some file on FAT32 file system, for recording this information, for be able to resume.

Rockbox does not currently support a sleep mode like you are talking about.

Information I gathered on TWiki pages and source code:

Information about RB API for power modes, read here:
http://www.rockbox.org/twiki/bin/view/Main/DynamicCPUFrequency

Looks like the RB have 3 power modes of operation: Idle, Normal and Boost - example frequencies on PortalPlayer(ARM based), for each mode: 24MHz, 30MHz and 80MHz. Also PortalPlayer are dual ARM core but since I know, RB just uses one core(??).

More information about the driver for PortalPlayer, where we can see the function, static void pp_set_cpu_frequency(long frequency), to set this 3 different frequencies, here - file system-pp502x.c:
http://svn.rockbox.org/viewvc.cgi/trunk/firmware/target/arm/system-pp502x.c?revision=&view=markup

In the same file, we can find the function void system_reboot(void) - for reboot, as BigBambi mention, I think.


Interesting working on hardware level, we can now see that we can boost power save with a good hardware, planned design - the good points of doing our own hardware and have full information about it!!

[spark]

mzandrew, why do we need 2 SD card slots in the protoB?
http://www.rockbox.org/twiki/bin/view/Main/RockboxPlayerPrototypeB

isn't 1 SD card slot sufficient? we can instead focus on making it as compact as possible.
Instead, 1 SD slot and 1 on-board NAND flash chip would be better option than 2 SD slots.
you can store the songs in as many cards as you want and keep them in your pocket.

Are you thinking of a card to card copy application for the player?

NAND is optional. but if we use NAND, we can do away with the SPI flash.
using NAND will also make Linux workable, thus increasing the usability of the hardware platform.

Alternatively we can have both SPI & NAND flash and 1 SD card. with this way you can ignore soldering of the NAND chip and use SPI. Those interested in NAND can solder it if they want.

[casainho]

Since Matt is working in RockboxPlayerPrototypeB, and is choosing components that he wants, I would like to start discussion for functionalities of the RockboxPlayerV1.

After Matt end the RockboxPlayerPrototypeB on mid-March 2008, we can then start working on software for RockboxPlayerPrototypeB and working on hardware for RockboxPlayerV1. When finished the software on PrototypeB, we can them go to Olimex(or others) asking help for making the V1, showing PrototypeB working.

On TWiki page of the V1 - Features:

    * Outputs: Stereo Headphone
Since the objective is to make a good recorder/audio player, I would put 2 outputs for stereo headphones! There was an Iriver player that had this functionality. I could go on train with girlfriend or any friend and being listen, showing music to them :-) - The main objective of this player, IMO, is for music fans!! and that implies easy listen and share!! - what do guys think?

    * Inputs:
          * Stereo Line-In for High Quality recording.
          * Mono integrated Mic for voice recording.
Ok, High Quality recording is a must!! There are expensive players just for professionals recording!!!

    * Internal Storage: 512MB or 1GB
512MB or 1GB is not much memory, I would prefer just to have SD card for memory. 512MB or 1GB would be like a "dead memory" in the player If will not use it because of low amount of space. SD cards have 8GB now - and If I want even more than 8GB, I would go for the harddrive option :-)

    * Memory Expansion Slots: 1 SD card
:-)

    * Hard Disk Drive Connector: 1 ZIF connector for connecting an optional 1.8"/2.5" Hard Disk Drive.
Very good option!

    * Display: TFT/OLED display. Size: ? Resolution: ?
As an audio player / recorder centric, It does not need a big display! - I imagine just a large display for who wants to monitor what is recording, like showing sound waves or something like that.

    * Connectivity: USB (Mass storage device with multiple mediums)
I also would like to have some wireless to connect to another devices, mainly to share music! - PCs, PDAs, mobile phones, etc, have internet where we can get music like on www.Jamendo.com, after we could copy that music to the player by wireless. The player should not have internet connection, but could connect to some other device that do that.
Bluetooth looks interesting for me because a lot of devices have it!! although is slow but can be ok for sharing musics, also for wireless headphones!!

    * Power: Li-Ion Battery
The actual main technology :-) - I just don't like to not be able to swap batteries when in travel, as I do with NiMh. 

    * Charger: 5V DC adapter input or USB
Ok.

    * Navigation Controls:
Not any touch sensing! I know that actual tendency of this gadgets go to them, but we must do what we really need. As an audio player / recorder, I want to have it on my pocket and put play/pause, forward/backward, volume up/down, without looking at the screen or without looking at any touch pad! We must feels in fingers the keys. This will also be important for visual impaired people that uses RB :-)

I am think in putting on TWiki a list of desirable things, ideas and a list with choosed ones with justifications.

[mzandrew]

From the wiki page,

Rockbox will be stored in SPI flash and be copied to ram upon bootup.
   * Anyone with knowledge of the inner workings of Rockbox know if this is feasable?  We can always slightly modify rockbox so that it saves configuration changes (or possibly a database, but that should probably be stored on the SD card in question instead) to the serial flash after a config change.  The point is that there's no file system on the spi flash, so will Rockbox work?  We could have the Rockbox bootloader at the start of the serial flash and another binary chunk that's an image of a FAT filesystem that contains the rest of Rockbox (besides RoLo) and then just pretend that the block of RAM that's a copy of this image is equivalent to the mass storage device that the Rockbox files would normally be served from.  Easy / difficult to implement this way?

comments, anyone?  I need to have this one resolved before I can continue with the design as it is now.

Okay, so one potential problem with this is that my .rockbox dir for the uisimulator is about 35 megabytes, which is greater than the available ram on the player...

[linuxstb]

Matt,

I'm confused about the license you've chosen for the RockboxPlayerPrototypeB hardware design -  the creative commons by-nc-sa 3.0

I commented as follows on the wiki page:

"As I'm sure you know, Rockbox is GPL'd, a license which allows commercial use, and for good reasons. I don't think the fact that a commercial company may not donate cash back to the project is a good reason to prevent them from using (and potentially contributing) to your design. I would have thought that the fact that users would be able to buy a player at a cheaper price, and the possibility of the contribution of professional engineers would be of greater benefit."

And then you added a comment saying that you're seeking to make money out of this project.

If the license is non-commercial, but you then want to make money from it yourself, then you are of course free to do so if the design is 100% your own (the CC license you've chosen just dictates how other people can use your work).

IANAL, but it seems to me that once other people start contributing to the design, then you are no longer the sole copyright owner, and (because the license is non-commercial), you will be unable to use those contributions in your own money-making endeavours.

This thread is for discussion of a Free/Open hardware audio player, and IMO a non-commercial license doesn't meet those goals.

casainho - have you chosen a license for your hardware design?

[casainho]

From the wiki page,

Rockbox will be stored in SPI flash and be copied to ram upon bootup.
   * Anyone with knowledge of the inner workings of Rockbox know if this is feasable?  We can always slightly modify rockbox so that it saves configuration changes (or possibly a database, but that should probably be stored on the SD card in question instead) to the serial flash after a config change.  The point is that there's no file system on the spi flash, so will Rockbox work?  We could have the Rockbox bootloader at the start of the serial flash and another binary chunk that's an image of a FAT filesystem that contains the rest of Rockbox (besides RoLo) and then just pretend that the block of RAM that's a copy of this image is equivalent to the mass storage device that the Rockbox files would normally be served from.  Easy / difficult to implement this way?

comments, anyone?  I need to have this one resolved before I can continue with the design as it is now.

Okay, so one potential problem with this is that my .rockbox dir for the uisimulator is about 35 megabytes, which is greater than the available ram on the player...

Why not use a 16MB flash instead of that SPI flash? - like Sansa E200, just one flash IC with one partition for RB bootloader and other with FAT32 for RB and audio files, etc ?? - Would be good for coding and looks like a traditional approach in this kind of hardware.

casainho - have you chosen a license for your hardware design?

Matt have a schedule to make RockboxPlayerPrototypeB and he is not discussing desired functionalities. He also will use Eagle, not Free Software. I don't mind with the license of this PrototypeB, we will need to work on others versions and on that time, we will have time to discuss desired features and licenses. Now, I prefer to focus on helping Matt doing this PrototypeB and later think on that kind of things.

But It's nice having this discussion, it's important! - I know now more opinions about his subject :-)

[cool_walking_]

I would put 2 outputs for stereo headphones!

I think this could possibly be a waste of space on the player, and people who want this could just get a splitter.  However if it doesn't take up too much space it would be fine.

[casainho]

I tried using Kicad. The schematics tool is good but you can't have more than one sheet. The pcb editor is ok but there are many limitations. you cannot undo any operation and not all operations have keyboard shortcuts.

I think Kicad can have a few sheets, we can read in manual: Total number of sheets and sheet number are automatically updated.

Spark, yesterday Matt said on IRC: I *am* planning to be the sole designer of the circuit board, at least for this first version. After all, Matt wanted to design and build a portable mp3/ogg/flac/etc player that would run rockbox, for is school project.

We must work in a future version with Kicad or GEDA, and not the Eagle. 

[Bagder]

Why not use a 16MB flash instead of that SPI flash? - like Sansa E200, just one flash IC with one partition for RB bootloader and other with FAT32 for RB and audio files, etc ?? - Would be good for coding and looks like a traditional approach in this kind of hardware.

SPI would be the interface while 16MB is a size. There's nothing preventing an SPI flash to be 16MB. 16 MB probably implies NOR I'd say.

The Sansa e200 you use as comparison has both internal NOR and NAND, so I'm not sure this clarifies anything...