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