Rockbox

This is the bug/patch tracker for Rockbox. Click here for more information.

Quick links: Bugs · Patches · Rockbox frontpage

Tasklist

FS#5486 - No speech when starting iRiver H340

Attached to Project: Rockbox
Opened by brian hartgen (brianhartgen) - Saturday, 03 June 2006, 15:37 GMT+2
Last edited by Dave Chapman (linuxstb) - Monday, 05 June 2006, 15:43 GMT+2
Task Type Bugs
Category Operating System/Drivers
Status Closed
Assigned To No-one
Player Type Iriver H300 series
Severity Critical
Priority Normal
Reported Version
Due in Version Version 3.0
Due Date Undecided
Percent Complete 100%
Private No

Details

STEPS TO REPRODUCE:

1. Power on the iRiver.
2. If you have a file automatically play at startup, you will hear the file.
3. Press stop.
4. Note that you get no speech at this point no matter which keys you press.
This is one of the problems and it is particularly a problem when Rockbox is
installed for the first time, because at that point Rockbox is not set to
play a file at startup.
5. Press play. Note that speech immediately begins, either the file will be
spelled or the MP3 clip played whichever is set.
6. If you press stop again during the speaking of the MP3 clip or the
spelling of the folder or file name, the player will freeze and the reset
button needs to be pressed in order to correct the problem. If you listen
to the speech, then press stop, everything is OK.
This task depends upon

Closed by  Hardeep Sidhu (hardeeps)
Saturday, 17 June 2006, 13:40 GMT+2
Reason for closing:  Fixed
Additional comments about closing:  Fixed in latest CVS.
Comment by Steve Bavin (pondlife) - Monday, 05 June 2006, 10:43 GMT+2
This happens to me too - in both the device and simulator. In the sim, it appears to be a division-by-zero in mpa.c line 259 ("Program received signal SIGFPE, Arithmetic exception.", presumably current_frequency is 0). I'm not overly adept at debugging yet, but the top of the call stack at the crash point looks like this:
#0 0x04cc9f8f in __divdi3 ()
#1 0x04cc18c9 in codec_start (api=0x44f0a0) at mpa.c:259
#2 0x00432c18 in codec_load_ram (codecptr=0x571c60 "MZ\\220", size=207470,
ptr2=0x0, bufwrap=0, api=0x44f0a0) at codecs.c:268
#3 0x00432d19 in codec_load_file (
plugin=0x4562f2 "/.rockbox/codecs/mpa.codec", api=0x44f0a0)
at codecs.c:299
#4 0x004319cd in codec_thread () at playback.c:2277
#5 0x0044af2c in runthread (data=0x431938) at thread-sdl.c:50

Hope this helps, I'll see if I can get further info.
Comment by Steve Bavin (pondlife) - Monday, 05 June 2006, 18:38 GMT+2
OK - I know a bit more about this crash on the simulator:
1) In mpa.c, around line 187, the following call is made: "inputbuffer = ci->request_buffer(&size, INPUT_CHUNK_SIZE);"
2) This enters playback.c routine voice_request_buffer_callback().
3) A call is then made to swap_codec(), which "rearranges" the memory being used in the original call (i.e. point 1 above).
4) The call returns to mpa.c, luckily not crashing immediately, but returning to a point after the call to mad_frame_decode.
5) Thus the frame.header.samplerate is left set to 0, which is then copied into current_frequency, causing a division by zero error.

Things I don't know (yet):
- If this is just a simulator problem with a co-incidental recipe, or the same problem as the real player.
- What system is meant to be in place to stop this codec/memory contention. I'd assume that there should be 2 copies of the MPA codec in memory (one for voice, one for the audio).
- Why this is only a problem when resuming with crossfade enabled.

One other note - it would be more useful if the simulator used the standard rockbox kernel (i.e. with no use of #ifdef SIMULATOR apart from at the point of hardware access).
Comment by Steve Bavin (pondlife) - Friday, 16 June 2006, 16:47 GMT+2
Looks like my details above are due to simulator problems, not the actual problem. Anyone else fancy looking at this...?

Loading...