This is the bug/patch tracker for Rockbox. Click here for more information.
Quick links: Bugs · Patches · Rockbox frontpage
FS#12452 - Reduce interrupt latency for AMS v1 and v2
Attached to Project:
Rockbox
Opened by Michael Sevakis (MikeS) - Wednesday, 14 December 2011, 04:12 GMT+2
Last edited by Michael Sevakis (MikeS) - Sunday, 08 January 2012, 23:34 GMT+2
Opened by Michael Sevakis (MikeS) - Wednesday, 14 December 2011, 04:12 GMT+2
Last edited by Michael Sevakis (MikeS) - Sunday, 08 January 2012, 23:34 GMT+2
|
DetailsThese devices can spend alot of time in ISR's waiting to perform operations like reading the DBOP or waiting for it to go idle. AMSv2 has PMU read and write functions that keep interrupts disabled for a full two I2C transfer. This can prevent audio interrupts from being serviced in a timely manner resulting in occasional dropouts for playback or small bits of lost data for recording. The solutions are 1) Enable stack interrupts on all targets 2) Rewrite ascodec_read/write_pmu to disable interrupts only to place two consecutive requests in the queue but wait with interrupts enabled for completion.
Interrupts callbacks are in SVC mode on its own stack. I'm not certain what size is reasonable. Theoretically all enabled interrupts could happen up to the highest level, potentially consuming quite a bit of stack in the worst case and 1/2 the current IRQ stack just to save context. I also disabled semaphore_release context switch for the moment. A different scheme that explicitely checks for thread execution context will be needed as interrupts being disabled won't be a way to discern whether or not interrupt context is executing. One interesting issue on Fuze v2 that I have not been able to figure out is that if the GPIOA ISR is interrupted by a higher-priority interrupt, execution ends up in all sorts of strange places, with the concomitant fault screen or freeze. Unless the cause of that is remedied, GPIOA's ISR will have to be the highest priority or the enabling of IRQ during ISR selected on a per-handler basis. GPIOA's ISR is very short so shouldn't hurt latency very much. Surprisingly, no other stacking I checked by running recording and delaying for a few thousand microseconds inside the ISR in order to force audio interrupts on top of another produced any sort of fault. 
as3525-int-latency-improvement-01.patch
(12.3 KiB)
firmware/kernel.c | 2 firmware/target/arm/crt0.S | 24 ++++++-- firmware/target/arm/as3525/system-as3525.c | 43 +++++++++++++--- firmware/target/arm/as3525/ascodec-as3525.c | 43 ++++++++++++++-- firmware/target/arm/as3525/ascodec-target.h | 24 +------- firmware/target/arm/as3525/sd-as3525v2.c | 6 +- firmware/target/arm/as3525/sansa-fuzev2/button-fuzev2.c | 34 +++++++----- firmware/target/arm/as3525/sd-as3525.c | 6 +- 8 files changed, 126 insertions(+), 56 deletions(-) |
This task depends upon
Closed by Michael Sevakis (MikeS)
Sunday, 08 January 2012, 23:34 GMT+2
Reason for closing: Accepted
Additional comments about closing: r31642. No point in continuing with this in this venue. :-)
Sunday, 08 January 2012, 23:34 GMT+2
Reason for closing: Accepted
Additional comments about closing: r31642. No point in continuing with this in this venue. :-)
Any specific conditions you'd want me to test this patch for Mike?
Testing by recording a sine wave is most telling since missing samples are easily seen since the cycle is truncated and distinguishable from amplitude glitches. Some before and after WAV files would be good to link to on here.
If you need an updated patch because it won't apply to a newer revision, just give word.
http://jhmikes.cleansoap.org/A440%20-%203dB%20-%2060s%20mono.wav
Only thing I'm not certain about would be the final SVC stack size, which I just left at 256 words for now.