Comment 315 for bug 1801540

(In reply to Takashi Iwai from comment #273)
> Hmm, would it be only about playback? That is, restricting the workaround
> only to capture stream works better?
>
> --- a/sound/pci/hda/hda_controller.c
> +++ b/sound/pci/hda/hda_controller.c
> @@ -617,7 +617,8 @@ static int azx_pcm_open(struct snd_pcm_substream
> *substream)
> * 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)
> + if ((chip->driver_caps & AZX_DCAPS_AMD_WORKAROUND) &&
> + substream->stream == SNDRV_PCM_STREAM_CAPTURE)
> runtime->hw.info |= SNDRV_PCM_INFO_BATCH;
>
> if (chip->align_buffer_size)
>
>
> In anyway, we need to know this change makes sense at all. IOW, people need
> to check whether this causes yet another regression on the devices that have
> worked with BATCH workaround.

With the standard flags, Discord is perfect, Steam has stutters for the first minute and a bit of delay (500 ms).

With the batch flag only on the capture stream, Steam is perfect, Discord has delayed audio.

With the batch flag only on the playback stream, same thing with both of them (first case).