Bug#1093390: linux-image-6.1.0-30-amd64: Audio with snd_pcm_oss choppy with -29 and -30; <= -28 is fine

[Salvatore Bonaccorso <carnil@debian.org>]

Control: tags -1 + upstream moreinfo
Control: found -1 6.13~rc6-1~exp1

Hi

On Wed, Feb 12, 2025 at 03:56:38PM -0500, Jason McCormick wrote:
> 
> > Looking through the changes beween 6.1.119 and 6.1.123 I don't spot
> > something obviously suspicious. There were no changes in sound/core/oss.
> 
> I ended up writing to Takashi Iwai who authored this patch: ALSA: usb-audio:
> Notify xrun for low-latency mode - kernel/git/stable/linux.git - Linux
> kernel stable tree <https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-6.1.y&id=8c28274b2dccdcf2fe29ef625f3c5f8a09e2b809>
> which is where we believe the issue originated. This was applied to the
> 6.1.y, 6.6.y, and 6.12.y branches along with the latest. Our project was
> able to confirm the issue in all three kernels. Takaski confirmed that this
> created a change in snd_usb_audio that "reveals the buffer underrun on the
> device that was ignored beforehand". But dealing with the underrun was
> causing the audio to be flushed with a bad chop. Loading the snd_usb_audio
> module with lowlatency=0 on systems that encounter the problem resolves the
> issue. Basically, it seems like fixing this issue in the kernel triggered
> other downstream audio issues interacting with USB audiot devices. It's
> added a new emphasis for us to get off of the last part of OSS
> once-and-for-all.

Have you asked this public on a mailing list? Can you reference the
current discussion, is Takaski planning to fix the regression?

If not, and given there is a workaround which will work enough and the
fade off snd_pcm_oss, should we close this bug?

Regards,
Salvatore