- Status Closed
- Percent Complete
- 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
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.
2006-06-17 11:40
Reason for closing: Fixed
Additional comments about closing: Warning: Undefined array key "typography" in /home/rockbox/flyspray/plugins/dokuwiki/inc/parserutils.php on line 371 Warning: Undefined array key "camelcase" in /home/rockbox/flyspray/plugins/dokuwiki/inc/parserutils.php on line 407
Fixed in latest CVS.
Loading...
Available keyboard shortcuts
- Alt + ⇧ Shift + l Login Dialog / Logout
- Alt + ⇧ Shift + a Add new task
- Alt + ⇧ Shift + m My searches
- Alt + ⇧ Shift + t focus taskid search
Tasklist
- o open selected task
- j move cursor down
- k move cursor up
Task Details
- n Next task
- p Previous task
- Alt + ⇧ Shift + e ↵ Enter Edit this task
- Alt + ⇧ Shift + w watch task
- Alt + ⇧ Shift + y Close Task
Task Editing
- Alt + ⇧ Shift + s save task
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,
#3 0x00432d19 in codec_load_file (
#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…?