<div dir="ltr"><div>Yep at least  for now  it  works  nicely.</div><div>On grub boot I did  the  e  thing  and   added<br></div><div>

    intel_iommu=on,igfx_off</div><div>to  the  end  of  the  line  starting with linux</div><div><br></div><div>So  how   does  that  get   fixed on  the   Bullseye  update  and  the  live/install image?<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 2 Jul 2021 at 16:30, Bryan Cebuliak <<a href="mailto:bryan.cebuliak@gmail.com">bryan.cebuliak@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>This Haswell related bug sounds very similar and possibly relevant to my Haswell machine:<br></div><div><a href="https://bugzilla.kernel.org/show_bug.cgi?id=60769" target="_blank">https://bugzilla.kernel.org/show_bug.cgi?id=60769</a></div><div><a href="https://bugs.freedesktop.org/show_bug.cgi?id=94804" target="_blank">https://bugs.freedesktop.org/show_bug.cgi?id=94804</a></div><div><br></div><div>"...</div><div><div><span>
          <span><span>Alexander E. Patrakov</span>
</span>
        </span>

        <span>
        </span>

        <span>
          2013-10-08 09:55:09 UTC
        </span>

      </div>




<pre>I have not tried your patch, but found that intel_iommu=on,igfx_off snd_hda_intel.align_buffer_size=1 fixes the problem. Should I still try the patch?..."<br>..."<br></pre><pre>and<br>"...<br></pre><div><span>
          <span><span>Alexander E. Patrakov</span>
</span>
        </span>

        <span>
        </span>

        <span>
          2016-04-03 06:44:56 UTC
        </span>

      </div>




Haswell HDMI audio users are affected by a longstanding kernel IOMMU bug: <a href="https://bugzilla.kernel.org/show_bug.cgi?id=60769" target="_blank">https://bugzilla.kernel.org/show_bug.cgi?id=60769</a> . To make sure that your report is not a duplicate, please add the following kernel command line option and reboot:

    intel_iommu=on,igfx_off

If that alone doesn't help, please try:

    intel_iommu=on,igfx_off snd_hda_intel.align_buffer_size=1</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 2 Jul 2021 at 14:08, Bryan Cebuliak <<a href="mailto:bryan.cebuliak@gmail.com" target="_blank">bryan.cebuliak@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div>Since update  from  Buster to  Bullseye on  hard  disc  and  on  live  USB   boot  when  using Built-in Audio Digital Stereo(HDMI 2) on  playback for  Youtube  and  other   video streams I  have   noticed variable skipping of  audio and  video ,  audio  out of   sync, video racing   at   fast  forward pace.  This    does  not   happen    when   playback  is  on Built-in  Audio Analog Stereo.  However  I   would  like  audio  to  come  through the  HDMI  device [TV].  Using  the  left over old  Debian 10 kernel on  the   Bullseye   system still  shows   same   problem.  Ubuntu 20.04  on  the   same   system has  no  issues.  What  is  the  regression  from  Debian 10  to   11?  I note  the  configuration Analogue  Stereo Duplex  is   unavailable in  the  Bullseye  version  but  available  and  selected in Buster. Changing  to  and  from  this  in Buster causes no problems  in  playback<br></div><div>Your  bleeding user</div><div>Bryan Cebuliak<br></div><div><br></div><div>On Tue, 11 Dec 2018 09:55:55 -0500 "Mike Fuller" <<a href="mailto:fuller.michael.d@gmail.com" target="_blank">fuller.michael.d@gmail.com</a>> wrote:.</div>> Also for what it's worth, hw_parms output during playback on the same<br>> device:<br>> <br>> On Debian 9 / CentOS 7.5 / Ubuntu 16.04:<br>>        access: MMAP_INTERLEAVED<br>>  format: S16_LE<br>>    subformat: STD<br>>    channels: 2<br>>       rate: 48000 (48000/1)<br>>     period_size: 44096<br>>        buffer_size: 88192<br>> <br>> On Ubuntu 18.04:<br>>  access: MMAP_INTERLEAVED<br>>  format: S32_LE<br>>    subformat: STD<br>>    channels: 2<br>>       rate: 48000 (48000/1)<br>>     period_size: 1024<br>>         buffer_size: 16384<br>> <br>> I don't know why but...this is the only discernable difference I've been<br>> able to find in all my testing. I've been unable to manually set format,<br>> period_size, or buffer-size parameters in Debian's pulseaudio configuration<br>> files (I am pretty sure its just user error). <br>> <br>> <br>> <br></div>
</blockquote></div>
</blockquote></div>