Guten Morgen,
wenn ich mp3's unter freeamp oder mpg321 abspiele, und dabei was im X-Windows mache, fängt die Musik an zu knacksen. Das pasiert auch, wenn ich midi-Files mit timidity abspiele.
Ich denke, das liegt an irgenteiner Priorität des Soundtreibers.
Danke, Friedrich
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Saturday 04 May 2002 11:05, Friedrich Hagedorn wrote:
Ich denke, das liegt an irgenteiner Priorität des Soundtreibers.
Oder aber an Deiner Festplatte, welche elektromagnetische Impulse in Deine Soundkarte einstreut.
Gruss, Jan. - -- IPv6 Research of cyconet.org available at http://ipv6.cyconet.org Feel free to contact webmaster at cyconet dot org for peering tunnel.
On Sat May 04, 2002 at 12:11:23PM +0200, Jan Wagner wrote:
Ich denke, das liegt an irgenteiner Priorität des Soundtreibers.
Oder aber an Deiner Festplatte, welche elektromagnetische Impulse in Deine Soundkarte einstreut.
:-) Das wäre auch eine Möglichkeit. Ist aber sehr unwahrscheinlich, da es dann erstens bei jedem Plattenzugriff knacksen müsste, und zweitens weil ich die gleiche Hardware schon unter meiner alten SuSe lief, und da knackste im X nix.
Hat jemand schonmal mit einem solchen Problem zu tun?
Danke, Friedrich
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Saturday 04 May 2002 12:14, Friedrich Hagedorn wrote:
:-) Das wäre auch eine Möglichkeit. Ist aber sehr unwahrscheinlich, da es dann erstens bei jedem Plattenzugriff knacksen müsste, und zweitens weil ich die gleiche Hardware schon unter meiner alten SuSe lief, und da knackste im X nix.
Hat jemand schonmal mit einem solchen Problem zu tun?
Hmmm ... benutzt Du bei Deinem neuen System auch ALSA als Soundtreiber wie bei SuSE? Einfluss koennte auch noch der Sound Daemon haben, der eventuell bei Dir unter X laeuft.
Ciao, Jan. - -- IPv6 Research of cyconet.org available at http://ipv6.cyconet.org Feel free to contact webmaster at cyconet dot org for peering tunnel.
On Sat May 04, 2002 at 12:27:06PM +0200, Jan Wagner wrote:
Hat jemand schonmal mit einem solchen Problem zu tun?
Hmmm ... benutzt Du bei Deinem neuen System auch ALSA als Soundtreiber wie bei SuSE? Einfluss koennte auch noch der Sound Daemon haben, der eventuell bei Dir unter X laeuft.
ALSA-Treiber sind geladen. Ein Sound-Dämon existiert meines Wissens bei mir gar nicht (Du meinst sowas wie esd). Es ist ein ganz spartanisches X mit Fvwm ohne alles.
Das knacksen ist besonders stark wenn ich die Maus bewege, oder wenn ich komplettes Fenster bewege.
Friedrich
Am Samstag, 4. Mai 2002 12:14 schrieb Friedrich Hagedorn:
On Sat May 04, 2002 at 12:11:23PM +0200, Jan Wagner wrote:
Ich denke, das liegt an irgenteiner Priorität des Soundtreibers.
Oder aber an Deiner Festplatte, welche elektromagnetische Impulse in Deine Soundkarte einstreut.
:-) Das wäre auch eine Möglichkeit. Ist aber sehr unwahrscheinlich, da
es dann erstens bei jedem Plattenzugriff knacksen müsste, und zweitens weil ich die gleiche Hardware schon unter meiner alten SuSe lief, und da knackste im X nix.
Hat jemand schonmal mit einem solchen Problem zu tun?
Bei mir gab es solche Probleme mit XFree 3.x. Als ich dann auf Xfree4.xx gewechselt atte waren die Probleme weg.
Hi Friedrich,
On Sat, May 04, 2002 at 12:14:21 +0200, Friedrich Hagedorn wrote:
:-) Das wäre auch eine Möglichkeit. Ist aber sehr unwahrscheinlich, da es dann erstens bei jedem Plattenzugriff knacksen müsste, und zweitens weil ich die gleiche Hardware schon unter meiner alten SuSe lief, und da knackste im X nix.
Hat jemand schonmal mit einem solchen Problem zu tun?
So was aehnliches. Seit ich auf meinem (zugegeben etwas antiquierten) Rechner von Kernel 2.2 auf Kernel 2.4 und von XFree 3 auf XFree 4 umgestellt habe, gibt es Sound-Aussetzer, wenn ich unter X ein Fenster mit Inhalt bewege.
Hardware: P166MMX, 96MB Ram, S3Virge (PCI), Soundblaster 16 (ISA).
Treiber ist jeweils sb.o, also nicht ALSA. Hat sich bei Kernel 2.4 und/oder bei XFree 4 was Grundlegendes beim DMA-Handling getan, dass die (ISA-)Soundkarte so schnell zu kurz kommt?
bye, Chris
On Sat May 04, 2002 at 01:12:36PM +0200, Christian Perle wrote:
es dann erstens bei jedem Plattenzugriff knacksen müsste, und zweitens weil ich die gleiche Hardware schon unter meiner alten SuSe lief, und da knackste im X nix.
Hat jemand schonmal mit einem solchen Problem zu tun?
So was aehnliches. Seit ich auf meinem (zugegeben etwas antiquierten) Rechner von Kernel 2.2 auf Kernel 2.4 und von XFree 3 auf XFree 4 umgestellt habe, gibt es Sound-Aussetzer, wenn ich unter X ein Fenster mit Inhalt bewege.
Mh, ich den 2.4.17 und XFree 4.1.0-14 Ich glaube aber nicht, dass das am X liegt. Ich denke, es ist sonse Prioriät bei Treibern. Nur hab ich da keine Ahnung von.
Friedrich
Hi Friedrich,
On Sat, May 04, 2002 at 12:51:56 +0200, Friedrich Hagedorn wrote:
Mh, ich den 2.4.17 und XFree 4.1.0-14 Ich glaube aber nicht, dass das am X liegt. Ich denke, es ist sonse Prioriät bei Treibern. Nur hab ich da keine Ahnung von.
Welche Soundkarte (bzw. welches Sound-Kernelmodul) ist denn bei Dir im Einsatz?
bye, Chris
On Sat May 04, 2002 at 01:21:31PM +0200, Christian Perle wrote:
Mh, ich den 2.4.17 und XFree 4.1.0-14 Ich glaube aber nicht, dass das am X liegt. Ich denke, es ist sonse Prioriät bei Treibern. Nur hab ich da keine Ahnung von.
Welche Soundkarte (bzw. welches Sound-Kernelmodul) ist denn bei Dir im Einsatz?
snd-card-ens1370.o ist bei mir geladen. Also en ASLA-Treiber.
Friedrich
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Saturday 04 May 2002 13:11, Friedrich Hagedorn wrote:
On Sat May 04, 2002 at 01:21:31PM +0200, Christian Perle wrote:
Mh, ich den 2.4.17 und XFree 4.1.0-14 Ich glaube aber nicht, dass das am X liegt. Ich denke, es ist sonse Prioriät bei Treibern. Nur hab ich da keine Ahnung von.
Welche Soundkarte (bzw. welches Sound-Kernelmodul) ist denn bei Dir im Einsatz?
snd-card-ens1370.o ist bei mir geladen. Also en ASLA-Treiber.
Klingt nach einer OnBoard-Soundcard. Wenn nicht, vergiss diese Mail.
OnBoard's habe erstens sehr miese Chips und werden dann auch noch vom Bus stiefmuetterlich behandelt. Die meisten sind eigentlich nicht Multitasking-OS-faehig.
Ausserdem hat sich in XFree4 die Behandlung der Maus und das Grafik-timing geaendert - es kann also durchaus sein, dass X jetzt mehr Prioritaet hat als der Soundtreiber, was fuer Low-Cost-Chips fatal ist (u.A. wegen zu kleinem Pufferspeicher). Gute Soundkarten zahlen sich aus. Besonders auf belasteten Systemen.
Konrad
- -- Is truth not truth for all? -- Natira, "For the World is Hollow and I have Touched the Sky", stardate 5476.4.
On Sat May 04, 2002 at 02:37:16PM +0200, Konrad Rosenbaum wrote:
snd-card-ens1370.o ist bei mir geladen. Also en ASLA-Treiber.
Klingt nach einer OnBoard-Soundcard. Wenn nicht, vergiss diese Mail.
Ne, is ne Pci-Karte (cat /proc/pci ...Ensoniq ES1370 [AudioPCI])
Ausserdem hat sich in XFree4 die Behandlung der Maus und das Grafik-timing geaendert - es kann also durchaus sein, dass X jetzt mehr Prioritaet hat als der Soundtreiber, was fuer Low-Cost-Chips fatal ist (u.A. wegen zu kleinem Pufferspeicher). Gute Soundkarten zahlen sich aus. Besonders auf belasteten Systemen.
Nah, und kann man das mit der Priorität irgendwie ändern?
Friedrich
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Saturday 04 May 2002 14:41, Friedrich Hagedorn wrote:
On Sat May 04, 2002 at 02:37:16PM +0200, Konrad Rosenbaum wrote:
snd-card-ens1370.o ist bei mir geladen. Also en ASLA-Treiber.
Klingt nach einer OnBoard-Soundcard. Wenn nicht, vergiss diese Mail.
Ne, is ne Pci-Karte (cat /proc/pci ...Ensoniq ES1370 [AudioPCI])
Ausserdem hat sich in XFree4 die Behandlung der Maus und das Grafik-timing geaendert - es kann also durchaus sein, dass X jetzt mehr Prioritaet hat als der Soundtreiber, was fuer Low-Cost-Chips fatal ist (u.A. wegen zu kleinem Pufferspeicher). Gute Soundkarten zahlen sich aus. Besonders auf belasteten Systemen.
Nah, und kann man das mit der Priorität irgendwie ändern?
Das ist jetzt alles rumdoktorn an Symptomen (was anderes geht bei Multitasking und Sound nicht):
Du kannst zumindest versuchen die Prioritaet der Sound-Applikation zu erhoehen. (man renice)
Oder Du kannst versuchen einen Preemptive Kernel zusammenzupatchen.
Falls die MP3's von einer CD kommen: *CD-LW reinigen (Reinigungs-CD) -> das verringert die Lesefehler *DMA einschalten -> verringert die Prozessorbelastung um Groessenordnungen *Prefetch-Buffer erhoehen -> verringert die Latenzzeiten, sollte bei MP3 aber nicht wesentlich sein.
So habe ich z.B. meine DVD's fluessig bekommen: hdparm -d 1 -c 1 -a 32 /dev/hdc
Vorsichtig solltest Du aber mit DMA- und PIO-Modes sein. Sowohl Chipsatz, als auch Laufwerk muessen den jeweiligen Mode unterstuetzen. (Bei CD-Rom nicht so kritisch, bei Platten und anderen beschreibbaren Medien potentiell toetlich.)
Schau mal, ob die Soundkarte Parameter fuer Puffergroessen oder andere Tuning-Parameter hat.
cat /proc/interrupts zeigt Dir welchen Interrupt die SK hat. Falls sie sich den Int mit einer anderen teilt versuch mal sie in einen anderen Slot zu schieben, damit sie ihren eigenen hat.
Viel Spass und Glueck.
Konrad
- -- BOFH excuse #324:
Your packets were eaten by the terminator
On Sat May 04, 2002 at 03:11:44PM +0200, Konrad Rosenbaum wrote:
Ausserdem hat sich in XFree4 die Behandlung der Maus und das Grafik-timing geaendert - es kann also durchaus sein, dass X jetzt mehr
es könnte wirklich an X und Maus liegen (Vermutung)
Prioritaet hat als der Soundtreiber, was fuer Low-Cost-Chips fatal ist (u.A. wegen zu kleinem Pufferspeicher). Gute Soundkarten zahlen sich aus. Besonders auf belasteten Systemen.
Nah, und kann man das mit der Priorität irgendwie ändern?
Das ist jetzt alles rumdoktorn an Symptomen (was anderes geht bei Multitasking und Sound nicht):
Mhh, aber wie sieht das bei anderen aus? Es muss doch möglich sein, einer Soundanwendung trotz X pünklich Daten zu liefern. top sagt: PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME COMMAND ... 395 fredy 9 0 3416 3416 3160 S 3.7 1.3 0:14 mpg321 ...
Immerhin sind es ja nur 3.7% die meine CPU verbraucht, um mp3 zu dekodieren.
Du kannst zumindest versuchen die Prioritaet der Sound-Applikation zu erhoehen. (man renice)
hab es versucht zB von 0 auf 15 bringt nix.
395 tty2 00:00:26 mpg321 renice 15 -p 395 395: Alte Priorität: 0, neue Priorität: 15
Schau mal, ob die Soundkarte Parameter fuer Puffergroessen oder andere Tuning-Parameter hat.
cat /proc/interrupts
11: 10881 XT-PIC HiSax, usb-ohci, Ensoniq AudioPCI
Ok, aber die anderen Sachen sind ja sonst ganz ruhig.
Folgendes Vorgehen hab ich beobachtet: mpg321 *.mp3 auf einer Konsole gestartet, Sound kommt ok. Wenn Ich jetzt ins X schalte, knackst es mal kurz, und wenn ich dann ein xterm Fenster mit der Maus bewege, krrsssschhhhrrrrsssss Wenn ich dann wieder in die Konsole schalte, wird der Sound ungefair aller halben Sekunden unterbrochen, klingt wie verschuckt, oder als würde sich ein ganz kleiner Abschnitt immer doppeln.
Und das mit einenm ALSA Treiber und dem Kernel Treiber. Ich glaub nicht, dass das ein 'normales' Verhalten einer Soundanwendung trotz Multitasking ist. Meine alte SuSe machete da keine Probleme (deswegen installier ich sie mir aber nicht nochmal :-) Wie klingen mp3's unter X bei anderen?
Danke, Friedrich
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Saturday 04 May 2002 16:17, Friedrich Hagedorn wrote:
On Sat May 04, 2002 at 03:11:44PM +0200, Konrad Rosenbaum wrote:
Ausserdem hat sich in XFree4 die Behandlung der Maus und das Grafik-timing geaendert - es kann also durchaus sein, dass X jetzt mehr
es könnte wirklich an X und Maus liegen (Vermutung)
Prioritaet hat als der Soundtreiber, was fuer Low-Cost-Chips fatal ist (u.A. wegen zu kleinem Pufferspeicher). Gute Soundkarten zahlen sich aus. Besonders auf belasteten Systemen.
Nah, und kann man das mit der Priorität irgendwie ändern?
Das ist jetzt alles rumdoktorn an Symptomen (was anderes geht bei Multitasking und Sound nicht):
Mhh, aber wie sieht das bei anderen aus? Es muss doch möglich sein, einer Soundanwendung trotz X pünklich Daten zu liefern. top sagt: PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME COMMAND ... 395 fredy 9 0 3416 3416 3160 S 3.7 1.3 0:14 mpg321 ...
Immerhin sind es ja nur 3.7% die meine CPU verbraucht, um mp3 zu dekodieren.
Moderne Karten haben normalerweise recht grosse Puffer, da stoert es nicht, wenn 200ms lang keine Daten geliefert werden koennen. Ein Multitasking System hat immer das Problem, dass es sehr viele parallele Tasks gleichzeitig behandeln muss. Da die richtige Prioritaet zu finden ist fuer einen Rechner unmoeglich. Du musst ihm also Tipps geben...
Ausnahme: man koennte Sound als Realtime-Task einstufen. Zu dumm, dass die Ansteuerung der GraKa, der Laufwerke etc.pp. auch in diese Klasse faellt (weil zu viele Controller nicht damit klar kommen, wenn Daten nicht rechtzeitig abgeholt werden).
Du kannst zumindest versuchen die Prioritaet der Sound-Applikation zu erhoehen. (man renice)
hab es versucht zB von 0 auf 15 bringt nix.
395 tty2 00:00:26 mpg321 renice 15 -p 395 395: Alte Priorität: 0, neue Priorität: 15
Das ist verkehrt herum. Unix/Linux hat keine Prioritaet, sondern einen Nice-Wert, also einen Nettigkeitsindex. Du musst den Prozess "un-nett" machen: renice -20 -p 395
(bei xmms alle 5 Prozesse)
Vorsicht: nice heruntersetzen geht nur als root.
Schau mal, ob die Soundkarte Parameter fuer Puffergroessen oder andere Tuning-Parameter hat.
cat /proc/interrupts
11: 10881 XT-PIC HiSax, usb-ohci, Ensoniq AudioPCI
Ok, aber die anderen Sachen sind ja sonst ganz ruhig.
Haengt die Maus am USB? (tut sie jedenfalls bei mir, genauso wie die Tastatur)
Folgendes Vorgehen hab ich beobachtet: mpg321 *.mp3 auf einer Konsole gestartet, Sound kommt ok. Wenn Ich jetzt ins X schalte, knackst es mal kurz, und wenn ich dann ein xterm Fenster mit der Maus bewege, krrsssschhhhrrrrsssss Wenn ich dann wieder in die Konsole schalte, wird der Sound ungefair aller halben Sekunden unterbrochen, klingt wie verschuckt, oder als würde sich ein ganz kleiner Abschnitt immer doppeln.
Timing. X nimmt mp123 CPU-Zyklen weg. Warum das passiert ist eine andere Frage. (s.u.)
Und das mit einenm ALSA Treiber und dem Kernel Treiber. Ich glaub nicht, dass das ein 'normales' Verhalten einer Soundanwendung trotz Multitasking ist.
Doch, ist es. Du hast bei Sound auf Multitasking eine Wahrscheinlichkeit mit der Du rechtzeitig CPU- und Bus-Ressourcen bekommst. Die ist bei Dir aber eindeutig zu gering, um es als angenehm bezeichnen zu koennen.
Meine alte SuSe machete da keine Probleme (deswegen installier ich sie mir aber nicht nochmal :-) Wie klingen mp3's unter X bei anderen?
Einwandfrei bei mir. Aber ich habe auch vergleichsweise teure Hardware (Bi-Athlon mit AMD-Chipsatz, SBLive, Matrox G550 GraKa, etc.pp.).
Ok, es ging also auf SuSE. Analysier mal bitte die Unterschiede:
*Version von XFree *GraKa *GraKa Treiber/Parameter *Framebuffer *neue Hardware *Sound-Treiber *Preemption Patch im Kernel *durchschnittliche Speicherauslastung (buffer/cache zaehlt nur als sekundaerer Wert) *Puffergroesse Deines MP3-Players (ich habe bei meinem alten Rechner mal Probleme unter Hochlast geloest, indem ich den Puffer auf 512kB hochgesetz habe) *Optimierung der Laufwerke (siehe andere Mail, evtl. wartet das Programm zu lange auf Daten, wenn der Bus anderweitig (mit Grafik) beschaeftigt ist - laesst sich mit hdparm und Puffer loesen)
Vielleicht fallen Dir noch weitere Kriterien ein.
Der Aussetzer beim Umschalten des Grafikmodus laesst sich aber nur mit zwei Ansaetzen bearbeiten: Preemption Patch und Puffer auf der Soundkarte selbst (zumindest der offizielle Kerneltreiber scheint da nix zu kennen, also nutzt er wahrscheinlich schon den vollen Puffer).
Konrad
- -- BOFH excuse #138:
BNC (brain not (user brain not connected)
On Sat May 04, 2002 at 04:49:51PM +0200, Konrad Rosenbaum wrote:
es könnte wirklich an X und Maus liegen (Vermutung)
Ausnahme: man koennte Sound als Realtime-Task einstufen. Zu dumm, dass die Ansteuerung der GraKa, der Laufwerke etc.pp. auch in diese Klasse faellt (weil zu viele Controller nicht damit klar kommen, wenn Daten nicht rechtzeitig abgeholt werden).
Ist das auch der Grund, warum das ganze System hängt, wenn eine CD-Rom eingelesen wird?
Das ist verkehrt herum. Unix/Linux hat keine Prioritaet, sondern einen Nice-Wert, also einen Nettigkeitsindex. Du musst den Prozess "un-nett" machen: renice -20 -p 395
(bei xmms alle 5 Prozesse)
Da wird es etwas besser, das knacksen geht erstmal deutlich zurück. Wenn ich jetzt xterm verchiebe, hört es sich an, als würden immer ein paar Milisekunden fehlen.
Vorsicht: nice heruntersetzen geht nur als root.
Schau mal, ob die Soundkarte Parameter fuer Puffergroessen oder andere Tuning-Parameter hat.
cat /proc/interrupts
11: 10881 XT-PIC HiSax, usb-ohci, Ensoniq AudioPCI
Ok, aber die anderen Sachen sind ja sonst ganz ruhig.
Haengt die Maus am USB? (tut sie jedenfalls bei mir, genauso wie die Tastatur
Oh, diese Idee ist gut. Das könnte auch der Grund sein, warum es bei SuSe damals ging, da ich da glaub ich noch keine USB-Tastatur/Maus hatte.
Dann werd ich mal versuchsweise ne PS2 Tastatur und ne alte serielle Maus anschliessen. Aber einfacher wäre ja, der Soundkarte einen anderen Interrupt zuweisen? Ich werde mal die Karte umstecken. Würde es aber über eine Umkonfiguration gehen?
Danke, Friedrich
On Sat May 04, 2002 at 06:00:53PM +0200, Friedrich Hagedorn wrote:
On Sat May 04, 2002 at 04:49:51PM +0200, Konrad Rosenbaum wrote:
Haengt die Maus am USB? (tut sie jedenfalls bei mir, genauso wie die Tastatur
Oh, diese Idee ist gut. Das könnte auch der Grund sein, warum es bei SuSe damals ging, da ich da glaub ich noch keine USB-Tastatur/Maus hatte.
Ich hab im Bios bissel was verändert, so dass die Soundkarte jetzt ihren eigenen Interrupt hat: 5: 245 XT-PIC HiSax, usb-ohci 8: 1 XT-PIC rtc 10: 7087 XT-PIC usb-ohci 12: 1012 XT-PIC Ensoniq AudioPCI
Aber das Problem ist noch genauso da, wie vorhin beschrieben. Das komische war jetzt eben: Wenn ich bei meiner Tastatur Num-Lock anschalte, bracht das beim ersten Mal ein wenig bis das zum USB-Kontroler durch ist. Es kommst dann immer folgendes: keyboard: Timeout - AT keyboard not present?(ed) keyboard: Timeout - AT keyboard not present?(f4)
Dann ist NUM-Lock an. Und in dieser Zeit hatte gerade der Sound vollkommen ausgesetzt...komisch ?!
Friedrich
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Saturday 04 May 2002 18:33, Friedrich Hagedorn wrote:
On Sat May 04, 2002 at 06:00:53PM +0200, Friedrich Hagedorn wrote: Das komische war jetzt eben: Wenn ich bei meiner Tastatur Num-Lock anschalte, bracht das beim ersten Mal ein wenig bis das zum USB-Kontroler durch ist. Es kommst dann immer folgendes: keyboard: Timeout - AT keyboard not present?(ed) keyboard: Timeout - AT keyboard not present?(f4)
Dann ist NUM-Lock an. Und in dieser Zeit hatte gerade der Sound vollkommen ausgesetzt...komisch ?!
Du scheinst ein wirklich schlimmes Problem mit Interrupts am USB zu haben. Was ist das fuer ein Controller (wenn onBoard - was ist das fuer ein Mainboard/Chipsatz)?
Konrad
- -- BOFH excuse #246:
It must have been the lightning storm we had (yesterdy) (last week) (last month)
On Sun May 05, 2002 at 12:17:37AM +0200, Konrad Rosenbaum wrote:
Du scheinst ein wirklich schlimmes Problem mit Interrupts am USB zu haben. Was ist das fuer ein Controller (wenn onBoard - was ist das fuer ein Mainboard/Chipsatz)?
Der USB-Controller ist OnBoard. Es ist ein ELITEGROUP K7S5A mit einem SIS735 Chipsatz.
Allerding kann es nicht am USB liegen. Hab es gerade getestet. Hab nur eine PS2-Tastatur angeschlossen, und alle USB-Treiber entfernt inklusieve von gpm. Neustart. In der Konsole mp3 mit freeamp laufen lassen. Und wenn ich dann im X mit der Tastatus ein xterm verschiebe, krrrssss. Und wenn ich wieder zurück in die Konsole schalte, sind immer noch die kleinen Aussetzter. Erst wenn ich etwas weiterspule, kommt der Sound wieder normal. Also gleiches Problem, wie vorher.
Bei meiner alten SuSe hatte ich glaub ich XFree 3.3.x So langsam glaub ich, dass das mit XFree 4.1.0 zu tun hat?! Bei wem laufen mp3's unter diesem X und einer ens1370 ganz normal?
Danke, Friedrich
Am Sonntag, 5. Mai 2002 12:13 schrieb Friedrich Hagedorn: ... Bei meiner alten SuSe hatte ich glaub ich XFree 3.3.x So langsam glaub ich, dass das mit XFree 4.1.0 zu tun hat?! Bei wem laufen mp3's unter diesem X und einer ens1370 ganz normal?
Danke, Friedrich
Ich habe ens1371 und keine Probleme mit mp3 unter XFree 4.1.0 mit SuSE 7.2. Belegt werden IRQ 5 und I/O-Port e800-e83f.
Viel Erfolg Uwe
On Sun May 05, 2002 at 01:00:43PM +0200, Uwe Kietzmann wrote:
Am Sonntag, 5. Mai 2002 12:13 schrieb Friedrich Hagedorn: ... Bei meiner alten SuSe hatte ich glaub ich XFree 3.3.x So langsam glaub ich, dass das mit XFree 4.1.0 zu tun hat?! Bei wem laufen mp3's unter diesem X und einer ens1370 ganz normal?
Ich habe ens1371 und keine Probleme mit mp3 unter XFree 4.1.0 mit SuSE 7.2.
Dacht ich mir. Und bei Debianern?
Belegt werden IRQ 5 und I/O-Port e800-e83f.
Mh, ich kann das nicht verstehen?! Gibt es irgendein Tool, mit dem man feststellen oder aufzeichen kann, was gerade für ein Prozess/Interrupt läuft und von wo der kommt. Damit ich den Prozess rausbekomme, der die Soundausgabe unterbricht, immer wenn ich auf X bin.
Oder kann es sein, dass ein Device (/dev/dsp) eine zu niedrige Priorität hat?
Danke, Friedrich
On Sun, May 05, 2002 at 09:31:41PM +0200, Friedrich Hagedorn wrote:
Mh, ich kann das nicht verstehen?! Gibt es irgendein Tool, mit dem man feststellen oder aufzeichen kann, was gerade für ein Prozess/Interrupt läuft und von wo der kommt. Damit ich den Prozess rausbekomme, der die Soundausgabe unterbricht, immer wenn ich auf X bin.
xosview
Damit siehst Du aber nur welche Interrupts gerade reinkommen. Ausgelöst werden die Interrupts von der Hardware.
Oder kann es sein, dass ein Device (/dev/dsp) eine zu niedrige Priorität hat?
Device und Prioritäten? Passt mMn nicht zusammen
Bert
On Sun, 05 May 2002 21:31:41 +0200, Friedrich Hagedorn wrote:
Mh, ich kann das nicht verstehen?! Gibt es irgendein Tool, mit dem man feststellen oder aufzeichen kann, was gerade für ein Prozess/Interrupt läuft und von wo der kommt. Damit ich den Prozess rausbekomme, der die Soundausgabe unterbricht, immer wenn ich auf X bin.
$ sar -I ALL 2 0
zeigt aller 2 Sekunden an, was für Intrs es gab (Paket sysstat)
Reinhard
Verfolgen wir doch 'mal den Weg der Daten: 1. Digital (vereinfacht) Festplatte -> Bus -> Prozessor -> Speicher -> Prozessor -> Bus -> Soundkarte 2. Analog: Soundkarte -> Ausgang An welcher Stelle kommt das Knacksen dazu? Um das Herauszufinden teste mal, ob ein anderes Datenformat (wav oder CD-Audiospur) auch knackst. Wenn ja, dann ist es das diskutierte IRQ-Latenzproblem. Und das läßt sich eben nicht durch irgendwelche Manipulationen am Bus beheben, sonder nur durch Begrenzen der Zeitscheibe, die sich der X-Server genehmigt. Falls die nämlich so groß ist, daß in dieser Zeit der Datenstrom an der Soundkarte abreißt, hilft auch kein renice, weder beim Soundprozess noch beim X-Server. Hier sehe ich nur zwei mögliche Lösungen: 1. bessere Hardware (mehr Speicher auf der Soundkarte) 2. Feintuning am X-Server (Time slice heruntersetzen)
Tilman Heinrich
On Mon May 06, 2002 at 03:13:18PM +0200, Tilman Heinrich wrote:
Verfolgen wir doch 'mal den Weg der Daten:
- Digital (vereinfacht)
Festplatte -> Bus -> Prozessor -> Speicher -> Prozessor -> Bus -> Soundkarte 2. Analog: Soundkarte -> Ausgang An welcher Stelle kommt das Knacksen dazu? Um das Herauszufinden teste mal, ob ein anderes Datenformat (wav oder CD-Audiospur) auch knackst. Wenn ja,
Danke erstmal für Deine Gedanken. Erstmal noch eine andere Frage. Könnte es sein, dass der kapm-idled Prozess dafür verantwortlich ist. Was ich gelesen hab, lastet er die CPU im Ruhezustand aus, indem der der CPU HLT-Befehle schickt, um Strom zu sparen. Die Aktivit des Prozesses geht aber bei andere Belastungen zurück. Kann es sein, dass kapm-idled nicht richtig arbeitet, und beim Multitasking dazwischen kommt?
Ergebnisse: 1. Beim normalen CD anhören knackst überhaupt nix. Ist aber auch normal, weil ja die Analogen Signale vom CD-Rom direkt auf die Soundkarte gehen und verstärkt werden. IRQ 12 (Soundkarte) blinkt im xosview auch nicht auf.
2. Wav mit play anhören. Wenn ich im X bin und nix mache, kanckst es immer dann, wenn IRQ 12 betätigt wird. So ca. aller 1.5 Sekunden. Wenn ich jedoch im Netscape skrolle knirscht/zirpt es richtig.
3. mp3's mit mpg321 (freeamp) im Prinzip wie 2. jedoch öftern. IRQ 12 wird ungefair zweimal in der Sekunde aufgerufen, und dann "zappt" es. Bei Skrollen im Netscape das gleiche zirpen.
Das kann doch nicht "normal" sein. Bei dem einen gehts bei mir nicht. Hey, das is nicht ok :-)
Danke fürs Mitraten, Friedrich
On Mon, 06 May 2002 20:04:34 +0200, Friedrich Hagedorn wrote:
Das kann doch nicht "normal" sein. Bei dem einen gehts bei mir nicht. Hey, das is nicht ok :-)
Ich habe nicht den ganzen Thread verfolgt ... sorry falls das schon kam:
Ich würde auf gut Glück erstmal mit der PCI-Latency (im BIOS) und Abschalten von HLT beim Däumchendrehen (Kerneloption "no-hlt") rumspielen.
Auf alle Fälle solltest du dir mal das "Linux Audio-Quality-HOWTO" [1] reinziehen. Da gibts u.a. einen Abschitt namens "Video Cards from Hell". Das paßt doch, oder? ;-) Oder frag google mal nach "crackling sound" Viel Leutchen kämpfen mit dem Problem.
Reinhard
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Saturday 04 May 2002 18:00, Friedrich Hagedorn wrote:
On Sat May 04, 2002 at 04:49:51PM +0200, Konrad Rosenbaum wrote:
es könnte wirklich an X und Maus liegen (Vermutung)
Ausnahme: man koennte Sound als Realtime-Task einstufen. Zu dumm, dass die Ansteuerung der GraKa, der Laufwerke etc.pp. auch in diese Klasse faellt (weil zu viele Controller nicht damit klar kommen, wenn Daten nicht rechtzeitig abgeholt werden).
Ist das auch der Grund, warum das ganze System hängt, wenn eine CD-Rom eingelesen wird?
Ja.
Haengt die Maus am USB? (tut sie jedenfalls bei mir, genauso wie die Tastatur
Oh, diese Idee ist gut. Das könnte auch der Grund sein, warum es bei SuSe damals ging, da ich da glaub ich noch keine USB-Tastatur/Maus hatte.
Dann werd ich mal versuchsweise ne PS2 Tastatur und ne alte serielle Maus anschliessen. Aber einfacher wäre ja, der Soundkarte einen anderen Interrupt zuweisen? Ich werde mal die Karte umstecken. Würde es aber über eine Umkonfiguration gehen?
PCI funktioniert da etwas ... aehmm .... komplizierter.
Der PCI/AGP Bus hat exakt vier Interrupt-Leitungen (der Einfachheit halber hat man sie A, B, C und D genannt). Jeder Slot ist an exakt eine Leitung angeschlossen. Da aber mehr als 4 PCI/AGP-Geraete in einem Rechner stecken (alle PCI-Slots, der AGP-Slot, 2 Platten- und 1 Floppy-Controller, USB, ISA-Bridge, etc.) teilen sich mehrere Geraete eine Leitung. Man kann leider nicht einstellen, welcher Slot auf welcher Leitung haengt, die meisten BIOSse lassen Dich aber einstellen welche Leitung welchen Interrupt bedient.
Mit BIOS-Konfigurationen kommst Du also nur weiter, wenn zwei Leitungen auf dem selben Interrupt haengen.
Konrad
- -- BOFH excuse #407:
Route flapping at the NAP.
On Sat, 04 May 2002 23:55:23 +0200, Konrad Rosenbaum wrote:
PCI funktioniert da etwas ... aehmm .... komplizierter.
Der PCI/AGP Bus hat exakt vier Interrupt-Leitungen (der Einfachheit halber hat man sie A, B, C und D genannt). Jeder Slot ist an exakt eine Leitung angeschlossen.
Falsch. Bei jedem PCI-Slot müssen zwingend alle 4 Leitungen INTA# bis INTD# auch verschaltet sein. Also nix mit "exakt eine Leitung". Es gibt durchaus PCI-Karten, die mehrere Int-Strippen nutzen (z.B. Netzkarten mit 2 Controllern ohne PCI-Bridge). Der AGP-Slot hat meines Wissens nur 2 Kontakte für Ints (INTA#,INTB#)
Da aber mehr als 4 PCI/AGP-Geraete in einem Rechner stecken (alle PCI-Slots, der AGP-Slot, 2 Platten- und 1 Floppy-Controller, USB, ISA-Bridge, etc.) teilen sich mehrere Geraete eine Leitung.
Nicht zwingend. Wenn du z.B. 6 PCI-Slots hast, sind die nicht einfach so busartig auf dem Board verdrahtet. Üblicherweise ist z.B. der oft genutzte INTA# bei jedem Slot auf eine andere Strippe geschaltet. Was an Slot1 an INTA# hängt, kann dann gern nochmal an Slot2 INTC# hängen usw. Da wohl 9x% der PCI-Karten nur INTA# nutzen, muß es in der Praxis zu keiner Mehrfachnutzung von Int-Leitungen durch mehrere Geräte kommen.
Wenn man vom VIA-Schrott absieht, haben die Chisets heutzutage mehr als 4 Eingänge für PCI am IRQ-Router. Bei ordentlich gebauten Boards mit Intel-Chipsets kann damit 8 PCI-Geräte (z.B. 5 Slots, 3 Onboard), die alle INTA# nutzen, auf 8 verschiedenen Leitungen zum IRQ-Router leiten und dann auch auf 8 verschiedene IRQs am (A)PIC mappen.
Die Aussage, daß es bei mehr als 4 PCI-Geräten notwendigerweise zu IRQ-Sharing kommt, ist also falsch.
Reinhard
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Sunday 05 May 2002 01:24, Reinhard Foerster wrote:
On Sat, 04 May 2002 23:55:23 +0200, Konrad Rosenbaum wrote:
PCI funktioniert da etwas ... aehmm .... komplizierter.
Der PCI/AGP Bus hat exakt vier Interrupt-Leitungen (der Einfachheit halber hat man sie A, B, C und D genannt). Jeder Slot ist an exakt eine Leitung angeschlossen.
Falsch. Bei jedem PCI-Slot müssen zwingend alle 4 Leitungen INTA# bis INTD# auch verschaltet sein. Also nix mit "exakt eine Leitung". Es gibt durchaus PCI-Karten, die mehrere Int-Strippen nutzen (z.B. Netzkarten mit 2 Controllern ohne PCI-Bridge). Der AGP-Slot hat meines Wissens nur 2 Kontakte für Ints (INTA#,INTB#)
Oh, stimmt. Der c't Artikel aus dem ich meine "Weisheit" habe hatte das glaube ich so illustriert:
Dev1: ABCD Dev2: BCDA Dev3: CDAB Dev4: DABC
Wenn man vom VIA-Schrott absieht, haben die Chisets heutzutage mehr als 4 Eingänge für PCI am IRQ-Router. Bei ordentlich gebauten Boards mit Intel-Chipsets kann damit 8 PCI-Geräte (z.B. 5 Slots, 3 Onboard), die alle INTA# nutzen, auf 8 verschiedenen Leitungen zum IRQ-Router leiten und dann auch auf 8 verschiedene IRQs am (A)PIC mappen.
Die Aussage, daß es bei mehr als 4 PCI-Geräten notwendigerweise zu IRQ-Sharing kommt, ist also falsch.
Du meinst es koennte durchaus so weitergehen?:
Dev5: EFGH Dev6: FGHE etc.
Konrad
- -- There is a multi-legged creature crawling on your shoulder. -- Spock, "A Taste of Armageddon", stardate 3193.9
On Sun, 05 May 2002 12:41:57 +0200, Konrad Rosenbaum wrote:
Dev1: ABCD Dev2: BCDA Dev3: CDAB Dev4: DABC
Du meinst es koennte durchaus so weitergehen?:
Dev5: EFGH Dev6: FGHE etc.
ja. Für den 0815-PC ist sowas sehr vernünftig. Das theoretisch problemlose IRQ-Sharing geht viel zu oft schief. In Richtige Rechner (TM) würden man für 8 PCI Geräte sowieso mehrere PCI-Busse einbauen.
Reinhard
Reinhard Foerster wrote:
ja. Für den 0815-PC ist sowas sehr vernünftig. Das theoretisch problemlose IRQ-Sharing geht viel zu oft schief. In Richtige Rechner (TM) würden man für 8 PCI Geräte sowieso mehrere PCI-Busse einbauen.
Der Magic Chipsatz für den Athlon hat ja mal einen Anfang gemacht mit 7 (oder waren es 8??) IRQ-Leitungen für den PCI-Bus. Vernünftiger sind natürlich getrennte Busse, die können sich nicht gegenseitig in die Quere kommen.
Roland
Hi Friedrich
Du kannst zumindest versuchen die Prioritaet der Sound-Applikation zu erhoehen. (man renice)
hab es versucht zB von 0 auf 15 bringt nix.
395 tty2 00:00:26 mpg321 renice 15 -p 395 395: Alte Priorität: 0, neue Priorität: 15
0 ist die Defaulteinstellung. Größere Zahlen bedeuten netter ==> Du hast dir also in den Fuß geschossen. Dein Prozess kommt fast nicht mehr dran. Als Root darfst du auch weniger nett sein (bis -20)
Jens Weiße
lug-dd@mailman.schlittermann.de
-
Bert Lange -
Christian Perle -
Friedrich Hagedorn -
Jan Wagner -
Jens Weiße -
Konrad Rosenbaum -
Reinhard Foerster -
Roland Müller -
Steffen Liebergeld -
Tilman Heinrich -
Uwe Kietzmann