Skip to content

L
linux
Switch branch/tag
  1. 09 Jun, 2021 8 commits
  3. 08 Jun, 2021 5 commits
  5. 07 Jun, 2021 9 commits
  7. 06 Jun, 2021 3 commits
  9. 05 Jun, 2021 5 commits
  11. 04 Jun, 2021 1 commit
  13. 03 Jun, 2021 2 commits
  15. 02 Jun, 2021 7 commits
    • Dongliang Mu's avatar
      ALSA: control led: fix memory leak in snd_ctl_led_register · 3ae72f6a
      Dongliang Mu authored 
      The snd_ctl_led_sysfs_add and snd_ctl_led_sysfs_remove should contain
the refcount operations in pair. However, snd_ctl_led_sysfs_remove fails
to decrease the refcount to zero, which causes device_release never to
be invoked. This leads to memory leak to some resources, like struct
device_private. In addition, we also free some other similar memory
leaks in snd_ctl_led_init/snd_ctl_led_exit.

Fix this by replacing device_del to device_unregister
in snd_ctl_led_sysfs_remove/snd_ctl_led_init/snd_ctl_led_exit.

Note that, when CONFIG_DEBUG_KOBJECT_RELEASE is enabled, put_device will
call kobject_release and delay the release of kobject, which will cause
use-after-free when the memory backing the kobject is freed at once.

Reported-by: syzbot+08a7d8b51ea048a74ffb@syzkaller.appspotmail.com
Fixes: a135dfb5 ("ALSA: led control - add sysfs kcontrol LED marking layer")
Signed-off-by: default avatarDongliang Mu <mudongliangabcd@gmail.com>
Reviewed-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: default avatarJaroslav Kysela <perex@perex.cz>
Link: https://lore.kernel.org/r/20210602034136.2762497-1-mudongliangabcd@gmail.comSigned-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      3ae72f6a
    • Takashi Iwai's avatar
      ALSA: usb-audio: Reduce latency at playback start · 9ce650a7
      Takashi Iwai authored 
      USB-audio driver behaves a bit strangely for the playback stream --
namely, it starts sending silent packets at PCM prepare state while
the actual data is submitted at first when the trigger START is kicked
off.  This is a workaround for the behavior where URBs are processed
too quickly at the beginning.  That is, if we start submitting URBs at
trigger START, the first few URBs will be immediately completed, and
this would result in the immediate period-elapsed calls right after
the start, which may confuse applications.

OTOH, submitting the data after silent URBs would, of course, result
in a certain delay of the actual data processing, and this is rather
more serious problem on modern systems, in practice.

This patch tries to revert the workaround and lets the URB submission
starting at PCM trigger for the playback again.  As far as I've tested
with various backends (native ALSA, PA, JACK, PW), I haven't seen any
problems (famous last words :)

Note that the capture stream handling needs no such workaround, since
the capture is driven per received URB.

Link: https://lore.kernel.org/r/20210601162457.4877-6-tiwai@suse.deSigned-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      9ce650a7
    • Takashi Iwai's avatar
      ALSA: usb-audio: Factor out DSD bitrev copy function · 4f083917
      Takashi Iwai authored 
      Just minor code refactoring.  Like DOP DSD code, it can be better in a
separate function for code readability.

Link: https://lore.kernel.org/r/20210601162457.4877-5-tiwai@suse.deSigned-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      4f083917
    • Takashi Iwai's avatar
      ALSA: usb-audio: Refactoring delay account code · e8a8f09c
      Takashi Iwai authored 
      The PCM delay accounting in USB-audio driver is a bit complex to
follow, and this is an attempt to improve the readability and provide
some potential fix.

Basically, the PCM position delay is calculated from two factors: the
in-flight data on URBs and the USB frame counter.  For the playback
stream, we advance the hwptr already at submitting URBs.  Those
"in-flight" data amount is now tracked, and this is used as the base
value for the PCM delay correction.  The in-flight data is decreased
again at URB completion in return.  For the capture stream, OTOH,
there is no in-flight data, hence the delay base is zero.

The USB frame counter is used in addition for correcting the current
position.  The reference frame counter is updated at each submission
and receiving time, and the difference from the current counter value
is taken into account.

In this patch, each in-flight data bytes is recorded in the new
snd_usb_ctx.queued field, and the total in-flight amount is tracked in
snd_usb_substream.inflight_bytes field, as the replacement of
last_delay field.

Note that updating the hwptr after URB completion doesn't work for
PulseAudio who tries to scratch the buffer on the fly; USB-audio is
basically a double-buffer implementation, hence the scratching the
buffer can't work for the already submitted data.  So we always update
hwptr beforehand.  It's not ideal, but the delay account should give
enough correctness.

Link: https://lore.kernel.org/r/20210601162457.4877-4-tiwai@suse.deSigned-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      e8a8f09c
    • Takashi Iwai's avatar
      ALSA: usb-audio: Pre-calculate buffer byte size · d303c5d3
      Takashi Iwai authored 
      There are a bunch of lines calculating the buffer size in bytes at
each time.  Keep the value in subs->buffer_bytes and use it
consistently for the code simplicity.

Link: https://lore.kernel.org/r/20210601162457.4877-3-tiwai@suse.deSigned-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      d303c5d3
    • Takashi Iwai's avatar
      ALSA: usb-audio: Make snd_usb_pcm_delay() static · cdebd553
      Takashi Iwai authored 
      It's a local function, let's make it static.

Link: https://lore.kernel.org/r/20210601162457.4877-2-tiwai@suse.deSigned-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      cdebd553
    • Takashi Sakamoto's avatar
      ALSA: firewire-motu: sequence replay for source packet header · f2ac3b83
      Takashi Sakamoto authored 
      This commit takes ALSA firewire-motu driver to perform sequence replay for
media clock recovery.

Unlike the other types of device, the devices in MOTU FireWire series
require two levels of sequence replay; the sequence of the number of
data blocks per packet and the sequence of source packet header per data
block. The former is already cached by ALSA IEC 61883-1/6 packet streaming
engine and ready to be replayed. The latter is also cached by ALSA
firewire-motu driver itself with a previous patch. This commit takes
the driver to replay both of them from the caches.

The sequence replay is tested with below models:

 * 828 mkII
 * Traveler
 * UltraLite
 * 828 mk3 FireWire
 * 828 mk3 Hybrid (except for high sampling transfer frequency
 * UltraLite mk3 FireWire
 * 4pre
 * AudioExpress

Unfortunately, below models still don't generate better sound, requires
more work:

 * 8pre
 * 828 mk3 Hybrid at high sampling transfer frequency

As long as I know, MOTU protocol version 1 requires extra care of the
format of data block, thus below models are not supported yet in this
time:

 * 828
 * 896
Signed-off-by: default avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20210602013406.26442-4-o-takashi@sakamocchi.jpSigned-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      f2ac3b83
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7