Rockbox

Tasklist

FS#8226 - Enable audio menu for pacbox; enable audio for ipod 5g by putting emu on cop

Attached to Project: Rockbox
Opened by Dave Hooper (stripwax) - Sunday, 25 November 2007, 19:37 GMT
Task Type Patches
Category Games
Status Unconfirmed
Assigned To No-one
Operating System PortalPlayer-based
Severity Low
Priority Normal
Reported Version Daily build (which?)
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 1
Private No

Details

This patch puts the pacbox emulator onto the cop, leaving the main cpu for audio codec. The COP behaviour is controller by a #define in pacbox.h

If PACBOX_ON_COP is defined, then all iram usage is also turned off, to prevent interference with audio thread.

Additionally, this patch adds an Audio menu (using the playback_control library), which is enabled for all PACBOX_ON_COP and GIGABEAT F-Series builds.

Patch from directly within the apps/plugins/pacbox directory.
   pacbox_ipod_cop_and_audio_men... (13.3 KiB)
This task depends upon

Comment by Dave Hooper (stripwax) - Sunday, 25 November 2007, 20:47 GMT
Updated to fix nano builds
   pacbox_ipod_cop_and_audio_men... (13.3 KiB)
Comment by Dave Hooper (stripwax) - Sunday, 25 November 2007, 21:07 GMT
Only tested on ipod 5g (as that is all I have). Could someone with a Gigabeat confirm that pacbox still runs but now has a working Audio Playback menu? Also could someone with any other device confirm that pacbox still works for them?
Comment by Michael Sevakis (MikeS) - Wednesday, 28 November 2007, 02:03 GMT
This is cool though the ultimate plan is to do playback decoding on COP to leave the CPU available for foreground tasks. This would probably keep the SPC codec from operating with the COP trying to run two emulators at once.
Comment by Dave Hooper (stripwax) - Thursday, 29 November 2007, 00:07 GMT
When all codecs get moved to COP, pacbox can get moved back to CPU
Comment by Dave Hooper (stripwax) - Thursday, 29 November 2007, 00:07 GMT
Updated to get rid of build warning on gigabeat
   pacbox_ipod_cop_and_audio_men... (13.4 KiB)
Comment by Dave Hooper (stripwax) - Monday, 03 December 2007, 21:59 GMT
At jhMikeS's suggestion, adding cache flush and cachealign_attr code. Probably, it would have been better to use a separate (cachealigned) section for data that needs to be local to cop only rather than sprinkling CACHEALIGN_ATTR thru the codebase.
   pacbox_ipod_cop_and_audio_men... (18.6 KiB)
Comment by Dave Hooper (stripwax) - Monday, 03 December 2007, 23:40 GMT
Fix sim builds (no icache)
   pacbox_ipod_cop_and_audio_men... (18.6 KiB)
Comment by Michael Sevakis (MikeS) - Tuesday, 04 December 2007, 04:11 GMT
The section idea for writeable data is one I've been thinking about for awhile and would be preferrable as the general one. I'm not sure how to pull it off in a scalable way (need to read up on the linker script syntax myself). Can we ensure that its size is 0 if nothing is allocated there?

Add to the list any I forgot for sections the COP should have to iself (in core, plugins, and codecs):
.bss
.data

Of course the same sections must be aligned for CPU so that adjacent and shared .rodata and such don't play ping-pong.

I think 16 bytes is actually the correct value as well but I played cautious for the moment.
Comment by Michael Sevakis (MikeS) - Tuesday, 04 December 2007, 04:16 GMT
BTW, threads can also switch cores. An implementation that flip-flops the main thread from CPU<=>COP would be a nice test of that capability.

EDIT to clarify: you could switch the main thread to the COP when it's running emulation and switch back to CPU when leaving the emulation to display menus or whatever. Just use switch_core(int core_num)
Comment by Michael Sevakis (MikeS) - Tuesday, 04 December 2007, 04:27 GMT
For the framebuffer CACHEALIGN_AT_LEAST(16) is preferrable since that automatically selects the greater of the alignments.
For the cache functions, CACHE_FUNCTION_WRAPPERS(rb) allows use without the "rb->" and allows for the case where cache maintenence APIs are inlines instead of calls.
Comment by Dave Hooper (stripwax) - Thursday, 06 December 2007, 23:59 GMT
Fantastic ideas. So while I haven't taken a look at the linker specs either, I have added the rest. Switching cores seems to work fine (and of course makes the code a touch simpler)
   pacbox_ipod_cop_and_audio_men... (19 KiB)
Comment by Dave Hooper (stripwax) - Friday, 07 December 2007, 00:14 GMT
I think just .bss and .data covers it. Would it even be worthwhile having yet another section for data used by /both/ cop and cpu?
Comment by Dave Hooper (stripwax) - Sunday, 09 December 2007, 17:48 GMT
I think just .bss and .data covers it. Would it even be worthwhile having yet another section for data used by /both/ cop and cpu?
Comment by Dave Hooper (stripwax) - Sunday, 30 December 2007, 10:30 GMT
Syncd
   pacbox_ipod_cop_and_audio_men... (20.1 KiB)
Comment by Dave Hooper (stripwax) - Sunday, 06 January 2008, 21:13 GMT
Sync again
   pacbox_ipod_cop_and_audio_men... (20.2 KiB)
Comment by Dave Hooper (stripwax) - Tuesday, 12 August 2008, 21:59 GMT
Sync again, for the changed interface of switch_core
   pacbox_ipod_cop_and_audio_men... (20.4 KiB)
Comment by Dave Hooper (stripwax) - Tuesday, 03 March 2009, 23:39 GMT
I realise that this hasn't been sync'd in a while, but a big part of that reason is that putting pacbox emulation on COP no longer interacts nicely with having mp3 parallelised decoder on cpu/cop , which was added to svn at some point after the last update above. I'll try and figure out a clean solution at some point (maybe just as simple as improve the pacbox emulation so it doesn't need so much juice)

Loading...