Archlinux/ALSA: How I solved my crackling microfone
(Or: what affect poor synchronization of processes threads and buffers..)
1 The Problemo
Seit dem letzten System Update stellte ich unerklärliche Nebengeräusche fest bei einer Aufnahme ab Line In (resp. Mic In). Das Playback von Dateien funktionierte problemlos.
Zuerst versuchte ich verschiedene Einstellungen im Alsa Mixer. Dann kamen Google und diverse Linux Foren. Alles ohne Erfolg.
Wie findet man allein sowas heraus? Ein Durchprobieren aller möglichen und unmöglichen Irrtümern begann. Erschwerend kam hinzu, dass der Fehler manchmal verschwand, dann wieder ohne Zutun auftrat. Der absolute Worst Case! Nach wochenlanger Suche und Beinahe-Kapitulation kam die Lösung dann doch.
Folgender Abschnitt ist nicht nur für User gedacht sondern auch für die ALSA Entwickler:
2 Fehler Analyse
Wie beginnt man mit der systematischen Analyse am Besten? Am schnellsten wäre ich zur Lösung gelangt wenn ich in nachfolgender Reihenfolge der nächsten Teilabschnitte vorgegangen wäre, aber im Nachhinein ist man bekanntlich immer klüger:
2.1 Ursache Hard- oder Software?
Gottseidank hatte ich auf dem PC einen Dualboot Windoze-Linux eingerichtet. So war die Frage schnell geklärt ob es sich um ein Hardware oder Software Problem handelt. Für jene, die das nicht haben tut es auch eine (getestete) Live CD
2.2 Testsignal Aufnahme OK?
Ich begann zuerst einen einfachen Ton (1 kHz 78 mV Sinus) an Line In aufzuzeichnen:
arecord -vv -f cd outfile.wav
Die Visualisierung mit Audacity zeigte Aussetzer von ein paar Mikrosekunden in bestimmten Abständen.
2.3 CPU Überlast ausgeschlossen?
Möglicherweise kann die CPU die Audio Echtzeit Informationen nicht schnell genug abarbeiten. In Linux kann man die Prozesse manuell priorisieren, also schneller machen:
nice -n -3 arecord -vv -f cd outfile.wav
2.4 Es ist Zeit für mehr System Informationen:
cat /proc/asound/card0/codec#3 |grep Codec
modinfo snd_hda_intel
arecord -l
2.5 Passt der Treiber wirklich zur Hardware?
Welche Firmware geladen wurde fand ich im Logfile und schien mir korrekt:
dmesg |grep snd
Danach versuchte ich, das ALSA Kernelmodul in dessen Verhalten zu beeinflussen. Für mein Foxconn Motherboard empfahl Google:
options snd_hda_intel model=ecs
Was zunächst als Erfolg aussah, entpuppte sich als zufällige Laune des Computers. Irgendetwas zuckte aber doch, darum folgte "Methode Bruteforce" was immer das Internet hergab. Um es etwas zu beschleunigen kreierte ich ein Script:
echo "options snd_hda_intel snoop=0" > /etc/modprobe.d/alsa.conf # Beispiel f. option snoop rmmod snd_hda_intel modprobe snd_hda_intel # systool -vm snd_hda_intel # Kontrolle ob Parameter geladen
Irgendwann gab ich dann doch auf.
2.6 Warum gibt es im Prozessor zwei AD Wandler?
Das Datasheet des ALC662 offenbarte Seltsames: Es arbeiten gleichzeitig zwei AD Wandler das gleiche Analogsignal um und mixen den Output wieder zusammen. Was wäre wenn diese sich gegenseitig stören? Also muss einer deaktiviert werden:
arecord -vv -f cd -D hw:0,2,0 outfile.wav # syntax hw:<card>,<device>,<subdevice>
Überraschung! Abhängig von der Tageslaune meines Computers, stellte ich dennoch eine markante bis vollständige Verbesserung fest. → 
.
Aber da musste noch mehr sein, so suchte ich weiter. Das ALSA Logfile2 war diesmal anders, kompakter, weniger involvierte Plugins.
2.7 Haben wir noch ein Buffer + Synchronisations Problem?
Weniger Plugins = besserer Sound, je nach Tageslaune des Computers? Interessant! Da ich selber programmiere und daher die Fallstricke beim Datenaustausch von Threads und Prozessen kenne, muss folgendes stimmen:
Hier scheint was im Argen zu liegen. Testen wir dies, indem wir einen riesigen Buffer kreieren um die Probleme zu kaschieren:
arecord -vv -f cd -D hw:0,2,0 --period-size=500000 outfile.wav
Und TADAAAAAA!! Meine These war richtig! Bitte, liebe ALSA-Programmierer: löst dieses Problem!
3 Abhilfe
Nun musste ein Weg gefunden werden, diesen dirty Hack minimal invasiv und dauerhaft abzuspeichern. Ein Default PCM vom Typ "plug" in /etc/asound.conf schien mir dafür am geeignetsten. Dummerweise erlaubt dieser kein "period_size" Attribut, aber man kann es indirekt beeinflussen via Sample Rate:
# nano /etc/asound.conf
pcm.!default {
type asym
capture.pcm
{
type plug
slave {
pcm "hw:SB,2,0" # find out definition "hw:<cardNr or CardName>,<deviceNr>,<subdevNr>" via arecord -l
rate 48000 # 48000 (alsa default bus) or 96000 (create more buffer size)
}
}
playback.pcm
{
type plug
slave.pcm "dmix" # if soundcard has not index 0 (aplay -l) then use explicit "hw:...." string
}
}
Nun konnte ich mit den Standartbefehlen aufzeichnen. Das Logfile3 war zwar wiederum verändert, aber dennoch plausiblel.
arecord -vv -f cd record.wav # ffmpeg -f alsa -ar 44100 -i default record.mp3 # Variante for mp3
4 Fazit
Da ich nicht selber in der Linux oder ALSA Community programmiere, geschweige denn mich ohne Hilfe darin vertiefen kann, bitte ich die Autoren darum, ihre Programmierung zu überprüfen. Logfiles und Testtöne sind im Artikel erwähnt. Obendrein hier noch ein paar Versionsangaben:
Etwas Gutes hatte das Ganze doch: Durch das Einarbeiten in ALSA kann ich jetzt Youtube Audiostreams lokal abspeichern ;-) siehe Artikel.
Last Update: Aug 2025
