This is the bug/patch tracker for Rockbox. Click here for more information.
Quick links: Bugs · Patches · Rockbox frontpage
FS#9318 - MP3 synthesis filter on COP
Attached to Project:
Rockbox
Opened by MichaelGiacomelli (saratoga) - Monday, 25 August 2008, 03:50 GMT+2
Last edited by MichaelGiacomelli (saratoga) - Sunday, 21 September 2008, 00:06 GMT+2
Opened by MichaelGiacomelli (saratoga) - Monday, 25 August 2008, 03:50 GMT+2
Last edited by MichaelGiacomelli (saratoga) - Sunday, 21 September 2008, 00:06 GMT+2
|
DetailsMy measurements of the COP and boost power consumptions for the PP5024 suggest that load balancing rockbox as much as possible across both of the cores is optimal for battery life. To test this, I've put the synthesis filter from MAD on the coprocessor. This reduces CPU load sufficiently that the CPU doesn't need to boost at 30MHz, and probably very little at 24MHz.
Unfortunately, theres still some glitching, either because of some cache coherency problem, or because I don't properly synchronize the two threads. 
mad_copv1.patch
(5.5 KiB)
apps/codecs/mpa.c | 127 +++++++++++++++++++++++++++++++++++++++++++++-- apps/codecs/libmad/mad.h | 15 +++-- 2 files changed, 132 insertions(+), 10 deletions(-) |
This task depends upon
Closed by MichaelGiacomelli (saratoga)
Sunday, 21 September 2008, 00:06 GMT+2
Reason for closing: Accepted
Sunday, 21 September 2008, 00:06 GMT+2
Reason for closing: Accepted
However, the patchfile is still b0rked.
Though if you mean MP3 decoding is broken, I'm still trying to figure out why it has that distortion.
Properly decodes a single file on my Sansa, but I have not yet figured out how to clean up after my threads, and so track changes do not work yet. Additionally, running test_codec still isn't possible, so theres still some sort of bug thats only apparent under certain conditions.
Additionally, I have not yet investigated the codecs.c code here:
http://pastebin.ca/1184808
Why not use 2-count semas and a circular buffer to obviate the memcpy usage? SPC uses that method and allows simultaneous DSP processing and EMU execution.
Edit: I might be seeing now why it's that way. Some details about what libmad does with the sbsample arrays might help improve parallelism.
Regarding a binary semaphore, I was under the impression that they worked differently. I need a way for one thread to release a lock for a single iteration of some code, and then automatically retrieve it after the second thread is finished. I don't really understand semaphores, but it looks like once a thread releases a binary semaphore, the code it blocks becomes open to a second thread indefinitely, and I couldn't see a way for the second thread to give back the lock to the first thread. Events seem like a good fit because a thread blocking on an event can only receive each event once, and thus they automatically block if a thread calls it twice.
"The Little Book of Semaphores" by Downey is a good read.
I've made minor changes to Mpegplayer as well to accommodate the changes to libmad.
ci->semaphore_init(&synth_done_sem, 2, 0); /* No blocks used */
ci->semaphore_init(&synth_pending_sem, 2, 2); /* All blocks free */
or
ci->semaphore_init(&synth_done_sem, 2, 0); /* No blocks used */
ci->semaphore_init(&synth_pending_sem, 2, 0); /* No blocks free */
followed by
ci->semaphore_release(&synth_pending_sem); /* Bring count back up to 2 to let the synth run */
ci->semaphore_release(&synth_pending_sem);
If I understand the code correctly, the way it is now it can only fill one buffer at a time. Perhaps my evaluation is whacked. :)
The confusing part for me was that there is no parallelism until the second iteration of the decoding loop (well, it's not my code so it needed a good staring session). The mutual waiting is quite tight however and to loosen it up into a full FIFO would need separate head and tail pointers and a PCM queue as well. As it is, one buffer is always free to one of the threads where a full FIFO would allow one thread to write or read all elements.