Rockbox Development > New Ports

SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2

<< < (155/386) > >>

cyclon1978:
with both patches i have on e280v2 mp3 playback - great, ogg playback - great, video playback: sound without picture

Thanks!

Andreas

freqmod:
@funman, well it does not crash, but my clipv1 stops playing when a track  if you shuffle a bit, and the let a track  play about a minutte after the lcd display has been turned of, then it displays (root), (root) and wont play anthing before playback is stopped (i.e. the square icon appears)  (when the disk alignment patch is applyed to rockbox SVN). This applies to mp3, but not to  speex (at least it takes much more time).

I did a full new full checkout from svn and made a new build directory to be shure it was no old remains from other patches.

edit: It does not seem like the oled/lcd has anything to do about it, it chashed when the lcd was active tool.

saratoga:
funman:  I tested both patches and they work nicely.  I say commit as soon as possible.

Performance is still extremely poor for whatever reason.  MP3 takes ~ 145MHz.  I can shave 10MHz off that by putting everything in IRAM, but thats it.  Cache shouldn't hurt us all that badly when running out of IRAM, unless lack of the MMU imposes some other performance penalty (slowing down sequential IRAM access or similar).  Is it possible some driver is doing a lot of busy waiting?

Otherwise, the port seems quite functional. 

funman:
@freqmod : I'll try using my clip more to see if I can reproduce (the IRAM patch didn't apply to Clipv1 and m200v4 at all by the way)

@sko/cyclon1978 : on the Fuze you need this patch for mpegplayer

@saratoga : I'll try to look in drivers if they do busy waiting and put some yield() here
Perhaps the slowness comes from the fact that we don't declare the SDRAM nor IRAM as cached (via the MMU) ?

bertrik:
IIRC from the discussions on IRC, a lot of ARM targets currently use long calls which makes the code slower and bigger. I think one of the most important things we could do with the MMU is to map memory regions such that they are close enough to each other to use short calls, thereby shrinking the code and speeding it up (slightly).

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version