[alsa-devel] Intel HD: ALC662 noise-bug on FitPC2i

[Takashi Iwai]

At Thu, 13 Dec 2012 08:58:09 +0100,
Bent Bisballe Nyeng wrote:
> 
> On 12/12/12 20:11, Takashi Iwai wrote:
> > At Wed, 12 Dec 2012 19:30:58 +0100,
> > Bent Bisballe Nyeng wrote:
> >>
> >> On 12/12/12 15:51, Takashi Iwai wrote:
> >>> At Wed, 12 Dec 2012 15:45:46 +0100,
> >>> Bent Bisballe Nyeng wrote:
> >>>>
> >>>> On 12/12/12 15:25, Takashi Iwai wrote:
> >>>>> At Wed, 12 Dec 2012 14:14:57 +0100,
> >>>>> Bent Bisballe Nyeng wrote:
> >>>>>>
> >>>>>> On 12/12/12 14:05, Clemens Ladisch wrote:
> >>>>>>> Bent Bisballe Nyeng wrote:
> >>>>>>>> When recording, audible clicking sounds are present in the resulting
> >>>>>>>> audio data.
> >>>>>>>>
> >>>>>>>> The corruption are composed of approximately 10 samples, and the
> >>>>>>>> nature of the corrupted values are such that they could come from an
> >>>>>>>> earlier buffer (the corrupted data resemble wav forms).
> >>>>>>>
> >>>>>>> This looks like a problem with your HDA controller; either the memory
> >>>>>>> bus is overloaded so that some writes are dropped, or the hardware is
> >>>>>>> just buggy.
> >>>>>>>
> >>>>>>>
> >>>>>>> Regards,
> >>>>>>> Clemens
> >>>>>>
> >>>>>> I tried to record some audio using windows 7 and here the noise was not
> >>>>>> present indicating that it is not buggy hardware.
> >>>>>>
> >>>>>> Also, the system was not under load when the arecord call was made so if
> >>>>>> the memory bus was overloaded I need another way to verify this.
> >>>>>>
> >>>>>> Are there any additional (useful) debugging info I can subtract from the
> >>>>>> system that will help aiding the debugging process?
> >>>>>
> >>>>> Which sound backend are you using at all?  Does the problem appear if
> >>>>> you run with -Dhw for arecord?
> >>>>>
> >>>>> If it's using dsnoop or PulseAudio, the accuracy of DMA position
> >>>>> reporting plays a big role.  In that case, changing position_fix
> >>>>> option cures often.
> >>>>>
> >>>>> Takashi
> >>>>
> >>>> There are no sound servers installed on the pc in question (it is a
> >>>> 'lean' pc) so arecord should be using the hardware directly already.
> >>>
> >>> If you are using alsa-lib as is, it must be using dsnoop as default,
> >>> which is pretty different from hw.
> >>>
> >>>
> >>> Takashi
> >>
> >> Running arecord with -Dhw did not solve the issue.
> >>
> >> I played around with the buffer-size and have concluded that even with a
> >> very large buffer the ticks are still present, precisely one tick per
> >> buffer. This results in fever ticks with greater buffer sizes, but ticks
> >> non-the-less.
> >>
> >> Are there any special kernel parameters that I should set in order to
> >> make audio smooth?
> > 
> > As I wrote, check position_fix option.
> > 
> > 
> > Takashi
> 
> Setting the position_fix=2 (use the position-buffer) did the trick. It
> now records nice and smooth.
> 
> Thank you very much for your help Takashi.
> 
> In the kernel documentation on the intel hda driver it is described that
> the position_fix parameter defaults to using the position_buffer, but
> falls back to the LPIB register if the position_buffer appears dead.
> 
> Does this mean that on my specific chip the position_buffer seems dead
> even though it isn't and the LPIB register doesn't work correctly?

It might be that the driver chooses a different default mode,
depending on the controller.  For example, the latest driver chooses
position_fix=1 as default for Poulsbo (8086:811b) and Oaktrail
(8086:080a), or for AMD chips.

> Furthermore it is not clear to me what (if any?) the difference between
> the default value 0 and the value 2? Does 2 read the position-buffer
> without mmap and are therefore more CPU hungry than 0?

The mode 0 lets the driver check the validity of the position-buffer
read then switch automatically to LPIB if it looks incorrect.
Meanwhile the mode 2 is fixed to the position-buffer no matter what
value is read.

The choice of position-buffer or LPIB register isn't about the
performance.  It's whether you can get the right value or not.


Takashi