| Message ID | 20240813120701.171743-1-ivan.orlov0322@gmail.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Introduce userspace-driven ALSA timers | expand |
On Tue, 13 Aug 2024 14:06:57 +0200, Ivan Orlov wrote: > > There are multiple possible timer sources which could be useful for > the sound stream synchronization: hrtimers, hardware clocks (e.g. PTP), > timer wheels (jiffies). Currently, using one of them to synchronize > the audio stream of snd-aloop module would require writing a > kernel-space driver which exports an ALSA timer through the > snd_timer interface. > > However, it is not really convenient for application developers, who may > want to define their custom timer sources for audio synchronization. > > For instance, we could have a network application which receives frames > and sends them to snd-aloop pcm device, and another application > listening on the other end of snd-aloop. It makes sense to transfer a > new period of data only when certain amount of frames is received > through the network, but definitely not when a certain amount of jiffies > on a local system elapses. Since all of the devices are purely virtual > it won't introduce any glitches and will help the application developers > to avoid using sample-rate conversion. > > This patch series introduces userspace-driven ALSA timers: virtual > timers which are created and controlled from userspace. The timer can > be created from the userspace using the new ioctl SNDRV_TIMER_IOCTL_CREATE. > After creating a timer, it becomes available for use system-wide, so it > can be passed to snd-aloop as a timer source (timer_source parameter > would be "-1.SNDRV_TIMER_GLOBAL_UDRIVEN.{timer_id}"). When the userspace > app decides to trigger a timer, it calls another ioctl > SNDRV_TIMER_IOCTL_TRIGGER on the file descriptor of a timer. It > initiates a transfer of a new period of data. > > Userspace-driven timers are associated with file descriptors. If the > application wishes to destroy the timer, it can simply release the file > descriptor of a virtual timer. > > I believe introducing new ioctl calls is quite inconvenient (as we have > a limited amount of them), but other possible ways of app <-> kernel > communication (like virtual FS) seem completely inappropriate for this > task (but I'd love to discuss alternative solutions). > > This patch series also updates the snd-aloop module so the global timers > can be used as a timer_source for it (it allows using userspace-driven > timers as timer source). > > V1 -> V2: > - Fix some problems found by Christophe Jaillet > <christophe.jaillet@wanadoo.fr> > V2 -> V3: > - Add improvements suggested by Takashi Iwai <tiwai@suse.de> > V3 -> V4: > - Address comments from Jaroslav Kysela <perex@perex.cz> and Mark Brown > <broonie@kernel.org> > V4 -> V5: > - Add missing error processing noticed by Takashi Iwai <tiwai@suse.de> > - Return timer file descriptor as part of the snd_timer_uinfo structure. > This is a more standard way of using ioctl interface, where the return > value of the ioctl is either 0 or an error code. > > Please, find the patch-specific changelog in the following patches. > > Ivan Orlov (4): > ALSA: aloop: Allow using global timers > Docs/sound: Add documentation for userspace-driven ALSA timers > ALSA: timer: Introduce virtual userspace-driven timers > selftests: ALSA: Cover userspace-driven timers with test Now applied to for-next branch. thanks, Takashi
There are multiple possible timer sources which could be useful for the sound stream synchronization: hrtimers, hardware clocks (e.g. PTP), timer wheels (jiffies). Currently, using one of them to synchronize the audio stream of snd-aloop module would require writing a kernel-space driver which exports an ALSA timer through the snd_timer interface. However, it is not really convenient for application developers, who may want to define their custom timer sources for audio synchronization. For instance, we could have a network application which receives frames and sends them to snd-aloop pcm device, and another application listening on the other end of snd-aloop. It makes sense to transfer a new period of data only when certain amount of frames is received through the network, but definitely not when a certain amount of jiffies on a local system elapses. Since all of the devices are purely virtual it won't introduce any glitches and will help the application developers to avoid using sample-rate conversion. This patch series introduces userspace-driven ALSA timers: virtual timers which are created and controlled from userspace. The timer can be created from the userspace using the new ioctl SNDRV_TIMER_IOCTL_CREATE. After creating a timer, it becomes available for use system-wide, so it can be passed to snd-aloop as a timer source (timer_source parameter would be "-1.SNDRV_TIMER_GLOBAL_UDRIVEN.{timer_id}"). When the userspace app decides to trigger a timer, it calls another ioctl SNDRV_TIMER_IOCTL_TRIGGER on the file descriptor of a timer. It initiates a transfer of a new period of data. Userspace-driven timers are associated with file descriptors. If the application wishes to destroy the timer, it can simply release the file descriptor of a virtual timer. I believe introducing new ioctl calls is quite inconvenient (as we have a limited amount of them), but other possible ways of app <-> kernel communication (like virtual FS) seem completely inappropriate for this task (but I'd love to discuss alternative solutions). This patch series also updates the snd-aloop module so the global timers can be used as a timer_source for it (it allows using userspace-driven timers as timer source). V1 -> V2: - Fix some problems found by Christophe Jaillet <christophe.jaillet@wanadoo.fr> V2 -> V3: - Add improvements suggested by Takashi Iwai <tiwai@suse.de> V3 -> V4: - Address comments from Jaroslav Kysela <perex@perex.cz> and Mark Brown <broonie@kernel.org> V4 -> V5: - Add missing error processing noticed by Takashi Iwai <tiwai@suse.de> - Return timer file descriptor as part of the snd_timer_uinfo structure. This is a more standard way of using ioctl interface, where the return value of the ioctl is either 0 or an error code. Please, find the patch-specific changelog in the following patches. Ivan Orlov (4): ALSA: aloop: Allow using global timers Docs/sound: Add documentation for userspace-driven ALSA timers ALSA: timer: Introduce virtual userspace-driven timers selftests: ALSA: Cover userspace-driven timers with test Documentation/sound/index.rst | 1 + Documentation/sound/utimers.rst | 126 +++++++++++ include/uapi/sound/asound.h | 17 +- sound/core/Kconfig | 10 + sound/core/timer.c | 225 ++++++++++++++++++++ sound/drivers/aloop.c | 2 + tools/testing/selftests/alsa/Makefile | 4 +- tools/testing/selftests/alsa/global-timer.c | 87 ++++++++ tools/testing/selftests/alsa/utimer-test.c | 164 ++++++++++++++ 9 files changed, 633 insertions(+), 3 deletions(-) create mode 100644 Documentation/sound/utimers.rst create mode 100644 tools/testing/selftests/alsa/global-timer.c create mode 100644 tools/testing/selftests/alsa/utimer-test.c