Hallo
Seit dem Upgrade auf Ubuntu 6.10 wird häufig der Onboard Soundchip als primäres Audiogerät erkannt, auf meiner Aureon 7.1 Space krieg ich dann leider kein Signal. Wenn das gerade der Fall ist, dann reicht es meistens, den Rechner noch einmal neu zu starten.
Was ich bisher probiert habe:
1. Onboard Sound im Bios deaktiviert
Bisher war ich eigentlich der Meinung, dass das Betriebssystem nur Geräte "sieht", die im Bios aktiviert sind.
Das scheint nicht so zu sein, jedenfalls hat das nicht geholfen.
2. In der Datei Modules die Treibermodule der Soundkarte in der richtigen Reihenfolge eingetragen.
Das hat nicht geholfen und da vorher keines der Module in der Datei war, habe ich sie dann wieder herausgelöscht
3. In der Datei alsa-base die Reihenfolge gemäss Wikieintrag geändert
Ich hatte das Gefühl, dass es jetzt häufiger klappt, das kann aber auch nur Einbildung oder Zufall sein. --> Kein echter Erfolg
Hier ürigens jemand mit einem ähnlichen Problem, aber leider ohne Lösung: http://forum.ubuntuusers.de/topic/56430/
Hat jemand noch eine Idee?
Linux 15.036 Themen, 107.107 Beiträge
Ich benutze diesen Soundchip nicht. Wenn alle beide Soundchips vom Kernel unterstützt werden, mußt du nur die Gerätedatei herausfinden, in die ein Programm die Musikdaten schreibt. Du brauchst entsprechende Rechte als benutzer, um diese Gerätedatei zu verwenden.
Du kannst mit dem Befehl "dmesg | less" alle Meldungen vom Kernel anzeigen lassen. Da werden auch Informationen über verwendete Gerätedateien (/dev/hda u.s.w) angezeigt.
Normalerweise müßte es möglich sein die Programme entsprechend mit der richtigen Gerätedatei zu konfigurieren.
Ich habe in einem von meinen Rechner zwei Netzwerkkarten. Da hat die eine Netzwerkkarte die Gerätedatei /dev/eth0 und die andere die Datei /dev/eth1.
Ich habe noch nicht herausgefunden in welcher Reihenfolge die Gerätedateien vergeben werden, ob erst die Onboad Geräte die Nummer 0 bekommen oder die eingesteckten PCI Karten.
Wenn du das Onboard Gerät deaktivierst, dann wird die PCI Karte wahrscheinlich die Nummer 0 (Null) von den beiden Gerätedateien bekommen.
Bei FreeBSD werden die Gerätedateien anders bezeichnet. Da wird der Treibername mit einbezogen.
PS: Die Gerätedateien sind unixtypisch. Die Programmierer schreiben in diese Gerätedateien ihre Daten, oder lesen Daten aus diesen Gerätedateien und müssen sich nicht um die Ansteuerung der Geräte kümmern: Man sagt , das unter Unix alles eine Datei ist.
Man muß dann in einer speziellen Gruppe wie audio sein, und diese Gruppe muß dann auf die richtige gerätedatei die Schreibrechte haben , um die Musik zu hören.
Leserechte braucht man um Daten von Geräten in den PC einzulesen, wie Microfon u.s.w.
Die Hardwareerkennung vom Kernel ist weitestgehend unabhängig vom BIOs, soweit mir bekannt.
Das BIOS wird beispielsweise für ACPI und APM genutzt. Da gibt es manchmal Probleme bei Notebooks, wenn das BIOS fehlerhaft programmiert wurde.
Vielen Dank!
Ich werde mir das genauer anschauen, wenn das Problem das nächste mal auftritt.
Hi
zu eth0/eth1
im Zusammenhang mit udev habe es mal gelesen, ein Zufall, hier ein link
http://www.science.uva.nl/research/air/wiki/LogicalInterfaceNames?show_comments=1
in den Kernel-Quellen steht vielleicht mehr dazu ;)
cu
Wie schaut denn deine aktuelle /etc/modules.d/alsa-base aus?
alias snd-card-0 T71Space
alias snd-card-1 V8237
##Reihenfolge festlegen
options T71Space index=0
options V8237 index=1
# autoloader aliases
#install sound-slot-0 /sbin/modprobe snd-card-0
#install sound-slot-1 /sbin/modprobe snd-card-1
#install sound-slot-2 /sbin/modprobe snd-card-2
#install sound-slot-3 /sbin/modprobe snd-card-3
#install sound-slot-4 /sbin/modprobe snd-card-4
#install sound-slot-5 /sbin/modprobe snd-card-5
#install sound-slot-6 /sbin/modprobe snd-card-6
#install sound-slot-7 /sbin/modprobe snd-card-7
# Cause optional modules to be loaded above generic modules
install snd /sbin/modprobe --ignore-install snd $CMDLINE_OPTS && { /sbin/modprobe -Qb snd-ioctl32 ; : ; }
install snd-pcm /sbin/modprobe --ignore-install snd-pcm $CMDLINE_OPTS && { /sbin/modprobe -Qb snd-pcm-oss ; : ; }
install snd-mixer /sbin/modprobe --ignore-install snd-mixer $CMDLINE_OPTS && { /sbin/modprobe --Qb snd-mixer-oss ; : ; }
install snd-seq /sbin/modprobe --ignore-install snd-seq $CMDLINE_OPTS && { /sbin/modprobe -Qb snd-seq-midi ; /sbin/modprobe --quiet snd-seq-oss ; : ; }
# Cause optional modules to be loaded above sound card driver modules
install snd-emu10k1 /sbin/modprobe --ignore-install snd-emu10k1 $CMDLINE_OPTS && { /sbin/modprobe -Qb snd-emu10k1-synth ; }
install snd-via82xx /sbin/modprobe --ignore-install snd-via82xx $CMDLINE_OPTS && { /sbin/modprobe -Qb snd-seq ; }
# Load saa7134-alsa instead of saa7134 (which gets dragged in by it anyway)
install saa7134 /sbin/modprobe --ignore-install saa7134 $CMDLINE_OPTS && { /sbin/modprobe -Qb saa7134-alsa ; : ; }
Prevent abnormal drivers from grabbing index 0
options snd-bt87x index=-2
options snd-atiixp-modem index=-2
options snd-intel8x0m index=-2
options snd-via82xx-modem index=-2
options snd-usb-audio index=-2
options snd-usb-usx2y index=-2
Hmmm... Ausschauen tut's eigentlich ganz korrekt. Abgesehen von einer Zeile:
Prevent abnormal drivers from grabbing index 0
da muss natürlich auch ein # davor stehen.
Entferne testhalber auch mal die # vor den install sound-slot- Zeilen.
Ich möchte mich schon mal bei allen für die Tipps bedanken.
Da ich nicht Lust habe, meinen Rechner zum Testen dutzende Male neu zu starten, werde ich das alles über einen längeren Zeitraum durchtesten.
Ich melde mich wieder, wenn ich denke, dass das Problem behoben ist oder wenn ich nicht mehr weiter weiss.
Wenn du sowieso den Onboard Sound nicht brauchst, dann kannst du doch auch mal einen eigenen Kernel kompilieren und den Treiber für den Onboard Soundchip einfach entfernen.
Vielleicht ist bei Ubuntu irgendwo noch ein Programmierfehler. Es werden im Betriebsystemkern zwei verschiedene Soundtreiber geladen und die vertragen sich vielleicht nicht.
Ubuntu versucht die Systemadministration sehr stark zu automatisieren. Leider wird das nie richtig funktionieren, allein schon deshalb ,weil es bei unixähnlichen Systemen keine Standards bei den Konfigurationsdateien im /etc Verzeichnis gibt.
Unixsoftware ist meist sehr komplex und man hat als Administrator sehr viele Einstellmöglichkeiten. Deshalb werden viele Konfigurationsdateien einfach mit einem Editor bearbeitet.
Das war schon bei SUSE immer ein Problem, als ich noch SUSE genutzt habe.
Für die meisten Anfänger sind die viele Kerneloptionen ein großes Problem. Leider ist bei der Online Hilfe nicht immer eine gute Erlärung dabei.
Ich finde diesen Beitrag sehr lesenswert, wenn man mal einen eigenen Kernel kompilieren will:
http://de.gentoo-wiki.com/Kernel_manuell_kompilieren
Bei Debian wird gar nicht erst versucht, die Systemadministration zu sehr zu automatisieren.
Ich habe jetzt alle vorgeschlagenen Änderungen in der Datei Alsa-base durchgetestet, ohne Erfolg.
Die Sache mit den Gerätedateien ist mir ein bisschen zu umständlich(funktioniert ja in etwa 7 von 8 Fällen).
Bei diesem Einen Fall kann ich dann mit einer Wahrscheinlichkeit von (nach bisherigen Erfahrungen) 70% die Karte einfach über das Gui aktivieren.
Den Kernel möchte ich nicht selber kompilieren, da ich gerade mal genug Erfahrung habe um zu wissen, dass dann mit grosser Wahrscheinlichkeit irgendwas wieder nicht funktionieren wird. Im Moment habe ich leider auch nicht die Zeit, ein Wochenende oder mehr dafür zu opfern.
Ist es nicht so, dass die Treiber als Module eingebunden werden. Könnte man dann nicht einfach das Einbinden dieses Moduls irgendwie verhindern?