lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <87a5ha1cnn.wl-tiwai@suse.de>
Date: Sun, 18 Aug 2024 10:02:52 +0200
From: Takashi Iwai <tiwai@...e.de>
To: Ivan Orlov <ivan.orlov0322@...il.com>
Cc: perex@...ex.cz,
	tiwai@...e.com,
	corbet@....net,
	broonie@...nel.org,
	shuah@...nel.org,
	linux-kselftest@...r.kernel.org,
	linux-doc@...r.kernel.org,
	linux-sound@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	christophe.jaillet@...adoo.fr,
	aholzinger@....de
Subject: Re: [PATCH v5 0/4] Introduce userspace-driven ALSA timers

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@...adoo.fr>
> V2 -> V3:
> - Add improvements suggested by Takashi Iwai <tiwai@...e.de>
> V3 -> V4:
> - Address comments from Jaroslav Kysela <perex@...ex.cz> and Mark Brown
> <broonie@...nel.org>
> V4 -> V5:
> - Add missing error processing noticed by Takashi Iwai <tiwai@...e.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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ