Bugzilla – Bug 105083
Audio recording (from microphone) with hissing sound under ALi M5455 driver
Last modified: 2007-02-26 13:55:11 UTC
Mainboard: ASRock Combo-Z with Athlon 64 CPU In both 32bit and 64bit installations of SUSE Linux 9.3 an 10.0 beta, any recording from the microphone is distorted by hissing noises (at least using KRecord). I have verified that on the same hardware running MS Windows XP with the sound drivers supplied by ASRock, the recording quality is excellent. lspci reports: 0000:00:04.0 Multimedia audio controller: ALi Corporation M5455 PCI AC-Link Controller Audio Device (rev 20) Subsystem: ASRock Incorporation: Unknown device 0850 Flags: bus master, medium devsel, latency 32, IRQ 201 I/O ports at e800 [size=256] Memory at febff000 (32-bit, non-prefetchable) [size=4K] Capabilities: <available only to root>
Takashi, Jaroslav, here's one for you guys.
Try to record with arecord: - arecord -fdat foo.wav - arecord -fcd foo.wav - arecord -Dhw:0 -fcd foo.wav and check whether the same symptom occurs.
(In reply to comment #2) > - arecord -fdat foo.wav High-pitched background noise. > - arecord -fcd foo.wav Same as above. > - arecord -Dhw:0 -fcd foo.wav Same noise, and: test> arecord -Dhw:0 -fcd foo.wav Recording WAVE 'foo.wav' : Signed 16 bit Little Endian, Rate 44100 Hz, Stereo Warning: rate is not accurate (requested = 44100Hz, got = 48000Hz) please, try the plug plugin (-Dplug:hw:0) With -Dplug:hw:0, also the same high-frequency noise. With arecord, the noise is still quite present and annoying, but less so than in krecord or linphone, where the noise's volume follows that of the audio input.
OK, then it's either a mixer setting or a driver problem. Which driver is used? If it's using ac97 codec, please attach /proc/asound/card0/codec97#0/* files. Also, run "alsactl -f somefile store" and attach that file.
(In reply to comment #4) > If it's using ac97 codec, please attach /proc/asound/card0/codec97#0/* files. ACK > Also, run "alsactl -f somefile store" and attach that file. ACK I am also attaching the output of lspci as run by root.
Created attachment 46733 [details] /proc/asound/card0/codec97#0/ac97#0-0
Created attachment 46734 [details] /proc/asound/card0/codec97#0/ac97#0-0+regs
Created attachment 46736 [details] alsactl -f somefile store
Created attachment 46738 [details] lspci
The capture level seems to high. Can you lower it? Anyway, try "arecord -fdat -Dhw:0 foo.wav", too.
I have lowered the capture level in KMix, but I tried this before to no avail. I am attaching a sample recording done with the arecord command line you suggested. The input source is microphone. During the first second, there is relative silence in the room (PCs running...). Then, I just shortly blow into the microphone. What's interesting is that the high pitched sound stays on after the noise. This happens at any recording level, when there is silence, the volume of the noise is low, once any significant sound input occurs, the noise becomes overwhelmingly loud. VOIP telephony is absolutely impossible with that, by the way, the frequency range of the codecs and the POTS gateway let only the noise through, but none of the actual audio.
Created attachment 47187 [details] Sample recording illustrating the problem
Can you try ali5455 module instead of ALSA driver? Run as root: "rcalsasound unload" then run "modprobe ali5455". For simply playback and record via OSS, you can use "play" and "rec" included in sox package.
OK, after using nmixer to adjust the recording source and level - I don't know how to set the automatic gain control, though - I get the perfect crystal clear recording I'd expect from the OSS driver. So can you pull the info from the OSS sources to fix the ALSA driver?
I have never managed to report this to the ALSA bug reporting system, but I've now found a workaround in SUSE 10.0: The mixer tool sets the recording input mark (a red dot) to both the microphone level and the catch-all capture level controls. This appears to cause an internal feed-back loop responsible for the noise I reported. Disabling the recording input for the microphone, or setting it to the otherwise unused line-in level control, resolves the problem! The recording gain apparently is independant of the microphone level, too. All that affects recording performance is the capture level setting. Some applications have built-in code that selects the microphone for recording, for instance linphone does this. The work-around there is to change the recording source to line-in in the linphone settings. Overall, it should be explored wether ALSA should be patched to disable the recording-source selection for anything else but "capture" on this driver.
The recording bug of ali5455 has been fixed in the recent versions.