[LAD] revisiting system timer sound application wake up

[Ricardo Biehl Pasquali]

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!