Rockbox

  • Status Closed
  • Percent Complete
    100%
  • Task Type Bugs
  • Category Operating System/Drivers
  • Assigned To No-one
  • Operating System Iriver H300 series
  • Severity Critical
  • Priority Very Low
  • Reported Version
  • Due in Version Version 3.0
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: Rockbox
Opened by brianhartgen - 2006-06-03
Last edited by linuxstb - 2006-06-05

FS#5486 - No speech when starting iRiver H340

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.

Closed by  hardeeps
2006-06-17 11:40
Reason for closing:  Fixed
Additional comments about closing:  

Fixed in latest CVS.

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=0×431938) at thread-sdl.c:50

Hope this helps, I’ll see if I can get further info.

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

Looks like my details above are due to simulator problems, not the actual problem. Anyone else fancy looking at this…?

Loading...

Available keyboard shortcuts

Tasklist

Task Details

Task Editing