KDE, xmms und stotternder Sound

[eman]

Hallo Gemeinde,

ich habe bei mir KDE 3.2.3, xmms 1.2.10, Kernel 2.6.8.1 mit alsa-sound laufen. Seltsamerweise kann die CPU-Auslastung 100% betragen, xmms läuft ohne Probleme weiter. Sobald ich aber anfange, ein Fenster zu verschieben, die Arbeitsfläche zu wechseln oder sonst irgendeine "Fensteraktion" ausführe, die die CPU nicht mal auf 10% hochbringt, stockt der Sound bzw. der Sound-Puffer wird nicht mehr neu gefüllt, sodass eine Endlossschleife eines Soundschnipsels zu hören ist.

Okay, kurzer Nachtrag: Wenn ich ein Fenster ein paar Pixel verschiebe, sodass der Rahmen der neuen Position erscheint und ich anschließend die Maus nicht mehr bewege, bleiben alle Anwendungen stehen. (Am Sound merkt man es am ehesten, dass sich nichts mehr rührt.)

Kennt jemand das Problem und die Lösung?

Vielen Dank,
Erik

[Allo]

threaded oss brauch manchmal wesentlich weniger cpu(eigentlich nur bei oss vorher...alsa sollte auch gehen)

in kcontrol kannst du die priorität und den soundpuffer einstellen
dein xmms problem ist, dass der xmms das sounddevice sperrt, und der artsd wenn er sound machen will, das nicht kann.
Das bringt KDE manchmal ins stocken.
Ein xmms arts plugin hilft(dann benutzt der auch arts)


Allo

[eman]

Hallo Allo,

danke für deine Antwort. Wahrscheinlich willst du darauf hinaus, dass sich irgendwie OSS und artsd gegenseitig behindern. Allerdings hab ich mein alsa ohne OSS-Schnittstelle kompiliert (im Kernel), der arts-Dämon wird nicht gestartet und läuft auch nicht und xmms benutzt das alsa-output-plugin, sodass an der Stelle eigentlich kein Problem auftreten kann.

Das Problem reduziert sich darauf, dass alle anderen Programme angehalten werden (zu sehen bspw. an der Auslastungsanzeige im KPanel), solange ein Fenster in der Verschiebephase ist.

Kann der KDE-Fenstermanager daran schuld sein?

Ratlos,
Erik

[Allo]

also gut, oss ist nicht...

also wenn du auf eine device(alsa oder oss) zugreifst, dann ist das für alles andere gesperrt.
deswegen supsended der artsd automatisch nach einer zeit.
dann kann man wieder xmms nehmen.
wenn der jetzt wieder sound spielen soll, ist das device vom xmms gesperrt.
wenn du xmms mit artsd verwendest, dann spielt der xmms über den artsd und der mithilfe des devices.
der mischt die soundeffekte dann mit der musik und es ist gut.


Allo

[pub]

so gesagt: der arts ist ein soundserver der die streams vor der soundkarte abfängt, mixt und dann an die soundkarte weitergibt. somit ist es möglich mehrere sounds gleichzeitig abzuspielen. die player müssen aber ein plugin für den soundserver haben. bei xmms ist es für arts halt xmms-artsd plugin.
soundserver: esd, arts, gstreamer
soundtreiber: alsa, oss
als beispiel.
das ist ja die grosse krankheit bei linux. es gibt leider keinen einheitlichen soundserver. das macht es kompliziert. wenn deine karte also kein hardwaremixing beherrscht bist du auf softwaremixing angewiesen.
man hat wenigstens bei den treibern ein einheitliches konzept, doch beim soundserver nutzt man verschieden.
gnome : esd
kde : arts
irgendwasanderes : wiederwasanderes

viellleicht hat gstreamer ja eine chance das zu werden. abwarten.

[eman]

Danke nochmal soweit für die Hilfe, ich hab mich auf der KDE-Liste noch ein wenig mehr umgesehen und bin auf den BUG 68843 http://bugs.kde.org/show_bug.cgi?id=68843 gestoßen, der genau das beschreibt. Es ist also ein Problem, das alle Anwendungen (und xmms besonders) beim Schieben von Fenstern (egal ob nur als Rahmen oder mit kompletten Inhalt) "stehenbleiben". Unter diesem Bug hängen noch mehrere Querverbindungen zu ähnlichen Problemen. Wenn ich die Beschreibungen richtig lese, scheinen die Probleme in unterschiedlichen KDE-Versionen aufzutreten und teilweise bereits gefixt gewesen zu sein. Also bleibt nur abwarten und Tee trinken .

THX
Erik