mbox series

[00/18] ALSA: emu10k1 & emux: fixes related to wavetable playback

Message ID 20240401100742.506001-1-oswald.buddenhagen@gmx.de (mailing list archive)
Headers show
Series ALSA: emu10k1 & emux: fixes related to wavetable playback | expand

Message

Oswald Buddenhagen April 1, 2024, 10:07 a.m. UTC
this fixes the regression i introduced (though arguably, i just made it broken
in a different way), and then some more.

Oswald Buddenhagen (18):
  ALSA: emux: fix /proc teardown at module unload
  ALSA: emux: prune unused parameter from snd_soundfont_load_guspatch()
  ALSA: emux: fix validation of snd_emux.num_ports
  ALSA: emux: fix init of patch_info.truesize in load_data()
  ALSA: emu10k1: prune vestiges of
    SNDRV_SFNT_SAMPLE_{BIDIR,REVERSE}_LOOP support
  ALSA: emux: centralize & improve patch info validation
  ALSA: emux: improve patch ioctl data validation
  ALSA: emu10k1: move patch loader assertions into low-level functions
  ALSA: emu10k1: fix sample signedness issues in wavetable loader
  ALSA: emu10k1: fix playback of 8-bit wavetable samples
  ALSA: emu10k1: make wavetable sample playback start position exact
  ALSA: emu10k1: shrink blank space in front of wavetable samples
  ALSA: emu10k1: merge conditions in patch loader
  ALSA: emu10k1: fix wavetable offset recalculation
  ALSA: emu10k1: de-duplicate size calculations for 16-bit samples
  ALSA: emu10k1: improve cache behavior documentation
  ALSA: emu10k1: fix playback of short wavetable samples
  ALSA: emux: simplify snd_sf_list.callback handling

 include/sound/emu10k1.h              |  32 +++--
 include/sound/soundfont.h            |   2 +-
 sound/isa/sb/emu8000_patch.c         |  13 --
 sound/pci/emu10k1/emu10k1_callback.c |  10 +-
 sound/pci/emu10k1/emu10k1_patch.c    | 207 +++++++++++----------------
 sound/pci/emu10k1/memory.c           |  55 +++++--
 sound/synth/emux/emux.c              |   6 +-
 sound/synth/emux/emux_hwdep.c        |   3 +-
 sound/synth/emux/emux_oss.c          |   3 +-
 sound/synth/emux/emux_proc.c         |   1 +
 sound/synth/emux/emux_seq.c          |   6 +-
 sound/synth/emux/soundfont.c         |  73 +++++++---
 12 files changed, 216 insertions(+), 195 deletions(-)

--
2.42.0.419.g70bf8a5751

Comments

Takashi Iwai April 1, 2024, 10:51 a.m. UTC | #1
On Mon, 01 Apr 2024 12:07:24 +0200,
Oswald Buddenhagen wrote:
> 
> this fixes the regression i introduced (though arguably, i just made it broken
> in a different way), and then some more.
> 
> Oswald Buddenhagen (18):
>   ALSA: emux: fix /proc teardown at module unload
>   ALSA: emux: prune unused parameter from snd_soundfont_load_guspatch()
>   ALSA: emux: fix validation of snd_emux.num_ports
>   ALSA: emux: fix init of patch_info.truesize in load_data()
>   ALSA: emu10k1: prune vestiges of
>     SNDRV_SFNT_SAMPLE_{BIDIR,REVERSE}_LOOP support
>   ALSA: emux: centralize & improve patch info validation
>   ALSA: emux: improve patch ioctl data validation
>   ALSA: emu10k1: move patch loader assertions into low-level functions
>   ALSA: emu10k1: fix sample signedness issues in wavetable loader
>   ALSA: emu10k1: fix playback of 8-bit wavetable samples
>   ALSA: emu10k1: make wavetable sample playback start position exact
>   ALSA: emu10k1: shrink blank space in front of wavetable samples
>   ALSA: emu10k1: merge conditions in patch loader
>   ALSA: emu10k1: fix wavetable offset recalculation
>   ALSA: emu10k1: de-duplicate size calculations for 16-bit samples
>   ALSA: emu10k1: improve cache behavior documentation
>   ALSA: emu10k1: fix playback of short wavetable samples
>   ALSA: emux: simplify snd_sf_list.callback handling

Could you give Fixes tag in each commit if it's a regression fix for
the  corresponding commit?


thanks,

Takashi
Oswald Buddenhagen April 1, 2024, 11:18 a.m. UTC | #2
On Mon, Apr 01, 2024 at 12:51:32PM +0200, Takashi Iwai wrote:
>Could you give Fixes tag in each commit if it's a regression fix for
>the  corresponding commit?
>
i did. you'll see it when the later patches arrive (minor hiccup with
mail delivery on my end ...).

of course this won't help a lot with picking to stable, because the fix
actually depends on several of the prior patches. i can re-arrange the
series to minimize the hard dependency chain, but it will still be ~10
patches.

an alternative approach would be just reverting the offending patch and
re-fixing it as part of the subsequent series. the revert would be
easily pickable, but that merely replaces the current problem with the
(admittedly less audible) previous problem. your choice.
Takashi Iwai April 1, 2024, 11:44 a.m. UTC | #3
On Mon, 01 Apr 2024 13:18:36 +0200,
Oswald Buddenhagen wrote:
> 
> On Mon, Apr 01, 2024 at 12:51:32PM +0200, Takashi Iwai wrote:
> > Could you give Fixes tag in each commit if it's a regression fix for
> > the  corresponding commit?
> > 
> i did. you'll see it when the later patches arrive (minor hiccup with
> mail delivery on my end ...).
> 
> of course this won't help a lot with picking to stable, because the fix
> actually depends on several of the prior patches. i can re-arrange the
> series to minimize the hard dependency chain, but it will still be ~10
> patches.
>
> an alternative approach would be just reverting the offending patch and
> re-fixing it as part of the subsequent series. the revert would be
> easily pickable, but that merely replaces the current problem with the
> (admittedly less audible) previous problem. your choice.

Judging from the amount of patches, I prefer a quicker "fix" for the
known regression, so a revert-and-rewrite sounds more like a
reasonable approach.  Care to resubmit with that?


thanks,

Takashi