[alsa-devel] [PATCH v2 1/1] ALSA: hda - use usleep_range in link reset and change timeout check
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 */
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
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
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
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
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
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
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
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
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
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
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
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
participants (5)
-
Bent Bisballe Nyeng -
Clemens Ladisch -
Lin, Mengdong -
mengdong.lin＠intel.com
-
Takashi Iwai