Notice: A non well formed numeric value encountered in /sites/rockbox.org/flyspray/includes/class.flyspray.php on line 96 Notice: A non well formed numeric value encountered in /sites/rockbox.org/flyspray/includes/class.flyspray.php on line 96 Notice: A non well formed numeric value encountered in /sites/rockbox.org/flyspray/includes/class.flyspray.php on line 96 Deprecated: Function create_function() is deprecated in /sites/rockbox.org/flyspray/includes/class.flyspray.php on line 104 Deprecated: The each() function is deprecated. This message will be suppressed on further calls in /sites/rockbox.org/flyspray/adodb/adodb.inc.php on line 845 Deprecated: Function create_function() is deprecated in /sites/rockbox.org/flyspray/includes/class.user.php on line 111 FS#9332 : Read audio data directly from flash memory

Rockbox

Tasklist

FS#9332 - Read audio data directly from flash memory

Attached to Project: Rockbox
Opened by Nicolas Pennequin (nicolas_p) - Thursday, 28 August 2008, 12:30 GMT
Task Type Patches
Category Music playback
Status New
Assigned To No-one
Operating System SW-codec
Severity Low
Priority Normal
Reported Version Daily build (which?)
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 0
Private No

Details

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)
This task depends upon

Comment by Dominik Wenger (Domonoky) - Saturday, 29 November 2008, 18:49 GMT
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.
Comment by Rafaël Carré (funman) - Tuesday, 02 December 2008, 16:45 GMT
synced; I begin testing on the Clip and notice a lot of skips in mp3, perhaps we can enlarge the audio buffer a bit
   buffering_flash_v2.patch (11.1 KiB)
Comment by Rafaël Carré (funman) - Wednesday, 03 December 2008, 15:51 GMT
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.
Comment by Frank Gevaerts (fg) - Monday, 08 December 2008, 20:24 GMT
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)
Comment by Alex Meyer (binaryhermit) - Sunday, 21 December 2008, 06:37 GMT
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.
Comment by Alex Meyer (binaryhermit) - Sunday, 21 December 2008, 07:22 GMT
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,
Comment by Alex Meyer (binaryhermit) - Sunday, 21 December 2008, 07:26 GMT
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.
Comment by Bertrik Sikken (bertrik) - Wednesday, 24 December 2008, 10:23 GMT
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
   buffering_flash_v3.patch (11.8 KiB)
Comment by Bertrik Sikken (bertrik) - Wednesday, 24 December 2008, 11:59 GMT
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)
   buffering_flash_v4.patch (12 KiB)
Comment by Bertrik Sikken (bertrik) - Saturday, 05 September 2009, 04:44 GMT
Updated to svn r22628:
* changed strncpy to strlcpy as suggested by than0 on IRC
   buffering_flash_v5.patch (12.2 KiB)
Comment by Rafaël Carré (funman) - Sunday, 24 January 2010, 18:00 GMT
sync to r24323

add missing argument to bufopen() : needed for albumart but not implemented
   buffering_flash_v6.patch (12.1 KiB)
Comment by Rafaël Carré (funman) - Monday, 25 January 2010, 23:48 GMT
I ran it on my clip and compared the battery bench : absolutely no battery life loss
   clip.png (5 KiB)

Loading...