Rockbox Development > New Ports
SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
ranma:
--- Quote from: tofmin on April 12, 2010, 11:56:08 AM ---When I turn on "cuesheet support" I can't skip to next/prev track. Player hangs in database (sometimes)
--- End quote ---
Hmm, indeed. Never tried cuesheet support before, maybe its an issue with the limited ram size?
--- Quote from: tofmin on April 12, 2010, 11:56:08 AM ---and I've got randomly "dark blue screens" (in Settings, Database or just after turning on).
--- End quote ---
That's a known problem, sometimes the LCD controller gets reset or something... Maybe due to the DBOP noise problem seen on key reads.
--- Quote from: tofmin on April 12, 2010, 11:56:08 AM ---If cuesheet support is off, then next/prev buttons works again but player still hangs sometimes with "blue screen" on the LCD and when I use some applications (ie: fire, fft)
Hmm, I remember 25508 coz this was first build which I installed on my player (and tested him almost two days) after apply "backlight patch" for the c200:
http://svn.rockbox.org/viewvc.cgi?view=rev&revision=25499
Sorry 4 bad english. Again. And thx for great job U done!
--- End quote ---
I tried "cuesheet support" with r25499 and it doesn't work there either, so it's not a regression.
Please remember that C200v2 support is still unstable, and some things might also just be a bit difficult to get to work because of the small amount of RAM (2MB) this hardware has (e.g. recording).
saratoga:
If cuesheet support tries to allocate more memory then we can afford, we should probably disable it.
ranma:
--- Quote from: saratoga on April 15, 2010, 01:30:51 PM ---If cuesheet support tries to allocate more memory then we can afford, we should probably disable it.
--- End quote ---
It's allocating ~72KB at least (struct cuesheet is freaking big), so that really might be the reason...
99 (MAX_TRACKS) struct cue_track_info are (((80*3+1)*3+4)*99) => 71973 Bytes
Let's see. With cuesheet enabled:
--- Quote ---pcm: 0/176400
alloc: 0/91552
usefl: 0/91552
--- End quote ---
Without cuesheet:
--- Quote ---pcm: 0/176400
alloc: 0/164624
usefl: 0/164624
--- End quote ---
So it's 73072 Bytes and practically half of the memory still 'available'.
[edit]
Verifying it's a memory issue:
For the most part the pcm buffer still seems to be larger than necessary, so I halved it, trading it in for 88200 additional Bytes of alloc/usefl.
Now with cuesheet enabled:
--- Quote ---pcm: 0/88200
alloc: 0/179480
usefl: 0/179480
--- End quote ---
And skipping to next/previous track works _most_ of the time.
Sometimes it still stops playing though, with pcm and alloc/usefl fully filled.
[/edit]
[edit2]
BTW, compiling with '-Os' gives me about 32KB more available memory than the default '-O', maybe that should be made default in configure as with some other archs (e.g. sh, m68k)
[/edit2]
[edit3]
When it stops playing and just sits there with filled buffer not doing anything, it seems to be sitting in codec_pcmbuf_insert_callback in
--- Code: ---186 while ((dest = pcmbuf_request_buffer(&out_count)) == NULL)
187 {
188 cancel_cpu_boost();
189 sleep(1); <---- sleeping here
190 if (ci.seek_time || ci.new_track || ci.stop_codec)
191 return;
192 }
--- End code ---
Debugger:
--- Code: ---(gdb) target remote localhost:3333
Remote debugging using localhost:3333
[...]
(gdb) bt
#0 switch_thread ()
at /home/ranma/src/rockbox-c240v2/firmware/target/arm/system-arm.h:242
#1 0x3003002c in codec_pcmbuf_insert_callback (ch1=<value optimized out>,
ch2=<value optimized out>, count=47)
at /home/ranma/src/rockbox-c240v2/apps/codec_thread.c:189
#2 0x30208684 in tree_gui_init ()
at /home/ranma/src/rockbox-c240v2/apps/tree.c:301
#3 0x00000450 in ?? ()
#4 0x00000450 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb) frame 1
#1 0x3003002c in codec_pcmbuf_insert_callback (ch1=<value optimized out>,
ch2=<value optimized out>, count=47)
at /home/ranma/src/rockbox-c240v2/apps/codec_thread.c:189
189 sleep(1);
(gdb) print dest
$1 = 0x0
(gdb) print out_count
$2 = 47
(gdb)
--- End code ---
[/edit3]
[edit4]
The problem seems to be that the pcm buffer is completely filled according to one metric (pcm: 88200/88200 in buffering thread debug, pcmbuf_request_buffer returns NULL) and completely empty according to another (pcmbuf_unplayed_bytes is 0, pcmbuffer_fillpos is 0).
[/edit4]
[edit5]
Ok, I think the problem here was just that with a reduced pcm buffer size
the PCMBUF_TARGET_CHUNK and PCMBUF_MINAVG_CHUNK defaults are too big.
With those two reduced to 8192 and 6144 it seems to run pretty well even with a pcm buffer of just 44100 Bytes. With a pcm buffer that small I do hear occasional short buffer underruns though.
And the hang with unreduced pcm buffer size and cuesheet support enabled is a different kind of hang than what I was seeing here.
BTW, I compared the target configs for the different Sansa 2MB targets and
c200v2 has the biggest PLUGIN_BUFFER_SIZE define of them all.
By reducing it from 0x60000 to 0x45000 like in sansaclip.h or sansam200v4.h
we'd gain enough memory (110592 Bytes) to make cuesheet support work I think.
[/edit5]
funman:
Perhaps we should disable the few plugins which use a lot of memory
Timar:
Hi,
as I've posted here: http://www.anythingbutipod.com/forum/showpost.php?p=463457&postcount=186 I get playback crashes with all recent rockbox builds on my Clip+. Today I've tried the new 25676. While it crashes as usual it now displays a debug message (reproducable). I thought I'd post it here for it may be usefull for bugfixing:
--- Code: ---Data abort at 30057FC4
FSR 0x8 (domain 0, fault 8)
address 0xFFFFFFFF
--- End code ---
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version