This is the bug/patch tracker for Rockbox. Click here for more information.
Quick links: Bugs · Patches · Rockbox frontpage
FS#4899 - iPod AutoPause
Attached to Project:
Rockbox
Opened by Max Ried (bot47) - Thursday, 23 March 2006, 20:03 GMT+2
Last edited by Rani Hod (RaeNye) - Monday, 18 September 2006, 20:37 GMT+2
Opened by Max Ried (bot47) - Thursday, 23 March 2006, 20:03 GMT+2
Last edited by Rani Hod (RaeNye) - Monday, 18 September 2006, 20:37 GMT+2
|
DetailsThis patch is a quick hack to support the auto pause feature of the original Apple firmware. Rockbox _SHOULD_ pause now automatically. This patch was made for my iPod nano and I guess the G5, too, since it's mostly the same machine. It does not yet work properly and is just a quick hack, but please complain about it and test it. Own risks of course. I made this because of a current feature request.
pause.diff
(1.2 KiB)
apps/playback.c | 17 +++++++++++++++-- 1 file changed, 15 insertions(+), 2 deletions(-) |
This task depends upon
Closed by Linus Nielsen Feltzing (linusnielsen)
Tuesday, 26 September 2006, 12:03 GMT+2
Reason for closing: Accepted
Tuesday, 26 September 2006, 12:03 GMT+2
Reason for closing: Accepted
Apply only pause2.diff. pause.diff is obsoleted
Works properly if playback.c is reverted to an older version, because pause is just broken.
Don't complain about the dirty patch, it will apply anyway. There was no way to provide a better one because the CVS Server lacks *grr*
Should apply cleanly post tagcache
why is that not embedded tho cvs yet, such a good patch!
I don't know if the method I use to rewind is the right thing to do, but it has worked for me so far.
I'm open to suggestions for any improvements to the strings in english.lang - at the moment I'm just trying to keep them as short as possible.
queue_post(&audio_queue, Q_AUDIO_RESUME, (bool *)true);
and
queue_post(&audio_queue, Q_AUDIO_PAUSE, (bool *)true);
, this way everything seems to work, and it feels like it makes more sense too. In the early versions you were eating real events from the queue and in the latest you were overwritten by them.
+ ev.id = Q_AUDIO_PAUSE;
+ ev.data = (void *)1;
lines (plus the Q_AUDIO_RESUME pair further down) in playback.c
But apart from that, the patch is broken at the moment, after the recent playback code changes.
It needs changing anyway (the pause/resume code shoudn't be where it is - but I'm not sure where it should be instead)
It needs to act whereever you are in RB... (so from that point of view playback.c makes sense).
Should it be setup as a BUTTON_ for the platforms that have headphone detection?
Still not as it should be, but working again.
Inserting/removing the phones should cause an event, instead of sitting in the playback thread looking to see if it's changed.
I've been trying to make the phone socket generate events by changing the interrupt code in firmware/drivers/button.c (line 625-634) - by changing the 0x20 values to 0x80 (ie purely socket) or 0xA0. I've also tried adding new interrupts for GPIOF, value 0x20 (which is generated by the headphone socket on my 5g - I think this maybe different on other models?). I've been using my piezo patch (5111) to enable beeps when interrupts occur - no luck so far.
I'm a bit stuck at this point as to what to try next. I'm not even sure that this is the right way to go - some extra feedback would be nice! :)
if (GPIO_INPUT_VALUE_OR_WHAT_EVER & 0xWHAT_EVER)
never works in my tests.
Solves slow response to headphone induced pause/resume while the playback system is filling the codec buffer.
Thread is now created/removed as needed - no longer any need to reboot after changing the settings.
With any luck this patch might even be looked at one day.
Obviously, I too hope it's committed some day soon.