[def]

@Atropin:
Danke nochmals für Deine abschließenden Erläuterungen.

Zitat (bb83: 01.09.2008, 19:41)

Richtig, es gibt unter linux ja meist mehrere Möglichkeiten die Hardware anzusprechen.
nvidia/nv ati/fglrx ipw3945/iwl3945 usw. Ich picke mir immer den raus,der am besten bei mir geht. In dem Fall nvidia / ipw3945 mit iwl3945 sind adhoc Netze z.B. unter aller Kanone.
(...)
Und du könntes gucken ob sich nicht 2 Module um die eine Soundkarte zerren. Hatte mal, das iwl3945 und ipw3945 gleichzeitig geladen waren. Kommt nur Mist bei rum

Ich glaube zwar nicht, dass es bei meinem AC'97-Chip eine große Rolle spielt, aber das ist ja trotzdem mal ganz interessant. Bei Soundtreibern sprechen wir von dynamisch ladbaren Kernelmodulen? Der Befehl lsmod zeigt also alle momentan geladenen Kernelmodule an. Woher wüsste ich denn, welche davon überhaupt Soundtreiber sind?
Hier meine Ausgabe nach lsmod:

Module				  Size  Used by
rfcomm				 33105  0 
l2cap				  22721  9 rfcomm
bluetooth			  48165  4 rfcomm,l2cap
autofs4				20933  2 
sunrpc				151777  3 
ppp_synctty			10945  0 
ppp_async			  12097  1 
crc_ccitt			   6081  1 ppp_async
ppp_generic			24669  6 ppp_synctty,ppp_async
slhc					9025  1 ppp_generic
nf_conntrack_ipv4	  11717  2 
ipt_REJECT			  7105  2 
iptable_filter		  6721  1 
ip_tables			  14033  1 iptable_filter
nf_conntrack_ipv6	  16469  2 
xt_state				6209  4 
nf_conntrack		   50453  3 nf_conntrack_ipv4,nf_conntrack_ipv6,xt_state
xt_tcpudp			   6977  8 
ip6t_ipv6header		 6209  2 
ip6t_REJECT			 7745  2 
ip6table_filter		 6593  1 
ip6_tables			 15057  2 ip6t_ipv6header,ip6table_filter
x_tables			   15557  7 ipt_REJECT,ip_tables,xt_state,xt_tcpudp,ip6t_ipv6h
eader,ip6t_REJECT,ip6_tables
loop				   16581  0 
dm_multipath		   18505  0 
ipv6				  224901  16 nf_conntrack_ipv6,ip6t_REJECT
snd_intel8x0		   30557  5 
snd_ac97_codec		 92261  1 snd_intel8x0
ac97_bus				5825  1 snd_ac97_codec
snd_seq_dummy		   6853  0 
snd_seq_oss			29633  0 
parport_pc			 26597  0 
parport				32301  1 parport_pc
snd_seq_midi_event	  9921  1 snd_seq_oss
snd_seq				44913  5 snd_seq_dummy,snd_seq_oss,snd_seq_midi_event
nvidia			   4706896  32 
snd_seq_device		  9933  3 snd_seq_dummy,snd_seq_oss,snd_seq
snd_pcm_oss			37441  0 
snd_mixer_oss		  16577  2 snd_pcm_oss
floppy				 52133  0 
pcspkr				  6593  0 
snd_pcm				61637  4 snd_intel8x0,snd_ac97_codec,snd_pcm_oss
serio_raw			   8901  0 
firewire_ohci		  22213  0 
firewire_core		  34785  1 firewire_ohci
snd_timer			  21065  2 snd_seq,snd_pcm
crc_itu_t			   6081  1 firewire_core
snd					44517  16 snd_intel8x0,snd_ac97_codec,snd_seq_oss,snd_seq,sn
d_seq_device,snd_pcm_oss,snd_mixer_oss,snd_pcm,snd_
timer
soundcore			   9633  2 snd
snd_page_alloc		 11337  2 snd_intel8x0,snd_pcm
forcedeth			  46541  0 
i2c_nforce2			 9793  0 
i2c_core			   20948  2 nvidia,i2c_nforce2
button				 10320  0 
sg					 31733  0 
sr_mod				 17541  0 
cdrom				  32865  1 sr_mod
dm_snapshot			18661  0 
dm_zero				 5825  0 
dm_mirror			  25541  0 
dm_mod				 49321  9 dm_multipath,dm_snapshot,dm_zero,dm_mirror
pata_acpi			   8641  0 
pata_amd			   13893  2 
ata_generic			 9285  0 
libata				126545  3 pata_acpi,pata_amd,ata_generic
sd_mod				 25817  3 
scsi_mod			  121965  4 sg,sr_mod,libata,sd_mod
ext3				  109897  2 
jbd					41173  1 ext3
mbcache				10309  1 ext3
uhci_hcd			   22865  0 
ohci_hcd			   22725  0 
ehci_hcd			   32205  0

Woher wüsste ich jetzt, ob es da zwei Module gibt, die auf den Soundchip zugreifen wollen?
Mir fallen - natürlich - vor allem erstmal die Sachen auf, die von snd abhängig sind: snd_intel8x0, snd_ac97_codec, snd_seq_oss, snd_seq, snd_seq_device, snd_pcm_oss, snd_mixer_oss, snd_pcm, snd_timer. Aber welcher ist jetzt der "Soundtreiber"?

Zitat (bb83: 01.09.2008, 19:41)

Mit alsamixer kannst du auch noch an den Kanälen rumspielen, wird vermutlich nicht helfen und dir schon bekannt sein .

Nein, war mir nicht bekannt; stimmt, wird wohl nichts helfen; ach ja: und danke für den Hinweis!

Viele Grüße
Def

[Atropin]

Zitat (def: 01.09.2008, 21:30)

@Atropin:
Danke nochmals für Deine abschließenden Erläuterungen.


Ich glaube zwar nicht, dass es bei meinem AC'97-Chip eine große Rolle spielt, aber das ist ja trotzdem mal ganz interessant. Bei Soundtreibern sprechen wir von dynamisch ladbaren Kernelmodulen? Der Befehl lsmod zeigt also alle momentan geladenen Kernelmodule an. Woher wüsste ich denn, welche davon überhaupt Soundtreiber sind?

Die meißten Soundtreiber (muss nicht modular einbindbar sein, kann auch fest in den Kernel compiled sein, im Falle von Distributionen sind die aber wohl alle Module) fangen in der Regel mit snd_ an.
Sie müssen es aber nicht, die können auch anders heißen

Zitat

Hier meine Ausgabe nach lsmod:
[...]

Woher wüsste ich jetzt, ob es da zwei Module gibt, die auf den Soundchip zugreifen wollen?
Mir fallen - natürlich - vor allem erstmal die Sachen auf, die von snd abhängig sind: snd_intel8x0, snd_ac97_codec, snd_seq_oss, snd_seq, snd_seq_device, snd_pcm_oss, snd_mixer_oss, snd_pcm, snd_timer. Aber welcher ist jetzt der "Soundtreiber"?

Die Modulliste ist völlig in Ordnung. Distributionen versuchen immer so viel wie möglich über Module zu lösen weil damit sehr viele Menschen erreicht werden und die natürlich alle unterschiedliche Hardware haben, wo es sinnmacht das bzImage (den Kernel, der beim booten geladen wird, das Stück ohne Module) so klein wie möglich zu halten, das klappt auch immer recht gut, kannst ja mal nachkucken, die /boot/bzImage (kann auch anders heißen) hat immer so um die 1,4MB. Die Module die du da auflistest gehören alle zu ALSA (auch die snd_[..]_oss, das sind die ALSA-OSS Kompatibilitätsmodule, damit Anwendungen auf ein PseudoOSS zugreifen können, was eigentlich ein ALSA ist). "der" Soundtreiber existiert so nicht. ALSA "besteht" aus mehreren einzelnen Treibern, snd und snd_pcm sieht recht verdächtig nach dem "Kern" aus. Dazu wird dann noch ein Devicetreiber von ALSA geladen, der in der Regel aus einem Treiber besteht, im Falle von ac'97 sind es aber mindestens zwei, einmal das für den Chip(nforce, via, intel, usw...), und einmal das für die AC'97 Implementierung
Die Devicetreiber dürften in deinem Fall die hier sein:
snd_intel8x0
snd_ac97_codec
ac97_bus

snd scheint schon das "wichtigste" Modul zu sein wie man schön an der Auflistung der Module sieht, die es benutzen:
snd 44517 16 snd_intel8x0,snd_ac97_codec,snd_seq_oss,snd_seq,sn
d_seq_device,snd_pcm_oss,snd_mixer_oss,snd_pcm,snd
_timer
(Die kommagetrennte Liste am Ende)

Die Idee das mehrere Module auf deine Soundkarte zugreifen ist zwar irgendwie nachvollziehbar, aber eigentlich nie zutreffend, außer man hat den Fall wo man ein proprietäres und ein normales aus dem Kernel sourcetree hat, aber auch da passiert das in der Regel nicht, dass sich zwei Treiber für ein Gerät laden lassen.

[def]

Zitat (Atropin: 02.09.2008, 06:31)

Die meißten Soundtreiber (muss nicht modular einbindbar sein, kann auch fest in den Kernel compiled sein, im Falle von Distributionen sind die aber wohl alle Module) fangen in der Regel mit snd_ an.
Sie müssen es aber nicht, die können auch anders heißen

Irgendwie typisch für Linux, nicht wahr?
War wohl etwas naiv von mir, anzunehmen, es könnte einen Befehl geben, der sagt: "Zeig mir mal den Treiber für den AC'97-Chip (egal, ob dynamisch geladen oder fest in den Kernel eingebaut)!" oder "Zeig mal alle Treiber, die für Sound zuständig sind!"
Stattdessen kommt man dem ganzen nur mit Erfahrungswerten, Faustregeln und Spürsinn auf die Schliche. Das sind so die Ecken und Kanten, an denen man merkt, dass Linux trotz aller aufpolierten Oberflächen und Schnickschnack immer noch ein System von und für Freaks ist!

Zitat (Atropin: 02.09.2008, 06:31)

(...) Die Module die du da auflistest gehören alle zu ALSA (auch die snd_[..]_oss, das sind die ALSA-OSS Kompatibilitätsmodule, damit Anwendungen auf ein PseudoOSS zugreifen können, was eigentlich ein ALSA ist). (...)

Halt, Moment mal. Heißt das also, dass die Einstellmöglichkeit für OSS-Ausgabe in einigen Media-Playern eigentlich eine Mogelpackung ist? Dass in Wirklichkeit, wenn ich OSS auswähle, immer noch ALSA zuständig ist, und eben nicht OSS?

Zitat (Atropin: 02.09.2008, 06:31)

(...)
Die Idee das mehrere Module auf deine Soundkarte zugreifen ist zwar irgendwie nachvollziehbar, aber eigentlich nie zutreffend, außer man hat den Fall wo man ein proprietäres und ein normales aus dem Kernel sourcetree hat, aber auch da passiert das in der Regel nicht, dass sich zwei Treiber für ein Gerät laden lassen.

Da greifen vermutlich die Automatiken, die die Kernel-Entwickler bzw. Distro-Hersteller eingebaut haben. Danke, dass Du Dir die Zeit genommen hast, die von mir präsentierte Liste mal genauer durchzusehen.
Und auch meine zahllosen Fragen beantwortet hast!

Viele Grüße
Def

[Atropin]

Zitat (def: 02.09.2008, 20:59)

Irgendwie typisch für Linux, nicht wahr?
War wohl etwas naiv von mir, anzunehmen, es könnte einen Befehl geben, der sagt: "Zeig mir mal den Treiber für den AC'97-Chip (egal, ob dynamisch geladen oder fest in den Kernel eingebaut)!" oder "Zeig mal alle Treiber, die für Sound zuständig sind!"
Stattdessen kommt man dem ganzen nur mit Erfahrungswerten, Faustregeln und Spürsinn auf die Schliche. Das sind so die Ecken und Kanten, an denen man merkt, dass Linux trotz aller aufpolierten Oberflächen und Schnickschnack immer noch ein System von und für Freaks ist!

Wie man's nimmt. Wenn man mal kurz drüber nachdenkt ist es einfach nur logisch, und Logik bringt manchmal Umstände mit sich die Sachen etwas komplizierter erscheinen lassen, weil man es einfach völlig anders gewöhnt ist. Windows versucht dem User alles so darzustellen ohne dass er großartig nachdenken braucht, das führt dann nicht selten dazu dass Angaben fehlen, mal nicht zugänglich sind wenn man mal Logik braucht, oder einfach mal Sachen gar nicht gehen weil das System für den User etwas Menschlichkeit vornehmen soll, was fehleranfällig by design ist. In der dmesg, in /proc, lspci, /proc/asound/(...) usw werden dir detaillierte Informationen geliefert die mehr als ausreichen, da geht schon kaum noch mehr. Das snd_[...] ein Soundmodul ist sollte selbsterklärend sein, die Module die darauf zurückgreifen stehen wie gesagt in der Ausgabe von lsmod, da haste dann schon "alles was für Sound zuständig ist".

Zitat

Halt, Moment mal. Heißt das also, dass die Einstellmöglichkeit für OSS-Ausgabe in einigen Media-Playern eigentlich eine Mogelpackung ist? Dass in Wirklichkeit, wenn ich OSS auswähle, immer noch ALSA zuständig ist, und eben nicht OSS?

Das kann gut sein, bei OSS unter Linux kenn ich mich nicht sonderlich gut aus, und um ALSA wirklich auszuschließen und das alte OSS als Einziges zu verwenden müssteste am Besten den Kernel mit einer eigenen Config compilen... Kann auch sein, dass der "echte" OSS-Kram gar nicht in den Distributionskerneln verfügbar ist, weil es ja "ALSA-OSS" gibt, und OSS sowiso nicht mehr gebraucht werden würde ...

Zitat

Da greifen vermutlich die Automatiken, die die Kernel-Entwickler bzw. Distro-Hersteller eingebaut haben. Danke, dass Du Dir die Zeit genommen hast, die von mir präsentierte Liste mal genauer durchzusehen.
Und auch meine zahllosen Fragen beantwortet hast!

Viele Grüße
Def

Die Distributoren versuchen bei vielen enduserorientierten Distributionen natürlich soviel wie möglich ist zu automatisieren, das ist häufig ein Problem, ja

[def]

Zitat (Atropin: 02.09.2008, 21:24)

(...) In der dmesg, in /proc, lspci, /proc/asound/(...) usw werden dir detaillierte Informationen geliefert die mehr als ausreichen, da geht schon kaum noch mehr. (...)

Ah ja, okay, die werde ich mir mal in Ruhe ankucken; danke für den Hinweis. Wenn es denn also Wege gibt, an alle Informationen vollständig ranzukommen (ohne raten oder vermuten zu müssen), dann will ich nichts gegen Linux gesagt haben!

Zitat (Atropin: 02.09.2008, 21:24)

Das kann gut sein, bei OSS unter Linux kenn ich mich nicht sonderlich gut aus, und um ALSA wirklich auszuschließen und das alte OSS als Einziges zu verwenden müssteste am Besten den Kernel mit einer eigenen Config compilen... Kann auch sein, dass der "echte" OSS-Kram gar nicht in den Distributionskerneln verfügbar ist, weil es ja "ALSA-OSS" gibt, und OSS sowiso nicht mehr gebraucht werden würde ...

Gut, macht auch nichts, hatte mich nur allgemein interessiert. Wie gesagt, für meinen AC'97-Soundchip spielts wohl eh keine Rolle, und solange man bei Linux bleibt und beim Kauf der Soundkarte auf Linux- bzw. ALSA-Kompatibilität achtet, kann einem OSS sowieso egal sein...!
Nochmal herzlichen Dank für Deine vielen Erläuterungen!

Schöne Grüße
Def

[blob]

Zitat (def: 01.09.2008, 13:58)

@blob:
Du wirst es nicht glauben, aber alsaconf existiert nicht auf meinem System (das Paket alsa-utils ist bereits installiert). Ich habe hier ein Programm namens alsactl, das zumindest dem Namen nach der Funktionalität recht nahe kommen könnte (?), aber es wird in jedem Fall anders bedient!

#./alsactl
alsactl: Specify command...

Lade das mal hiermdown, entpacke es (in Textconsole zBsp mit mc dann F5), kopiere es in dein System, danach anwenden

ftp://ftp.uni-siegen.de/pub/sys-linux/als...7-i486-1sys.tgz

[def]

Zitat (blob: 03.09.2008, 00:48)

Lade das mal hiermdown, entpacke es (in Textconsole zBsp mit mc dann F5), kopiere es in dein System, danach anwenden

ftp://ftp.uni-siegen.de/pub/sys-linux/als...7-i486-1sys.tgz

Danke für die Datei. Ich bin ja immer für Experimente zu haben. Ich hatte neulich schon am System rumgebastelt (ohne Fedoras Paketmanagement einzubeziehen, natürlich), also kann das hier auch nicht mehr schaden. Mal sehen, wann ich mein System kaputtgespielt habe. Dann kann ich endlich SYS Linux ausprobieren...!
Also, ich wusste jetzt nicht genau, welche Schritte erforderlich sind. Hab folgendes gemacht:

• alsa-utils-1.0.17-i486-1sys/install/doinst.sh durchlaufen lassen (die ersetzten Dateien hatte ich vorher gesichert - ich hatte mir das Skript vorher kurz angesehen...)
  
• alsaconf ausgeführt und immer auf Enter geklickt (nach Deiner Empfehlung). Wie erwartet, war die Ausgabe des Programms am Schluss sinngemäß, dass nunmehr alles richtig konfiguriert sei.

Im Moment funktioniert der Sound ohne Probleme; sollte sich das ändern, werde ich das an dieser Stelle nachtragen. Wie gesagt, die Probleme treten höchst unregelmäßig auf.

Nochmal vielen Dank für Deine Mühe!

Schöne Grüße
Def

Dieser Beitrag wurde von def bearbeitet: 03. September 2008 - 00:34

[Atropin]

Lass uns bitte mal wissen ob das Problem nu behoben ist

[def]

Zitat (Atropin: 04.09.2008, 20:46)

Lass uns bitte mal wissen ob das Problem nu behoben ist

Mach ich gern. Zusammengefasst: Sieht ganz so aus!
Also erstmal, ich habe noch keine Soundkarte, sondern nutze noch den AC'97-Chip. Schon als ich da mit Euren Tipps rumprobiert habe, hat das Problem irgendwann aus unerfindlichen Gründen nachgelassen, auch schon bevor ich blob's Tipp mit alsaconf ausprobiert hatte, aber da glaubte ich noch, das wäre nur eine Phase. Und auch nach dem Ausprobieren von blob's Tipp ist es nicht mehr aufgetreten. Das einzige, was ich jetzt noch merke, sind sehr kurze Aussetzer im Sound, wenn der Rechner gerade mal stark "belastet" ist (glaube ich zumindest). Aber diese sind wirklich sehr selten und kurz und stören somit nicht weiter.
Ich weiß also nicht mal, was letztendlich geholfen hat. Aber ich hoffe mal, es bleibt so. (Zumindest, bis ich eine Soundkarte gekauft habe - die gönn ich mir trotzdem irgendwann!)
Also nochmal vielen Dank!

Viele Grüße
Def

[def]

Während meiner Programmierexperimente mit Python sind die Soundprobleme jetzt übrigens doch wieder aufgetreten. Offensichtlich wird der Chip davon negativ beeinflusst, wenn ein unoptimiertes, schlecht geschriebenes Python-Programm den Prozessor minutenlang in die Knie zwingt.
Das ist zwar überhaupt nicht schlimm, aber ich wollte es Euch der Vollständigkeit halber wissen lassen.

Viele Grüße
Def