- Status New
- Percent Complete
- Task Type Patches
- Category Music playback
- Assigned To No-one
- Operating System SW-codec
- Severity Low
- Priority Very Low
- Reported Version Daily build (which?)
- Due in Version Undecided
-
Due Date
Undecided
- Votes
- Private
FS#9332 - Read audio data directly from flash memory
This patch provides a replacement for buffering.c, where there is only minimal buffering (one 32K buffer for audio data and some static buffers for metadata). It is a proof of concept for how this could work on targets with very little RAM.
I would be interested in feedback on the kind of impact this has on runtime, so if you have a flash target please consider giving it a try and reporting your results :)
Note that you will need to disable album art in your build for this to work. I don't even know what would happen if you don't, but it'd probably be bad. To disable it you need to comment or remove the #define HAVE_ALBUMART line in your target's configuration file (firmware/export/config-[TARGET].h).
buffering_flash_v2.patch
(11.7 KiB)
Hi,
i just wanted to try this code on a m200v4 (only 2MB ram) as we have trouble with the normal buffering code.
Unfortunatly this patch is outdated ( EVENT_HANDLE_FINISHED does not exist anymore), and i am unable to fix it.
Would be very nice if you could sync this to svn.
synced; I begin testing on the Clip and notice a lot of skips in mp3, perhaps we can enlarge the audio buffer a bit
It seems to be due to the fact that the buffer is only refilled when requested and not in advance.
Except that, the patch works very fine on Clip.
Don't ask me why, but this seems to break USB on both e200 and gigabeat F.
[edit] OK, found te problem : the thread event loop needs to handle SYS_USB_CONNECTED (in the same way as buffering.c)
Some results of testing this patch on the clip:
low-bitrate MP3 and -q5 Vorbis: Mostly works.
AAC: Fails because the AAC codec apparently isn't built for targets with 2MB or less of RAM
FLAC: Fails to play and often leads to a SD RX buffer underrun (don't remember the exact wording and have rockbox uninstalled from my 2 clips)
For what it's worth, I suspect the failures I'm experiencing have more to do with bitrate than codec.
I did some testing of my theory after Lucent suggested that the cause of the problem could be the Clip choking on data stored in certain parts of the flash memory and gave a potential workaround.
Ogg, mp3, and WAV seem to work and FLAC and SHN throw codec errors when I try to play them.
When I shut down after I try to play FLAC or SHN, I get the following error:
*PANIC*
SD : RX OVERRUN, RXR
FIFO FULL,
It's also possible that my issues aren't related to this patch and are issues that are masked in unpatched builds by the completely broken buffering system.
Tried to bring this patch up-to-date:
* Use an unsigned int thread id for the buffering thread instead of a struct thread_entry pointer
* Fix warnings about unused parameters
* Add return value for functions need to do so (functions returning a size_t return a 0 now)
* Copy SYS_USB_CONNECTED handler from buffering.c
Hmm, my previous patch was no good, missed a break:
* fixed missing break
* implemented functions buf_handle_offset and buffer_get_debugdata (returns mostly 0)
Updated to svn r22628:
* changed strncpy to strlcpy as suggested by than0 on IRC
sync to r24323
add missing argument to bufopen() : needed for albumart but not implemented
I ran it on my clip and compared the battery bench : absolutely no battery life loss