summaryrefslogtreecommitdiff
path: root/fs/smb/client/fscache.h
diff options
context:
space:
mode:
authorOswald Buddenhagen <oswald.buddenhagen@gmx.de>2024-04-01 17:58:05 +0300
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>2024-04-10 17:36:00 +0300
commit0f28afed9f9d71a3f97df94b9691ac49f49ec887 (patch)
tree320774fb594981fc69dbeb3a604425a8ee133631 /fs/smb/client/fscache.h
parentf3e692c8c24a7161667413c2f75236d616317ae2 (diff)
downloadlinux-0f28afed9f9d71a3f97df94b9691ac49f49ec887.tar.xz
Revert "ALSA: emu10k1: fix synthesizer sample playback position and caching"
[ Upstream commit 03f56ed4ead162551ac596c9e3076ff01f1c5836 ] As already anticipated in the original commit, playback was broken for very short samples. I just didn't expect it to be an actual problem, because we're talking about less than 1.5 milliseconds here. But clearly such wavetable samples do actually exist. The problem was that for such short samples we'd set the current position beyond the end of the loop, so we'd run off the end of the sample and play garbage. This is a bigger (more audible) problem than the original one, which was that we'd start playback with garbage (whatever was still in the cache), which would be mostly masked by the note's attack phase. So revert to the old behavior for now. We'll subsequently fix it properly with a bigger patch series. Note that this isn't a full revert - the dead code is not re-introduced, because that would be silly. Fixes: df335e9a8bcb ("ALSA: emu10k1: fix synthesizer sample playback position and caching") Link: https://bugzilla.kernel.org/show_bug.cgi?id=218625 Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Message-ID: <20240401145805.528794-1-oswald.buddenhagen@gmx.de> Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
Diffstat (limited to 'fs/smb/client/fscache.h')
0 files changed, 0 insertions, 0 deletions