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

Takashi Iwai tiwai at suse.de
Wed Dec 12 15:51:23 CET 2012


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


More information about the Alsa-devel mailing list