Comment 337 for bug 1801540

(In reply to Rob McCathie from comment #296)
> Just thought i'd update on my situation, i've now tested that it is only the
> Pulse changing to batch mode that causes my issue. So i'm no longer running
> the patch i posted earlier, rather now i do this:
>
>
>
> diff -Naur a/sound/pci/hda/hda_controller.c b/sound/pci/hda/hda_controller.c
> --- a/sound/pci/hda/hda_controller.c 2021-02-10 19:29:23.000000000 +1100
> +++ b/sound/pci/hda/hda_controller.c 2021-02-14 00:38:36.602466066 +1100
> @@ -609,13 +609,6 @@
> 20,
> 178000000);
>
> - /* by some reason, the playback stream stalls on PulseAudio with
> - * tsched=1 when a capture stream triggers. Until we figure out the
> - * real cause, disable tsched mode by telling the PCM info flag.
> - */
> - if (chip->driver_caps & AZX_DCAPS_AMD_WORKAROUND)
> - runtime->hw.info |= SNDRV_PCM_INFO_BATCH;
> -
> if (chip->align_buffer_size)
> /* constrain buffer sizes to be multiple of 128
> bytes. This is more efficient in terms of memory
>
>
>
> ------------------
>
> It's my opinion that the above reversion should be done in mainline. A
> bugfix that fixes a problem over here but creates a new one over there isn't
> a bugfix at all.

FWIW, on my system this improves the recording start, removing completely audio clicks at the start of recording (no audio stalls in reproduction, even with multiple streams on acquisition while playing audio), so for my use case it's fine, but someone with PulseAudio should test this and see if it causes regressions.