Support and General Use > Hardware

N3: An open source portable audio player

<< < (5/7) > >>

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:

--- Quote from: Bagder on June 18, 2007, 03:11:53 AM ---
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.

--- End quote ---

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:

--- Quote from: may1937 on June 18, 2007, 09:58:25 PM ---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.

--- End quote ---

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

Bagder:

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

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

Navigation

[0] Message Index

[#] Next page

[*] Previous page