-----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)