Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Open Source Firmware For iRiver players (Read 163264 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Open Source Firmware For iRiver players

Reply #25
Quote
Quote
Hi Emtee,
About Iriver i don't knowx if they are aware of the Rockbox project but it's not usefull to notify them and it could be a real BAD idea...
indeed there have been two others project of iHP alt firmwares  and the first one have been stopped by the authors due to iRiver pression... (that's what they said)

There is no need to connect rbx with iriver firmware section which is well known fo hi uncompetence... It won't help rbx and it may cause some issue...



PS: nothing to add to Roberto explanation about the integer lossy encoder...
[{POST_SNAPBACK}][/a]

Well, I own a CD-based iRiver player, and I'm happy with the firmware updates iriver provides. Sure, they aren't realeased every month or so, but the firmware is pretty stable and they even listened to their customers when asked for vorbis support.
I obviously won't notify them, that's the project's authors decision. But I'm not sure if iRiver would react negativelly. It's not like they're cracking or reverse engineering iRiver's original firmware - they're building one up from scratch, which might be more convenient to power-users, and can raise iRiver's sells. So unless there are some kinds of legal problems, iRiver should aknowledge the project and help them out. Pretty much like the Fedora Core/Red Hat relationship.
I might be missing something, though.
[a href="index.php?act=findpost&pid=273007"][{POST_SNAPBACK}][/a]
Hi Emtee,
First i don't want to be "out of subject" but i really want to precise I'm a very old "iriver fan", i meet the brand three years ago with his wonderfull iMP350 (SlimX)... So i'm totally aware of what iriver did adding Ogg Vorbis support by firmware upgrade to most of their palyers even very old one (with some bitrate limitations).

So don't mistake i'm not a primary antiiRiver, but the firmware policy of the korean company have changed for a while unfortunately and no iHP1xx owner can ignore this (tehy have promised much to us and after delay and delay we saw nothing or very few)...

Rockbox is a very skilled team, they've transfigured Archos players with their firmware... Actually they've began the iRiver port project for less than one year (~6months) and their progress are very impressive... In fact they are progressing very faster than the builtin iRiver fw had during more tyan one year... And keep in mind that Rbx had to discover all the hardware (in fact the [a href="http://www.iriverlounge.com]iRiverlounge[/url] work helped a lot at the beginning, thanks to them)...

So i really think there is absolutely no need to contact iriver... Maybe it would have been helpfull at the beginning of the project, but at the actual step it's simply useless...

I do'nt think iRiver can make any matter to Rbx project, but I'm quite sur they will try to... The iRiver policy concerning any modification (and even mionr one as logo changing) was to be quite strict (in the fact things were a little bit different than what they notified) I really don't want to see them causing troubles with Rbx...

Indeed the two latest lt.fw project didn't begun from scratch, LinusM confirmed this to me and that's why iRiver made some pression... And finally the project stopped (for the iriverlounge one it was a very different context anywell)

To resume, as far as i'm concerned i rather iRiver nt be informed cause first they won't help even if they wanted to do, and secondly they may cause some troubles which will necessarily slowen the rbx port...


Open Source Firmware For iRiver players

Reply #26
Exctarct of today IRC:
Quote
linuxstb -> Tang: Yes, libmad and libFLAC are now working (but outside the non-existent new Rockbox audio system)


So two decoders are implemented: libmad and libflac... But audio playback is still not possible since the audio output is not coded yet!!!


ABout the METADATA implementaion policy i've asked the question to Rockbox and they answered they will start METADATA support in a second step...
I'm not skilled in this domain but as far as i know, as some metadata format are "tarnscodec" (APEtag for APE, MPC and MP3, ogg comment for vorbis and FLAC) this point of view appears very sensefull...

Anyway if someone think there is some reason to take in consideration an implementation of both codec and his metadata in the same step, just expose it here or directly one the Rbx IRC channel...

Thanks,
Tanguy

Open Source Firmware For iRiver players

Reply #27
Quote
To resume, as far as i'm concerned i rather iRiver nt be informed cause first they won't help even if they wanted to do, and secondly they may cause some troubles which will necessarily slowen the rbx port...
[a href="index.php?act=findpost&pid=273147"][{POST_SNAPBACK}][/a]


Well, to cut it short ...

iRiver has released a product with a major recording flaw (known as 'the glitch') and they have done nothing about it with various firmware updates. Assuming this behaviour can be adressed via software/driver, I am not that happy with iRiver's decision to cease support for the H1xx series in favour of the newer H3xx series (which does not offer digital recording).

iRiver has also promised gapless playback ... all they realised was some kind of 'gap reduction' that doesn't work effectively and can cause playback trouble.

RockBox (as a project) creates a completely alternative software (a whole new operating system) for the iRiver players without using the original iRiver code (which surely is licensed to iRiver and thus stands as their legal property) ...

Bottomline is ... if the RockBox alternative software

1) will have the features the iRiver community really desires,
2) will enable the H1xx series of bit-true digital recording without dropping samples every 30 seconds and
3) doesn't use anything of the old code,

iRiver should be absolutely grateful about that. If they do object (or put pressure on the RockBox team to force them into not continuing their iRiver port), it is our task as consumers to make iRiver pay really hard for it.

The DAP market offers a lot of alternatives besides Apple ... and the iRiver competitors would gladly bite off a bit from iRiver's market shares.

Just my 2 cents.
The name was Plex The Ripper, not Jack The Ripper

Open Source Firmware For iRiver players

Reply #28
hi JeanLuc,
I'm quite agree with your point of view... Anyway just want to make discussion more rockbox centered now...
Cheers,
Tanguy

Open Source Firmware For iRiver players

Reply #29
Out of curiousity: what made you folks choose the iRivers? I mean, there are many portables out there, so why was this series interesting for you? Did it have something to do with available firmware memory and CPU? The fact that you're so freely brainstorming about codec support.... like for example monkeys audio although flac has faster decoding speed.... makes me think that the CPU may be quite capable?

- Lyx

EDIT: By the way... you'll be in a dead-head with the neuros for the first player to support MPC. Some weeks ago there was a call here for coders to get MPC-playback on the neuros. But then again, considering your openness to codec-support there will be lots of possibilites left to be "the first" even if the neuros people get MPC implemented first.
I am arrogant and I can afford it because I deliver.

Open Source Firmware For iRiver players

Reply #30
Quote
Out of curiousity: what made you folks choose the iRivers? I mean, there are many portables out there, so why was this series interesting for you? Did it have something to do with available firmware memory and CPU? The fact that you're so freely brainstorming about codec support.... like for example monkeys audio although flac has faster decoding speed.... makes me think that the CPU may be quite capable?

- Lyx
[a href="index.php?act=findpost&pid=273171"][{POST_SNAPBACK}][/a]

Even if i'm not rbx member i can answer to you snce i've read LOG about this...

Indeed they choosen iHP cause to his hardware and this include Opt IN/OUT... The iHP1xx is the only one DAP with OPTICAL IN/OUT...

The CPU wasn't first considerated neither the RAM since they were astonished when they learnt tehre was 32 Mb!!!

Open Source Firmware For iRiver players

Reply #31
Quote
The CPU wasn't first considerated neither the RAM since they were astonished when they learnt tehre was 32 Mb!!!
[a href="index.php?act=findpost&pid=273174"][{POST_SNAPBACK}][/a]


Would you know, by any chance, the CPU model and speed?

Open Source Firmware For iRiver players

Reply #32
Quote
Quote
The CPU wasn't first considerated neither the RAM since they were astonished when they learnt tehre was 32 Mb!!!
[{POST_SNAPBACK}][/a]


Would you know, by any chance, the CPU model and speed?
[a href="index.php?act=findpost&pid=273177"][{POST_SNAPBACK}][/a]

I 've knew that but i prefered asking on IRC to be sure giving exact info:
Quote
CPU: Motorola SCF5249 140MHz coldfire
Checkout this WIki Rockbox page:
[a href="http://www.rockbox.org/twiki/bin/view/Main/IriverInfo]http://www.rockbox.org/twiki/bin/view/Main/IriverInfo[/url]


The team say your'all welcome on their IRC channel, get access from this webpage:
http://www.rockbox.org/irc/


Open Source Firmware For iRiver players

Reply #33
About the two implemented decoders (libMAD and libFLAC) read their speed on IRC:
Quote
libmad is currently running at about 3.8% of real-time. libFLAC is about 8%


Very slow so... But keep in mind that for the moment the CPU is running underclocked (~20MHz instead of 140 I believe)

About mp3 decoder the team in thinking about going for this http://www.freescale.com/webapp/sps/downlo...M9&location=psp that need only 19mHz and 37kb mem only!

The issue is about the licensing so they are trying to get contact with the Motorola crew...

Anyway when Linus will set the CPU at his real speed i imagine the MAD implementation should work at real time with some optimisation...

Open Source Firmware For iRiver players

Reply #34
Quote
The issue is about the licensing so they are trying to get contact with the Motorola crew...[a href="index.php?act=findpost&pid=273189"][{POST_SNAPBACK}][/a]


It's worth checking if there won't be incompatibilities with the mix of licenses going into Rockbox: GPL (mad), LGPL (if they go with mpg123), BSD (WavPack, Vorbis...)

If Motorola, by any chance, only releases it as precompiled library, it'll be automatically incompatible with the GPL.

Open Source Firmware For iRiver players

Reply #35
Quote
Out of curiousity: what made you folks choose the iRivers? I mean, there are many portables out there, so why was this series interesting for you? Did it have something to do with available firmware memory and CPU? The fact that you're so freely brainstorming about codec support.... like for example monkeys audio although flac has faster decoding speed.... makes me think that the CPU may be quite capable?
[a href="index.php?act=findpost&pid=273171"][{POST_SNAPBACK}][/a]

Lack of having to install software to move files to and from the unit as it is read by computers as a Mass Storage device, Vorbis support, filetree navigation, and good battery life sold it for me.  Well that and the black look is nice to me.
Nero AAC 1.5.1.0: -q0.45

Open Source Firmware For iRiver players

Reply #36
Just our of curiosity, once the coders get a successful port on any iRiver device, is there a chance they would be willing to back-port to earlier iRiver devices? I own an iMP-250, and would love to be able to listen with some of the features (lossless playback of certain formats, truly "gapless" playback of MP3s using the L.A.M.E. tag info, etcetera...) discussed.

    - M.

Open Source Firmware For iRiver players

Reply #37
Quote
Out of curiousity: what made you folks choose the iRivers? I mean, there are many portables out there, so why was this series interesting for you?


1) optical SPDIF I/O and Line I/O for recording/playback (playback is bit-true, didn't know about the recording glitch )
2) 2x20 mW output power (it can even drive my Sennheiser HD600 with satisfying results) without too much low-frequency loss with low-impedance headphones/earbuds
3) 96 dB SNR
4) microphone (internal/external) for possible live recordings
5) convenient dimensions and weight
6) battery running time and short load cycle
7) sound quality when being compared to its competitors
8) ease of use as a player/external HDD without the need of proprietary software

just a few reasons ...
The name was Plex The Ripper, not Jack The Ripper

Open Source Firmware For iRiver players

Reply #38
The iHp choice question was for rockbox team i think...
No chance that Rockbox will be ported to earlier iriver, in fact it would be ported to iRiver H3xx quite easily but also to iAudio M3 and HB X-Key500 due to quite identical hardware (same CPU)

Latests Rockbox progress:
Quote
Sound   10% (very basic output working (sin-wave)


Plus some more progress in low level driver:
Quote
I2C driver   50% Writing to I2C done
I2S driver  10% Basic I2S output, but not interrupt-based yet
SPI driver  0%
Remote LCD driver (SPI)  0%
Audio ADC/DAC driver  10% UDA1380 Initialization and basic control done (volume control, muting etc)



Open Source Firmware For iRiver players

Reply #39
Quote
About the two implemented decoders (libMAD and libFLAC) read their speed on IRC:
Quote
libmad is currently running at about 3.8% of real-time. libFLAC is about 8%


Very slow so... But keep in mind that for the moment the CPU is running underclocked (~20MHz instead of 140 I believe)[{POST_SNAPBACK}][/a]

hmm... 8% at 20MHz ~> 56% at 140MHz.  the stock firmware for the [a href="http://www.jetaudio.com/products/iaudio/m3/]iAudio M3[/url] (same CPU) is doing FLAC with low order LPC, hopefully there is some more headroom somewhere in the iriver.  stock libFLAC (C only, no asm optimizations) is doing flac -8 on 74 MHz ARM7 parts (phatbox, rio), not sure if there are any major architectural differences between coldfire and ARM7 that would account for that.

one thing is for sure, a coldfire assembly version of one simple function (FLAC__lpc_restore_signal) would make a big difference and help out on the M3 also.

Josh

Open Source Firmware For iRiver players

Reply #40
I was looking for one of these players and I got this:
Quote
Buying choices
for the iRiver H120 (20GB)

This product is no longer available. See other MP3 players from iRiver.


From ZDNet and CNET.

Does anyone know where to find it?
I'm the one in the picture, sitting on a giant cabbage in Mexico, circa 1978.
Reseñas de Rock en Español: www.estadogeneral.com

Open Source Firmware For iRiver players

Reply #41
Quote
I was looking for one of these players and I got this:
Quote
Buying choices
for the iRiver H120 (20GB)

This product is no longer available. See other MP3 players from iRiver.


From ZDNet and CNET.

Does anyone know where to find it?
[{POST_SNAPBACK}][/a]

Quote
The iRiver H120 (iHP-120) 20GB is currently  In Stock

[a href="http://www.advancedmp3players.co.uk/shop/product_info.php?products_id=69]http://www.advancedmp3players.co.uk/shop/p...?products_id=69[/url]

or ... eBay

Open Source Firmware For iRiver players

Reply #42
Quote
4) microphone (internal/external) for possible live recordings
interesting, how serious is that glitch? and ot: what are some other portables with mic inputs? (and good quality recording)
PANIC: CPU 1: Cache Error (unrecoverable - dcache data) Eframe = 0x90000000208cf3b8
NOTICE - cpu 0 didn't dump TLB, may be hung

Open Source Firmware For iRiver players

Reply #43
Quote
Quote
About the two implemented decoders (libMAD and libFLAC) read their speed on IRC:
Quote
libmad is currently running at about 3.8% of real-time. libFLAC is about 8%


Very slow so... But keep in mind that for the moment the CPU is running underclocked (~20MHz instead of 140 I believe)[{POST_SNAPBACK}][/a]

hmm... 8% at 20MHz ~> 56% at 140MHz.  the stock firmware for the [a href="http://www.jetaudio.com/products/iaudio/m3/]iAudio M3[/url] (same CPU) is doing FLAC with low order LPC, hopefully there is some more headroom somewhere in the iriver.  stock libFLAC (C only, no asm optimizations) is doing flac -8 on 74 MHz ARM7 parts (phatbox, rio), not sure if there are any major architectural differences between coldfire and ARM7 that would account for that.

one thing is for sure, a coldfire assembly version of one simple function (FLAC__lpc_restore_signal) would make a big difference and help out on the M3 also.

Josh
[a href="index.php?act=findpost&pid=274418"][{POST_SNAPBACK}][/a]
Hi mister jcoalson,
Thanks for all those details... Of course the fact that the colfire is underclocked under rbx doesnt mind no optimisation will be required to run FLAC...

And of course the rbx team will make his possible to optimize the whole code... Anyway as they are working on a general audio API arc hitecture i wonder if they would optimize the codec to specifics CPU (ie coldfire for iHp and M3)
I imagine they will but i'haven't asked this to the team...I'll do this afternoon here i've no IRC access...
I'll ask too if the latests progress and specially about the CPU frequency...

of course I'll report their answers here then...

Cheers!

 

Open Source Firmware For iRiver players

Reply #44
Quote
Out of curiousity: what made you folks choose the iRivers? I mean, there are many portables out there, so why was this series interesting for you? Did it have something to do with available firmware memory and CPU? The fact that you're so freely brainstorming about codec support.... like for example monkeys audio although flac has faster decoding speed.... makes me think that the CPU may be quite capable?

but the time i bought my SlimX i paid 130 dollars, instead of like 60/80 for other brands, cause i was really eager to play my Vorbis files in it ... but time passed, and i regretted the desition more and more ... i should have bought another cheaper brand, as the vorbis support never materialized ... 

Open Source Firmware For iRiver players

Reply #45
Quote
Quote
Out of curiousity: what made you folks choose the iRivers? I mean, there are many portables out there, so why was this series interesting for you? Did it have something to do with available firmware memory and CPU? The fact that you're so freely brainstorming about codec support.... like for example monkeys audio although flac has faster decoding speed.... makes me think that the CPU may be quite capable?

but the time i bought my SlimX i paid 130 dollars, instead of like 60/80 for other brands, cause i was really eager to play my Vorbis files in it ... but time passed, and i regretted the desition more and more ... i should have bought another cheaper brand, as the vorbis support never materialized ... 
[a href="index.php?act=findpost&pid=274543"][{POST_SNAPBACK}][/a]

hi Kwanbis (never noticed you were a mareo dev)
The Vorbis support have been implemented by iRiver to IMP350 (1st SlimX) with fw 2.0 (if i do'nt mistake about the version)...
But there is some bitrate limitation which are very problemetic due to Vorbis VBR mode... :/

Open Source Firmware For iRiver players

Reply #46
Come back to subject anyway...

The Coldfire CPU is still running at 11mHz... (i mistaken it wasn't 19MHz)

Here is the Preglow answer to my question about this point on IRC:
Quote
preglow   Tang: clocking the cpu correctly takes alot of time, i'm pretty certain the wiki will be updated once it's done


Linus is working on this, but 'll take time, please be patient...

Open Source Firmware For iRiver players

Reply #47
Quote
hi Kwanbis (never noticed you were a mareo dev)
The Vorbis support have been implemented by iRiver to IMP350 (1st SlimX) with fw 2.0 (if i do'nt mistake about the version)...
But there is some bitrate limitation which are very problemetic due to Vorbis VBR mode... :/

afai, i'm THE mareo dev  ... yep, the bitrate problem is what i'm refering to

Open Source Firmware For iRiver players

Reply #48
Sorry i confused Sebastian Mares as Mareo dev too... just a mistake...
Cheers...

Open Source Firmware For iRiver players

Reply #49
Quote
And of course the rbx team will make his possible to optimize the whole code... Anyway as they are working on a general audio API arc hitecture i wonder if they would optimize the codec to specifics CPU (ie coldfire for iHp and M3)
I imagine they will but i'haven't asked this to the team...I'll do this afternoon here i've no IRC access...
I'll ask too if the latests progress and specially about the CPU frequency...

of course I'll report their answers here then...

Cheers!
[{POST_SNAPBACK}][/a]

Finaly I didn't asked on the IRC channel in fact i found the answer by myself in their Wiki:
Quote
Codec optimisation

None of the initial codec implementations are running fast enough for real-time decoding. Therefore effort is needed to optimise the libraries for the iRiver environment.


Some profiling information on libmad and libFLAC can be found here: [a href="http://ipodlinux.org/forums/viewtopic.php?t=850]http://ipodlinux.org/forums/viewtopic.php?t=850[/url]


So even if they chose a nonspecific architecture for the codec part of the new Rbx port, specific optimisations aren't excluded...

Cheers,
Tanguy