[LAD] revisiting system timer sound application wake up

08/08/2018 (ignore this date) PulseAudio tsched ================= Around December 2007 to February 2009 Lennart Poettering has asked some questions in alsa-devel mailing list in order to implement the timer based audio scheduling for PulseAudio. In 2008 he wrote an article named "What's Cooking in PulseAudio's glitch-free Branch". I have not found detailed documentation about PulseAudio timer wake up and I'm not sure about some implementation details. By using the emails from Lennart and his article a Documentation can start to grow. Do PulseAudio synchronize to sound device by adjusting the timer or the amount committed (application pointer)? The nice thing about the second case is that the period time (in application's view) is bonded to system clock instead of sound device's. What timer interface does PulseAudio use? timerfd? POSIX timers? Hardware issues =============== How the deviation of system and sound device clock is today? Perhaps someone that works with sound cards or SoCs can answer this. Do the most of today's hardware has the same clock for sound device and system? How sound devices deal with random accesses to their ring buffer. Do most of them allow writing/reading anywhere and anytime? How is the acurracy and precision of the hardware pointer returned by sound devices? Does SNDRV_PCM_INFO_BATCH flag reveals something about the above one? As PulseAudio runs in many Linux distributions today, it seems an interesting idea to implement an utility to collect some information regarding the above issues. Then make it available to the public. E.g. it would be possible to know the pointer acurracy for specific devices. SCHED_DEADLINE and timerfd ========================== There are a few works over there about SCHED_DEADLINE and audio: - This paper presented in Linux Audio Conference 2011: BAGNOLI, Giacomo; CUCINOTTA, Tommaso; FAGGIOLI, Dario. 2011. Low-Latency Audio on Linux by Means of Real-Time Scheduling. Dario Faggioli is one of the authors of SCHED_DEADLINE. - This presentation of Alessio Balsini: "Experimenting with the Android Audio Pipeline and SCHED_DEADLINE". OSPM 2018. Here is an overview: <https://lwn.net/Articles/754923/>. In SCHED_DEADLINE I assume there is no way to accurately adjust the timer. As well as there is no way to adjust when the first expiration will be. I think this is because of Constant Bandwidth Server algorithm. Must ask to some developer of this. Having this in mind, the only way to synchronize to sound device is by adjusting the amount read/written (application pointer). Timerfd on the other hand is fully adjustable. However, it can be preempted by a high priority task. Anyway I don't see that as a problem as it should ralely happen. Perhaps SCHED_DEADLINE is suitable for professional environment (aiming almost-zero glitches). Thoughts on this? Is there someone planning to implement SCHED_DEADLINE in PulseAudio? I'm currently working on both implementations (not for PulseAudio). See <https://github.com/ricardobiehl/simplesound>. Take a look at 'Documentation/timer_wakeup.rst', 'tools/timer_wakeup.c' and 'tools/deadline_wakeup.c'. 'tools/waveplay.c' play .wav files using the application wakeup method specified in 'tools/Makefile'. Documentation ============= Many of the points I've mentioned should get well covered by some documentation (e.g. ALSA, PulseAudio). Also, I think ALSA's internal (kernel-level) documentation needs to grow. I'm actually working on that, documenting some stuff as I'm developing a small sound library that interacts directly to ALSA in kernel, and the application wakeup using timerfd and SCHED_DEADLINE. Cheers!