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

[Bent Bisballe Nyeng]

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?

I attached my kernel config just in case.

Kind regards
Bent Bisballe Nyeng

-------------- next part --------------
A non-text attachment was scrubbed...
Name: config.gz
Type: application/x-gzip
Size: 15708 bytes
Desc: not available
URL: <http://mailman.alsa-project.org/pipermail/alsa-devel/attachments/20121212/60e95cbd/attachment-0001.gz>