Instead of open-coding for getting the timer resolution, use the
standard snd_timer_resolution() helper.
The original code falls back to the callback function when the
resolution is zero, but it must be always so when the callback
function is defined. So this should be no functional change.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The SNDRV_SEQ_IOCTL_SET_QUEUE_TEMPO ioctl sets the tempo and the ppq
in a single call, while the current implementation updates each value
one by one. This is a bit racy, and also suboptimal from the
performance POV, as each call does re-acquire the lock and invokes
the update of ALSA timer resolution.
This patch reorganizes the code slightly so that we change both the
tempo and the ppq in a shot. The skew value can be put into the same
lock, but this is rather a rarely used feature and completely
independent from the temp/ppq (it's evaluated only in the interrupt),
so it's left as it was.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The use of snd_BUG_ON() in ALSA sequencer timer may lead to a spurious
WARN_ON() when a slave timer is deployed as its backend and a
corresponding master timer stops meanwhile. The symptom was triggered
by syzkaller spontaneously.
Since the NULL timer is valid there, rip off snd_BUG_ON().
Reported-by: syzbot <syzkaller@googlegroups.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The recent rewrite of the sequencer time accounting using timespec64
in the commit [3915bf294652: ALSA: seq_timer: use monotonic times
internally] introduced a bad regression. Namely, the time reported
back doesn't increase but goes back and forth.
The culprit was obvious: the delta is stored to the result (cur_time =
delta), instead of adding the delta (cur_time += delta)!
Let's fix it.
Fixes: 3915bf2946 ('ALSA: seq_timer: use monotonic times internally')
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=177571
Reported-by: Yves Guillemot <yc.guillemot@wanadoo.fr>
Cc: <stable@vger.kernel.org> # v4.8+
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The sequencer client manager reports timestamps in units of unsigned
32-bit seconds/nanoseconds, but that does not suffer from the y2038
overflow because it stores only the delta since the 'last_update'
time was recorded.
However, the use of the do_gettimeofday() function is problematic
and we have to replace it to avoid the overflow on on 32-bit
architectures.
This uses 'struct timespec64' to record 'last_update', and changes
the code to use monotonic timestamps that do not suffer from leap
seconds and settimeofday updates.
As a side-effect, the code can now use the timespec64_sub() helper
and become more readable and also avoid a multiplication to convert
from microseconds to nanoseconds.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
ALSA sequencer may open/close and control ALSA timer instance
dynamically either via sequencer events or direct ioctls. These are
done mostly asynchronously, and it may call still some timer action
like snd_timer_start() while another is calling snd_timer_close().
Since the instance gets removed by snd_timer_close(), it may lead to
a use-after-free.
This patch tries to address such a race by protecting each
snd_timer_*() call via the existing spinlock and also by avoiding the
access to timer during close call.
BugLink: http://lkml.kernel.org/r/CACT4Y+Z6RzW5MBr-HUdV-8zwg71WQfKTdPpYGvOeS7v4cyurNQ@mail.gmail.com
Reported-by: Dmitry Vyukov <dvyukov@google.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
We may disable proc fs only for sound part, to reduce ALSA
memory footprint. So add CONFIG_SND_PROC_FS and replace the
old CONFIG_PROC_FSs in alsa code.
With sound proc fs disabled, we can save about 9KB memory
size on X86_64 platform.
Signed-off-by: Jie Yang <yang.jie@intel.com>
Reviewed-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The kernel memory allocators already report the errors when the
requested allocation fails, thus we don't need to warn it again in
each caller side.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
As snd_seq_timer_set_tick_resolution() is always called with the same
three fields of struct snd_seq_timer, it suffices to give that as the
only parameter.
Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
Kill snd_assert() in sound/core/*, either removed or replaced with
if () with snd_BUG_ON().
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
This header file exists only for some hacks to adapt alsa-driver
tree. It's useless for building in the kernel. Let's move a few
lines in it to sound/core.h and remove it.
With this patch, sound/driver.h isn't removed but has just a single
compile warning to include it. This should be really killed in
future.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
Modules: ALSA<-OSS emulation,ALSA sequencer,ALSA<-OSS sequencer
Optimize the code when compiled without CONFIG_PROC_FS (in seq and oss
emulation parts).
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Modules: ALSA sequencer
When no default timer frequency has been set, initialize_timer() just
uses the maximum frequency supported by the timer, which is ridiculously
high on 96 kHz timers.
This patch introduces a default frequency of 1000 Hz for this case, and
makes sure that a frequency set by the user isn't too high.
Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Modules: ALSA sequencer
Remove the last parameter of snd_seq_timer_set_tick_resolution()
because it is always one.
Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
PCM Midlevel,ALSA Core,Timer Midlevel,ALSA sequencer,Virtual Midi
This patch contains the following possible cleanups:
- make needlessly global code static
- #if 0 the following unused global functions
- remove the following unneeded EXPORT_SYMBOL's
Signed-off-by: Adrian Bunk <bunk@stusta.de>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.
Let it rip!
Takashi Iwai