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