Audio playback is a low load periodic application that has little/no variation in period and load over time. It consists of tasks involved in decoding the audio stream and communicating with audio frameworks and drivers.
Performance Criteria All tasks must have completed before the next request to fill the audio buffer. Most modern hardware should be able to deal with the load even at the lowest P-state. Task behaviour The task load pattern period is dictated by the audio interrupt. On an example modern ARM based system this occurs every ~6 ms. The decoding work is triggered every fourth interrupt, i.e. a ~24 ms period. No tasks are scheduled at the intermediate interrupts. The tasks involved are: Main audio framework task (AudioOut): The first task to be scheduled after the interrupt and continues running until decoding has completed. That is ~5 ms. Runs at nice=-19. Audio framework task 2 (AudioTrack): Woken up by the main task ~250-300 us after the main audio task is scheduled. Runs for ~300 us at nice=-16. Decoder task (mp3.decoder): Woken up by the audio task 2 when that finishes (serialized). Runs for ~1 ms until it wakes a third Android task on which it blocks and continues for another ~150 us afterwards (serialized). Runs at nice=-2. Android task 3 (OMXCallbackDisp): Woken by decoder task. Runs for ~300 us at nice=-2. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
