Intel HD: ALC662 noise-bug on FitPC2i

Intel HD: ALC662 noise-bug on FitPC2i

[Bent Bisballe Nyeng]

[-- Attachment #1: Type: text/plain, Size: 8847 bytes --]

Hi list

I have tried to access the bugtracker at
https://bugtrack.alsa-project.org/alsa-bug for a while without luck, so
now I will try to post the bug here...

Problem:
When recording, audible clicking sounds are present in the resulting
audio data.

Analysis:
When recording at 48kHz 1024 samples per channel are returned by the
snd_pcm_readi function.
I made a test app that wrote zeros into the first 20 samples of each
recorded buffer in order to 'mark' the beggining of each buffer in the
output file and it appears that the clicking noise come from buffer
corruption at position 1024-160 samples (160 samples from the end of
the buffer).

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).

Sometimes only a single sample seem to be corrupted (see
wavform3.png), but sometimes several (see wavform1.png and
wavform2.png).

Usually the number of corrupted samples are the same for both channels.

A sample recording produced by the command:
arecord -c 2 -t raw -f S16_LE -r 48000 --disable-resample -d 10
alc662-noise-bug.raw
The resulting file can be fetched at
 http://www.aasimon.org/public/alc662-noise-bug.raw (too big to send by
email)

Hardware:
Fit-PC2i (Atom Z530).
Intel HD driver with ALC662 codec.

Kernel (uname -a):
Linux InterCom 3.2.1-gentoo-r2-fitpc2i #1 SMP Tue Dec 11 09:10:23 i686
Intel(R) Atom(TM) CPU Z530 @ 1.60GHz GenuineIntel GNU/Linux

Alsa-lib and utils used were v.1.0.24, but tests with kernel-3.5.7 and
alsa-lib/utils-1.0.25 has also been performed with similiar results.

Kernel compiled with asound debug (from .config):
CONFIG_SND_DEBUG=y
CONFIG_SND_DEBUG_VERBOSE=y
CONFIG_SND_PCM_XRUN_DEBUG=y

Log output with "echo 127 > /proc/asound/card0/pcm0c/xrun_debug":

Command run:
(arecord -c 2 -t raw -r 48000 -d 0.1 out.raw &) ; sleep 0.015; killall
arecord

Dec 10 15:58:46 InterCom kernel: [ 1733.745094] hda-intel:
azx_pcm_prepare: bufsize=0x10000, format=0x21
Dec 10 15:58:46 InterCom kernel: [ 1733.745109] hda_codec_setup_stream:
NID=0x8, stream=0x2, channel=0, format=0x21
Dec 10 15:58:46 InterCom kernel: [ 1733.749510] hwptr_update:
pcmC0D0c:0: pos=209/1024/8192, hwptr=209/0/209/0
Dec 10 15:58:46 InterCom kernel: [ 1733.749553] hwptr_update:
pcmC0D0c:0: pos=212/1024/8192, hwptr=3/209/212/0
Dec 10 15:58:46 InterCom kernel: [ 1733.749609] hwptr_update:
pcmC0D0c:0: pos=214/1024/8192, hwptr=2/212/214/0
Dec 10 15:58:46 InterCom kernel: [ 1733.749645] hwptr_update:
pcmC0D0c:0: pos=216/1024/8192, hwptr=2/214/216/0
Dec 10 15:58:46 InterCom kernel: [ 1733.749664] hwptr_update:
pcmC0D0c:0: pos=217/1024/8192, hwptr=1/216/217/0
Dec 10 15:58:46 InterCom kernel: [ 1733.749694] hwptr_update:
pcmC0D0c:0: pos=219/1024/8192, hwptr=2/217/219/0
Dec 10 15:58:46 InterCom kernel: [ 1733.749719] hwptr_update:
pcmC0D0c:0: pos=220/1024/8192, hwptr=1/219/220/0
Dec 10 15:58:46 InterCom kernel: [ 1733.749738] hwptr_update:
pcmC0D0c:0: pos=221/1024/8192, hwptr=1/220/221/0
Dec 10 15:58:46 InterCom kernel: [ 1733.749767] hwptr_update:
pcmC0D0c:0: pos=222/1024/8192, hwptr=1/221/222/0
Dec 10 15:58:46 InterCom kernel: [ 1733.749793] hwptr_update:
pcmC0D0c:0: pos=223/1024/8192, hwptr=1/222/223/0
Dec 10 15:58:46 InterCom kernel: [ 1733.749813] hwptr_update:
pcmC0D0c:0: pos=224/1024/8192, hwptr=1/223/224/0
Dec 10 15:58:46 InterCom kernel: [ 1733.749841] hwptr_update:
pcmC0D0c:0: pos=226/1024/8192, hwptr=2/224/226/0
Dec 10 15:58:46 InterCom kernel: [ 1733.749867] hwptr_update:
pcmC0D0c:0: pos=227/1024/8192, hwptr=1/226/227/0
Dec 10 15:58:46 InterCom kernel: [ 1733.749887] hwptr_update:
pcmC0D0c:0: pos=228/1024/8192, hwptr=1/227/228/0
Dec 10 15:58:46 InterCom kernel: [ 1733.749914] hwptr_update:
pcmC0D0c:0: pos=229/1024/8192, hwptr=1/228/229/0
Dec 10 15:58:46 InterCom kernel: [ 1733.749940] hwptr_update:
pcmC0D0c:0: pos=230/1024/8192, hwptr=1/229/230/0
Dec 10 15:58:46 InterCom kernel: [ 1733.749961] hwptr_update:
pcmC0D0c:0: pos=231/1024/8192, hwptr=1/230/231/0
Dec 10 15:58:46 InterCom kernel: [ 1733.749989] hwptr_update:
pcmC0D0c:0: pos=233/1024/8192, hwptr=2/231/233/0
Dec 10 15:58:46 InterCom kernel: [ 1733.752935] hwptr_update:
pcmC0D0c:0: pos=374/1024/8192, hwptr=141/233/374/0
Dec 10 15:58:46 InterCom kernel: [ 1733.752964] hwptr_update:
pcmC0D0c:0: pos=376/1024/8192, hwptr=2/374/376/0
Dec 10 15:58:46 InterCom kernel: [ 1733.753002] hwptr_update:
pcmC0D0c:0: pos=377/1024/8192, hwptr=1/376/377/0
Dec 10 15:58:46 InterCom kernel: [ 1733.754067] hwptr_update:
pcmC0D0c:0: pos=428/1024/8192, hwptr=51/377/428/0
Dec 10 15:58:46 InterCom kernel: [ 1733.754092] hwptr_update:
pcmC0D0c:0: pos=430/1024/8192, hwptr=2/428/430/0
Dec 10 15:58:46 InterCom kernel: [ 1733.754129] hwptr_update:
pcmC0D0c:0: pos=431/1024/8192, hwptr=1/430/431/0
Dec 10 15:58:46 InterCom kernel: [ 1733.754156] hwptr_update:
pcmC0D0c:0: pos=433/1024/8192, hwptr=2/431/433/0
Dec 10 15:58:46 InterCom kernel: [ 1733.754175] hwptr_update:
pcmC0D0c:0: pos=434/1024/8192, hwptr=1/433/434/0
Dec 10 15:58:46 InterCom kernel: [ 1733.754204] hwptr_update:
pcmC0D0c:0: pos=435/1024/8192, hwptr=1/434/435/0
Dec 10 15:58:46 InterCom kernel: [ 1733.754230] hwptr_update:
pcmC0D0c:0: pos=436/1024/8192, hwptr=1/435/436/0
Dec 10 15:58:46 InterCom kernel: [ 1733.754250] hwptr_update:
pcmC0D0c:0: pos=437/1024/8192, hwptr=1/436/437/0
Dec 10 15:58:46 InterCom kernel: [ 1733.754278] hwptr_update:
pcmC0D0c:0: pos=439/1024/8192, hwptr=2/437/439/0
Dec 10 15:58:46 InterCom kernel: [ 1733.754304] hwptr_update:
pcmC0D0c:0: pos=440/1024/8192, hwptr=1/439/440/0
Dec 10 15:58:46 InterCom kernel: [ 1733.754324] hwptr_update:
pcmC0D0c:0: pos=441/1024/8192, hwptr=1/440/441/0
Dec 10 15:58:46 InterCom kernel: [ 1733.754351] hwptr_update:
pcmC0D0c:0: pos=442/1024/8192, hwptr=1/441/442/0
Dec 10 15:58:46 InterCom kernel: [ 1733.754377] hwptr_update:
pcmC0D0c:0: pos=443/1024/8192, hwptr=1/442/443/0
Dec 10 15:58:46 InterCom kernel: [ 1733.754398] hwptr_update:
pcmC0D0c:0: pos=444/1024/8192, hwptr=1/443/444/0
Dec 10 15:58:46 InterCom kernel: [ 1733.754425] hwptr_update:
pcmC0D0c:0: pos=446/1024/8192, hwptr=2/444/446/0
Dec 10 15:58:46 InterCom kernel: [ 1733.754450] hwptr_update:
pcmC0D0c:0: pos=447/1024/8192, hwptr=1/446/447/0
Dec 10 15:58:46 InterCom kernel: [ 1733.754472] hwptr_update:
pcmC0D0c:0: pos=448/1024/8192, hwptr=1/447/448/0
Dec 10 15:58:46 InterCom kernel: [ 1733.754501] hwptr_update:
pcmC0D0c:0: pos=449/1024/8192, hwptr=1/448/449/0
Dec 10 15:58:46 InterCom kernel: [ 1733.754525] hwptr_update:
pcmC0D0c:0: pos=450/1024/8192, hwptr=1/449/450/0
Dec 10 15:58:46 InterCom kernel: [ 1733.754545] hwptr_update:
pcmC0D0c:0: pos=451/1024/8192, hwptr=1/450/451/0
Dec 10 15:58:46 InterCom kernel: [ 1733.754575] hwptr_update:
pcmC0D0c:0: pos=453/1024/8192, hwptr=2/451/453/0
Dec 10 15:58:46 InterCom kernel: [ 1733.754599] hwptr_update:
pcmC0D0c:0: pos=454/1024/8192, hwptr=1/453/454/0
Dec 10 15:58:46 InterCom kernel: [ 1733.754618] hwptr_update:
pcmC0D0c:0: pos=455/1024/8192, hwptr=1/454/455/0
Dec 10 15:58:46 InterCom kernel: [ 1733.754647] hwptr_update:
pcmC0D0c:0: pos=456/1024/8192, hwptr=1/455/456/0
Dec 10 15:58:46 InterCom kernel: [ 1733.754673] hwptr_update:
pcmC0D0c:0: pos=458/1024/8192, hwptr=2/456/458/0
Dec 10 15:58:46 InterCom kernel: [ 1733.754691] hwptr_update:
pcmC0D0c:0: pos=458/1024/8192, hwptr=0/458/458/0
Dec 10 15:58:46 InterCom kernel: [ 1733.754718] hwptr_update:
pcmC0D0c:0: pos=460/1024/8192, hwptr=2/458/460/0
Dec 10 15:58:46 InterCom kernel: [ 1733.754744] hwptr_update:
pcmC0D0c:0: pos=461/1024/8192, hwptr=1/460/461/0
Dec 10 15:58:46 InterCom kernel: [ 1733.754764] hwptr_update:
pcmC0D0c:0: pos=462/1024/8192, hwptr=1/461/462/0
Dec 10 15:58:46 InterCom kernel: [ 1733.754791] hwptr_update:
pcmC0D0c:0: pos=463/1024/8192, hwptr=1/462/463/0
Dec 10 15:58:46 InterCom kernel: [ 1733.754817] hwptr_update:
pcmC0D0c:0: pos=464/1024/8192, hwptr=1/463/464/0
Dec 10 15:58:46 InterCom kernel: [ 1733.754837] hwptr_update:
pcmC0D0c:0: pos=465/1024/8192, hwptr=1/464/465/0
Dec 10 15:58:46 InterCom kernel: [ 1733.754865] hwptr_update:
pcmC0D0c:0: pos=467/1024/8192, hwptr=2/465/467/0
Dec 10 15:58:46 InterCom kernel: [ 1733.754889] hwptr_update:
pcmC0D0c:0: pos=468/1024/8192, hwptr=1/467/468/0
Dec 10 15:58:46 InterCom kernel: [ 1733.754910] hwptr_update:
pcmC0D0c:0: pos=469/1024/8192, hwptr=1/468/469/0
Dec 10 15:58:46 InterCom kernel: [ 1733.754940] hwptr_update:
pcmC0D0c:0: pos=470/1024/8192, hwptr=1/469/470/0
Dec 10 15:58:46 InterCom kernel: [ 1733.754964] hwptr_update:
pcmC0D0c:0: pos=472/1024/8192, hwptr=2/470/472/0
Dec 10 15:58:46 InterCom kernel: [ 1733.754983] hwptr_update:
pcmC0D0c:0: pos=472/1024/8192, hwptr=0/472/472/0
Dec 10 15:58:46 InterCom kernel: [ 1733.761111]
hda_codec_cleanup_stream: NID=0x8

Thank you in advance.

Kind regards
Bent Bisballe Nyeng


[-- Attachment #2: wavform1.png --]
[-- Type: image/png, Size: 9552 bytes --]

[-- Attachment #3: wavform2.png --]
[-- Type: image/png, Size: 9463 bytes --]

[-- Attachment #4: wavform3.png --]
[-- Type: image/png, Size: 8973 bytes --]

[-- Attachment #5: Type: text/plain, Size: 0 bytes --]

Re: Intel HD: ALC662 noise-bug on FitPC2i

[Clemens Ladisch]

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

Re: Intel HD: ALC662 noise-bug on FitPC2i

[Bent Bisballe Nyeng]

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?

Kind regards
Bent Bisballe Nyeng

[PATCH v2 1/1] ALSA: hda - use usleep_range in link reset and change timeout check

[mengdong.lin]

From: Mengdong Lin <mengdong.lin@intel.com>

Reducing the time on HDA link reset can help to reduce the driver loading
time. So we replace msleep with usleep_range to get more accurate time
control and change the value to a smaller one. And a 100ms timeout is set
for both entering and exiting the link reset.

Signed-off-by: Xingchao Wang <xingchao.wang@intel.com>
Signed-off-by: Mengdong Lin <mengdong.lin@intel.com>

diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c
index 72b085a..ed3a290 100644
--- a/sound/pci/hda/hda_intel.c
+++ b/sound/pci/hda/hda_intel.c
@@ -1041,7 +1041,7 @@ static void azx_power_notify(struct hda_bus *bus, bool power_up);
 /* reset codec link */
 static int azx_reset(struct azx *chip, int full_reset)
 {
-	int count;
+	unsigned long timeout;
 
 	if (!full_reset)
 		goto __skip;
@@ -1052,24 +1052,26 @@ static int azx_reset(struct azx *chip, int full_reset)
 	/* reset controller */
 	azx_writel(chip, GCTL, azx_readl(chip, GCTL) & ~ICH6_GCTL_RESET);
 
-	count = 50;
-	while (azx_readb(chip, GCTL) && --count)
-		msleep(1);
+	timeout = jiffies + msecs_to_jiffies(100);
+	while (azx_readb(chip, GCTL) &&
+			time_before(jiffies, timeout))
+		usleep_range(500, 1000);
 
 	/* delay for >= 100us for codec PLL to settle per spec
 	 * Rev 0.9 section 5.5.1
 	 */
-	msleep(1);
+	usleep_range(500, 1000);
 
 	/* Bring controller out of reset */
 	azx_writeb(chip, GCTL, azx_readb(chip, GCTL) | ICH6_GCTL_RESET);
 
-	count = 50;
-	while (!azx_readb(chip, GCTL) && --count)
-		msleep(1);
+	timeout = jiffies + msecs_to_jiffies(100);
+	while (!azx_readb(chip, GCTL) &&
+			time_before(jiffies, timeout))
+		usleep_range(500, 1000);
 
 	/* Brent Chartrand said to wait >= 540us for codecs to initialize */
-	msleep(1);
+	usleep_range(1000, 1200);
 
       __skip:
 	/* check to see if controller is ready */
-- 
1.7.9.5

Re: Intel HD: ALC662 noise-bug on FitPC2i

[Takashi Iwai]

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

Re: Intel HD: ALC662 noise-bug on FitPC2i

[Bent Bisballe Nyeng]

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.

I will try to run arecord with the -D parameter tomorrow.

Kind regards
Bent Bisballe Nyeng

Re: Intel HD: ALC662 noise-bug on FitPC2i

[Takashi Iwai]

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

Re: Intel HD: ALC662 noise-bug on FitPC2i

[Bent Bisballe Nyeng]

[-- Attachment #1: Type: text/plain, Size: 2286 bytes --]

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


[-- Attachment #2: config.gz --]
[-- Type: application/x-gzip, Size: 15708 bytes --]

[-- Attachment #3: Type: text/plain, Size: 0 bytes --]

Re: Intel HD: ALC662 noise-bug on FitPC2i

[Takashi Iwai]

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

Re: Intel HD: ALC662 noise-bug on FitPC2i

[Bent Bisballe Nyeng]

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?

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?

Kind regards
Bent Bisballe Nyeng

Re: 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

Re: [PATCH v2 1/1] ALSA: hda - use usleep_range in link reset and change timeout check

[Lin, Mengdong]

Hi Takashi,

Would you please have a look on this patch?

This is a update to a patch submitted by Xingchao before:
[alsa-devel] [PATCH] ALSA - Replace msleep() with usleep_range() to save module loading time

Many thanks!
Mengdong

Re: [PATCH v2 1/1] ALSA: hda - use usleep_range in link reset and change timeout check

[Takashi Iwai]

At Thu, 13 Dec 2012 09:32:06 +0000,
Lin, Mengdong wrote:
> 
> Hi Takashi,
> 
> Would you please have a look on this patch?
> 
> This is a update to a patch submitted by Xingchao before:
> [alsa-devel] [PATCH] ALSA - Replace msleep() with usleep_range() to save module loading time

The patch was already merged.  Sorry, forgot to inform you, as I was
too busy in these days.


Takashi