- Status Closed
- Percent Complete
- Task Type Bugs
- Category Plugins
- Assigned To No-one
- Operating System Iriver H100 series
- Severity Medium
- Priority Very Low
- Reported Version
- Due in Version Undecided
-
Due Date
Undecided
- Votes
- Private
FS#6174 - Plugins that use IRAM lock up when loaded while playing
Since plugins use the same IRAM space as codecs, whenever a plugin (such as mp3_encoder) copies it’s data to IRAM, it overwrites the codec data. To fix this, there needs to be a plugin api function that unloads the codec and copies data to IRAM. This function would look like:
int plugin_copy_iram(void* iramstart, void* iramend, void* iramcopy, void* iedata, void* iend);
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
Ok, I found the problem. Calling rb→audio_stop() worked on an older version, but not on current CVS.
Calling rb→audio_stop(); by itself rb→sleep(1); seems to make it work on the current version, but it's just a hack.
The problem is that audio_stop() (in playback.c) yields until playing is false, but audio_stop_playback() (which is called from the audio thread) sets playing to false before it calls audio_stop_codec_flush(), which yields again, causing audio_stop to return before the codec is finalized and unloaded.
The solution is to set playing to false after the call to audio_stop_codec_flush().
Thanks - I'll commit this shortly.