John Covici wrote:
> Hi. I got a message from my sound card module today, but I can't find
> what to change -- seems not to be a kernel config.
> snd_hda_intel 0000:00:1f.3: IRQ timing workaround is activated for
> card #0. Suggest a bigger bdl_pos_adj.
>
> What the heck is that?
>
> Thanks in advance for any suggestions.
>
I'm clueless what this means. I just used a search engine. Here goes.
bdl_pos_adj
Specifies the DMA IRQ timing delay in samples. Passing -1 will make
the driver to choose the appropriate value based on the controller chip.
https://www.kernel.org/doc/html/latest/sound/alsa-configuration.html#module-snd-hda-intel and this:
HD-Audio Controller
DMA-Position Problem
The most common problem of the controller is the inaccurate DMA pointer
reporting. The DMA pointer for playback and capture can be read in two
ways, either via a LPIB register or via a position-buffer map. As
default the driver tries to read from the io-mapped position-buffer, and
falls back to LPIB if the position-buffer appears dead. However, this
detection isn't perfect on some devices. In such a case, you can change
the default method via position_fix option.
position_fix=1 means to use LPIB method explicitly. position_fix=2 means
to use the position-buffer. position_fix=3 means to use a combination of
both methods, needed for some VIA controllers. The capture stream
position is corrected by comparing both LPIB and position-buffer values.
position_fix=4 is another combination available for all controllers, and
uses LPIB for the playback and the position-buffer for the capture
streams. position_fix=5 is specific to Intel platforms, so far, for
Skylake and onward. It applies the delay calculation for the precise
position reporting. position_fix=6 is to correct the position with the
fixed FIFO size, mainly targeted for the recent AMD controllers. 0 is
the default value for all other controllers, the automatic check and
fallback to LPIB as described in the above. If you get a problem of
repeated sounds, this option might help.
In addition to that, every controller is known to be broken regarding
the wake-up timing. It wakes up a few samples before actually processing
the data on the buffer. This caused a lot of problems, for example, with
ALSA dmix or JACK. Since 2.6.27 kernel, the driver puts an artificial
delay to the wake up timing. This delay is controlled via bdl_pos_adj
option.
When bdl_pos_adj is a negative value (as default), it's assigned to an
appropriate value depending on the controller chip. For Intel chips,
it'd be 1 while it'd be 32 for others. Usually this works. Only in case
it doesn't work and you get warning messages, you should change this
parameter to other values.
https://www.kernel.org/doc/html/latest/sound/hd-audio/notes.html Does that help any?
Dale
:-) :-)