N3: An open source portable audio player

[linuxstb]

I realize Rockbox does not use Linux, my point was that we already have a bootstrapped software environment for the hardware, including source. Surely, that would help a Rockbox port?

Of course.

It just seems odd to design an "open source portable audio player" around a CPU with no public documentation...  

As I think Bagder said elsewhere, whatever hardware you choose, someone, somewhere, sometime will port Rockbox to it.  However, experience has shown that Rockbox running on such targets never performs as well as ones where the documentation is freely available.

Having Linux source available will be helpful, but it's not the same as having datasheets.

[may1937]

How would using a CompactFlash drive for storage compare? Still flash, they can offload the cost of large storage on the purchaser, and more flexible for the user?

Yes, I was thinking along those lines, possibly include an internal 4GB CF, and have an SD/MS slot for user expansion. I certainly wouldn't call that kind of storage "tiny". Certainly not great, but in terms of development cost it may be a reasonable trade off.

I don't think 4/8 GB of storage would appeal to the "audiophile type crowd".

I agree - having such a tiny amount of storage would make this extremely un-interesting for me.

But seeing the reaction here (and there is some of the same in our community), it looks like we need to take a more serious look at including a hard drive from the start.

[may1937]

Of course.

It just seems odd to design an "open source portable audio player" around a CPU with no public documentation...  

As I think Bagder said elsewhere, whatever hardware you choose, someone, somewhere, sometime will port Rockbox to it.  However, experience has shown that Rockbox running on such targets never performs as well as ones where the documentation is freely available.

Having Linux source available will be helpful, but it's not the same as having datasheets.

My thought has been if we can do a good enough job commenting the code, the need for datasheets will be minimal. I know, it is not an ideal situation. We are trying to work with what we have.

Datasheets are available, by the way. Myself and several other community members have signed an NDA with Neuros to get them, with the explicit provision we will be writing open source code based on them.

[Bagder]

Datasheets are available, by the way. Myself and several other community members have signed an NDA with Neuros to get them, with the explicit provision we will be writing open source code based on them.

NDAs limit the number of developers quite drasticly. Some developers won't be able to sign them and some won't want to. It is just so non open source'ish.

Let me also remind you about the situation we have with this dm320 series: no open source codec and in fact hardly any open source at all is written to take advantage of a CPU/DSP architecture. Not even any of the video codecs. So, to take advantage of that combo you have to resort to the style almost every Linux-using commercial portable player do (including Neuros): use binary drivers and modules that aren't open source, so that you can include proprietary codecs that use the DSP accordingly.

Rockbox does not allow such binary-driver work-arounds and my guess is that none or just very little DSP code will ever be written open source for this target. That leaves us with a CPU+DSP combo where the DSP part is mostly annoying and the CPU parts is far less powerful than say a Toshiba Gigabeat... Possibly it will also not reach the best possible run-time either.

But then, I believe the ARM9 parts of a dm320 is powerful enough to drive Rockbox and all its audio codecs perfectly fine, and I think it is enough to also do a fair job at video playback so if dm320 is the final choice I expect Rockbox to run fine on it. The fact that we have other pending dm320 targets that can take advantage of such work is also interesting to me.

[GodEater]

I don't think 4/8 GB of storage would appeal to the "audiophile type crowd".

I agree - having such a tiny amount of storage would make this extremely un-interesting for me.

But seeing the reaction here (and there is some of the same in our community), it looks like we need to take a more serious look at including a hard drive from the start.

I think you have to bear in mind that most "audiophile" types prefer their lossless codecs - 8GB isn't going to give you a lot of storage space for your music if you mostly use FLAC. Now I personally don't call myself an audiophile - I have tin ears. I just happen to have an enormous music collection - 8GB is less than a sixth of the space I need to carry it round with me - and I'm not interested enough in swapping my music between the DAP and my PC to keep only a subset of it on me at any one time. Just my personal opinion though.

[AlexP]

I too would require way more than 8 Gb - I currently have two targets - a gigabeat F40 (40 Gb) and a H140 with a 60 Gb disk in it and neither are big enough for my music collection which is just in MP3 and OGG.  If I were to go lossless...

I would love a decent modern player with a 2.5 disk - I know it is bigger, but I could carry all my music around with me.

Similarly to GodEater, I can't be bothered swapping music on and off a DAP - until we start getting 60+ Gb of flash, flash storage is a non-starter.

[may1937]

NDAs limit the number of developers quite drasticly. Some developers won't be able to sign them and some won't want to. It is just so non open source'ish.

Let me also remind you about the situation we have with this dm320 series: no open source codec and in fact hardly any open source at all is written to take advantage of a CPU/DSP architecture. Not even any of the video codecs. So, to take advantage of that combo you have to resort to the style almost every Linux-using commercial portable player do (including Neuros): use binary drivers and modules that aren't open source, so that you can include proprietary codecs that use the DSP accordingly.

Rockbox does not allow such binary-driver work-arounds and my guess is that none or just very little DSP code will ever be written open source for this target. That leaves us with a CPU+DSP combo where the DSP part is mostly annoying and the CPU parts is far less powerful than say a Toshiba Gigabeat... Possibly it will also not reach the best possible run-time either.

But then, I believe the ARM9 parts of a dm320 is powerful enough to drive Rockbox and all its audio codecs perfectly fine, and I think it is enough to also do a fair job at video playback so if dm320 is the final choice I expect Rockbox to run fine on it. The fact that we have other pending dm320 targets that can take advantage of such work is also interesting to me.

Thanks for bringing this up. It has been discussed ad nauseum within the Neuros community, but it is certainly worth highlighting here to bring others up to speed.

Neuros' current dm320 product does use closed source codecs, as described above. Even those closed codecs do all audio processing on the ARM side. I have run both Tremor and MAD, using closed source pcm output, and was getting 30-40% CPU usage under Linux. We have some c54x code from the old N2 which could potentially run Tremor. I'm not sure if the MP3 code for N2 was open source or not. But certainly to get started, we would not need to worry about running codecs on the DSP.

However, it is the DSP portion of the chip which has the serial ports required to interface with the DACs. So, even getting straight pcm audio to play will require some code running on the DSP. The good news in all this is that I'm currently mentoring a Google Summer of Code project to provide a bridge enabling open source code to run on the DSP. Things are moving along well, we have code running on the DSP, and are currently evaluating what the protocol should look like between the two CPUs. As this project matures, I will be writing a DAC driver for the DSP. So the situation is grim now, but we do have a project in motion to solve this problem.

Supporting video on the N3 was not on my radar at all; I'm not sure how the rest of our community feels about it. The bridge project does not stand a chance of interfacing with the closed source codecs, so any video codecs would have to be written or ported from scratch, not a very likely situation considering the cost of TI's compiler.

[saratoga]

If you're not interested in supporting video, and plan to run all the code on the ARM core, what use is the DSP?  Unless you have some justification for the DSP core being there, a more sensible option would be to pick a plain ARM core.

The Samsung cores in particular are attractive.  They're much faster then the TI ones, and are completely open (all parts are documented).

[markun]

However, it is the DSP portion of the chip which has the serial ports required to interface with the DACs. So, even getting straight pcm audio to play will require some code running on the DSP. The good news in all this is that I'm currently mentoring a Google Summer of Code project to provide a bridge enabling open source code to run on the DSP. Things are moving along well, we have code running on the DSP, and are currently evaluating what the protocol should look like between the two CPUs. As this project matures, I will be writing a DAC driver for the DSP. So the situation is grim now, but we do have a project in motion to solve this problem.

The archopen.org guys have audio playback as well, you might want to talk to them about it.

[Bagder]

The archopen.org guys have audio playback as well, you might want to talk to them about it.

I've talked to (some of) them in the past.

They managed by doing reverse engineering of the DSP code in existing dm320-based firmwares, and they also rely heavily on the leaked dm320 docs... I assume we can get sound code working on an Neuros dm320-based device based on their code.

It doesn't make it a better arch in my eyes, it just shows that we can always overcome whatever obstacles they put in our way. It just seems a pity that someone one actively tries to make an open source player take this route  - again.

And may1937: Rockbox already plays mpeg2 movies perfectly fine so you have to make an effort to not support movie-playing on a new Rockboxable device...

[may1937]

The Samsung cores in particular are attractive.  They're much faster then the TI ones, and are completely open (all parts are documented).

It doesn't make it a better arch in my eyes, it just shows that we can always overcome whatever obstacles they put in our way. It just seems a pity that someone one actively tries to make an open source player take this route  - again.

Maybe I am wrong about the amount of effort required to switch CPUs, but as I have tried to express before, we do not have a hardware engineer. This means we will likely end up contracting with one, and I have not even begun looking into that. I imagine the rates would be somewhere in the $100-200/hour range. Between adding the DACs, ADCs, whatever other audio circuitry is needed, an FM transmitter, now possibly a hard drive, SPDIF, shrinking the design, getting the thing powered from a battery (including a recharge circuit) and whatever else needs to be done, we already have a substantial amount of hardware work that needs doing. Even after the design is completed, we will also likely need their time for board bring-up. If they can complete this work in a man month at US$150/hour, we are looking at a bill of around US$24,000. This is for a community project, which, as of yet, does not have any funding. Unless they can integrate a new CPU in a man day or two, which I highly doubt, I am not seeing another option besides sticking with dm320. I acknowledge, even agree, that dm320 is not the ideal candidate for an open source player.

Am I missing something here? If anyone has a different take on this situation, I would be very interested to hear it.

And may1937: Rockbox already plays mpeg2 movies perfectly fine so you have to make an effort to not support movie-playing on a new Rockboxable device...

My comment about video was based on me and those I have talked to in our community not being interested in video on the N3. Its great that Rockbox supports it, and I didn't mean we should cut the feature, just that it was not a target feature for the project at this point.

[johnson4]

Having the ability to use a 2.5" drive is a start. Yes it makes it a bit bigger, but if it offers expandability that's very valuable to the kind of people who are interested in open source.

As I see it, Rockbox is already on it's way to having a 2.5'' drive DAP. Once USBOTG is supported, all that you'll need is
-the HD obviously
-a $25 2.5" USB HD Enclosure,
-a little solder and a male USB connector
-some creative mods to the Enclosure housing.
 Im imagining a expansion sleeve (like it iPAQ PDAs have) for my Gigabeat now.
 

[GodEater]

Your plan sort of implies you're going to be carting your original DAP *and* an external hard drive around with you. No thanks

[johnson4]

ya not very sexy, but size doesn't seem to be the main consern to those who wish to have 300GB in tow

[GodEater]

I'd *love* 300GB of DAP storage space - but just not like that!