Habe bereits eine Antwort allerdings PM erhalten, die so einiges klärt. Ich poste sie hier, falls noch jemand dasselbe Problem hat oder haben wird - wie auch immer... ;-) Am Sonntag, 21. November 2004 14:27 schrieben Sie:

Am Samstag, 20. November 2004 19:35 schriebst du:

...

(...). Oder kurz: Wer sich als erster anmeldet ist der einzige mit Sound. Dasselbe Problem tritt übrigens auch beim Brennen auf. Wenn bereits ein Benutzer angemeldet ist bekommt der 2 keinen Zugriff auf die Laufwerke. K3b sagt dann immer: "Es konnten keine Geräte gefunden werden, es kann nur ein Abbild erstellt werden".

Dieses Problem hat mich sehr viel Zeit gekostet. Also beide. Da spielen zeimlich viele Dinge mit rein. Ab SuSE 8.2 der resmgr, das cdrecord von SuSE ist so gepatcht, daß es diesen nutzt, um schreibenden Zugriff auf die Brenner-Devices zu bekommen. Normalerweise wird nur der Nutzer des ersten X-Servers zugelassen. Das kann man in /etc/resmgr.conf umstellen: # # This rule grants access to users logged in locally # allow desktop tty=/dev/tty[1-9]* || tty=tty[1-9]* || tty=:*

Eigentlich steht dort am Ende der Zeile ein ":0", der Stern erlaubt aber eben über jeden X-Server eingeloggtem Benutzer Zugriff auf eine Reihe von Geräte-Dateien (siehe weiter oben in der Datei). Das Brenn-Problem sollte sich also mit obiger Zeile lösen lassen. Achja, als Schnell-Test, wenn unter dem zweiten Benutzer cdrecord -scanbus schon nicht funktioniert, wird es k3b auch nicht tun.

Der Sound ist deutlich komplizierter: Preiswerte Sound-Karten (z. B. AC97) haben nur einen Kanal, d. h. es können gar nicht zwei Programme gleichzeitig das Sound-Device benutzen. KDE umgeht das mit dem artsd (Soundserver, siehe KDE-Kontrollzentrum): Dieser krallt sich das Sound-Device und mischt den Sound der KDE-Applikationen. Siehst du schon das Problem durch diese Kombination? KDE des zweiten Benutzers kann seinen artsd nicht starten, weil der des ersten schon das Sound-Device blockiert! Im KDE-Kontrollzentrum kann man aber einstellen, nach wieviel Sekunden Inaktivität sich der Soundserver schlafen legt und damit das Device freigibt. Nach dieser Zeit könnte dann KDE des zweiten Benutzers seinen artsd starten. Könnte! Die Rechte sind aber falsch gesetzt, der zweite Benutzer hat gar keine Schreibrechte auf die relevanten (und zahlreichen) benötigten Geräte-Dateien. Man kann ihnen von Hand Gruppen-Schreibrechte geben (die Gruppe audio gibt es schon und die Sound-Geräte-Dateien gehören auch dieser Gruppe), aber nach einem Neustart/-login hat wieder nur der als erstes angemeldete Benutzer Schreibrechte (eigentlich der Benutzer vom ersten X-Server ":0"). Warum? Die Datei /etc/logindevperm macht so ziemlich genau das, was der Name verheißt: Sie setzt beim (X-)Login die Geräte-Datei-Berechtigungen. Und zwar auf 0600, also Schreib- und Leserechte nur für den Eigentümer, nicht für die Gruppe. 0660 müßte bei den geteilten Geräte-Dateien stehn. Sound ist meiner Erfahrung nach aber leider nicht nur eine einzige Geräte-Datei bzw. eine einzige Zeile in obiger Datei, es kommen noch Mixer und irgendwelche anderen Dinge dazu. Bei mir unter Verwendung von ALSA genügen diese Datein: jan@linux:~> chmod 0660 /dev/snd/controlC0 /dev/snd/pcmC0D0p /dev/snd/timer Herausgefunden habe ich das unter dem zweiten Benutzer mit: tv@linux:~> strace aplay /opt/kde3/share/sounds/KDE_Error.wav 2>&1 | o Damit sieht man nämlich recht gut, welche Dateien nicht geöffnet werden können. Sprich, in /etc/logindevperm in folgender Zeile die 0600

:0 0600 /dev/snd/*

durch 0660 ersetzen (siehe oben): :0 0660 /dev/snd/* :

...

Wäre froh, wenn mir jemand beim Sound hilft, das mit dem Brennen ist eher unwichtig, da ich nicht jeden Tag eine CD brenne. ;-)

Es kann sein, daß nach obiger Prozedur immer noch kein Sound kommt, weil beim KDE-Start des zweiten Benutzers noch das Sound-Device blockiert ist. Ich habe hier (zuätzlich zu obigem) auf das dmix-Plugin von ALSA gesetzt. Damit ist es möglich auch bei preiswerten Karten mehrere Kanäle zu nutzen, sprich es spielt artsd, aber eine Ebene tiefer und damit auch für XMMS (ohne arts-Output-Plugin) und sonstige Nicht-KDE-Programme (die aber ALSA unterstützen). Dafür habe ich mirein aktuelles ALSA bei packman geholt: http://packman.links2linux.de/?action=217 Es bringt eine Datei namens /etc/asoundrc.dmix mit, diese kopiert man nach /etc/asound.conf und startet ALSA neu (rcalsasound restart), alles als root oder mit sudo. Danach könnten mehrere Programme gleichzeitig unter einem Benutzer auf das Sound-Device zugreifen. Wieder könnten! Denn das dmix-Plugin bzw. dessen Inter-Prozeß-Kommunikation legt eine Datei in /tmp ab, mit den Rechten 0600. Diese Datei heißt auch immer anders, sodaß man sie nicht mit /etc/logindevperms erschlagen könnte. Die Lösung (ich habe mir den Source von ALSA dafür angeguckt :-) ): In /etc/asound.conf gibt es Zeilen wie ipc_key ... Unter all diese Zeilen schreibst du einfach diese Zeile: ipc_perm 0660 Und schon können auch die Mitglieder der Gruppe audio ALSA mit dem dmix-Plugin benutzen und das sogar gleichzeitig.

Wie du siehst ist das alles eigentlich sehr logisch ... ;-) Zu deiner Problematik und dem dmix-Plugin findest du auch Informationen in den SUSE-ML, in google suchen nach site:lists.suse.com dmix alsa Auf das ipc_perm ist scheinbar aber noch keiner gekommen. .-) Und beim Brenn-Problem verweise viele auf die alte Methode über die Gruppenrechte (wie eben beim Sound), aber ein korrekt konfigurierter resmgr ist um Längen eleganter! site:lists.suse.com resmgr

HTH, Jan

Patrick

Hallo liebe SuSE-Multimedianer, sorry fuer die etwas spaete Antwort ... Patrick Trettenbrein wrote:

Auf meinem System zu Hause ist es so eingerichtet, dass jeder sein eigenes Benutzerkonto hat. Wenn jetzt ich jetzt aber bereits ein paar Studen am PC arbeite und dann will man Vater schnell ins Internet oder irgendetwas anderes am PC machen, wird eben schnell der Benutzer mittels "KDE -> Benutzer wechseln" gewechselt. Da aber bereits jemand auf dem System angemeldet ist, kann für den zweiten Benutzer kein eigener Soundserver erstellt werden oder irgendsowas, zumindest bekommt der 2 Benutzer keinen Sound. Erst wenn sich der zuerst angemeldete wieder abmeldet hat der als 2ter angemeldete nach einer Neuanmeldung wieder Sound. Oder kurz: Wer sich als erster anmeldet ist der einzige mit Sound. Dasselbe [...] Wäre froh, wenn mir jemand beim Sound hilft, das mit dem Brennen ist eher unwichtig, da ich nicht jeden Tag eine CD brenne. ;-)

Zu Device-Rechten u. aehnlichem haben ja nun einige Leute bereits was gesagt, so dass per ALSA/OSS direkt auf die Sound-HW zugegriffen werden kann. Ich haette Infos beizusteuern, wie man aRts mit mehreren Usern nutzen kann. Lange Zeit habe ich aRts fuer etwas gehalten, was man am besten u. moeglichst schnell mit killall -9 totschlaegt ;-) Mittlerweile sehe ich das anders. Dieses netzwerkfaehige Soundsystem ist gar nicht so schlecht, leider bloss seine Doku (IMHO). Unter http://docs.kde.org/en/3.3/kdemultimedia/artsbuilder/ habe ich aber einen Einstieg bekommen u. nach heftigem googlen auch eine Loesung gefunden. Mein Setup: genau EIN Multimedia-User startet einen artsd, und zwar netzwerktransparent. Dazu: Kontrollzentrum -> Sound&Multimedia -> Sound-System Reiter aRts:: arts Server bei KDE Start hochfahren JA Netzwerk-Transparenz aktivieren JA Sicherheits- u. Referenz-Infos per X11 NEIN (Rest egal) Reiter Sound Ein-/Ausgabe: weitere Benutzereinstellungen "-p <PORTNUMMER>" Anmerkung: man kann auch die X11-auth benutzen, dann muss man, glaube ich, auf dem arts-Client ein "ssh -x" zum arts-Server machen. Bei mir auf einem System reicht aber die "/tmp/mcop-XXXXX" Methode. Dann steht in ~/.mcoprc: "GlobalComm=Arts::TmpGlobalComm" (ansonsten GlobalComm=Arts::X11GlobalComm) des Benutzers, der den arts-Server betreibt. Alle uebrigen Benutzer betreiben keinen eigenen arts-Server, sondern benutzen den, den obiger User unter Port <PORTNUMMER> betreibt. Hierzu haben sie denselben .mcoprc Eintrag wie oben u. zusaetzlich eine ENV-Variable: ARTS_SERVER=127.0.0.1:<PORTNUMMER> Der arts-Server koennte auch auf einem anderen System als auf localhost laufen, dann waere aber wahrscheinlich X11GlobalComm sinnvoll. Weiterhin notwendig, damit der Client-User auf den Server zugreifen kann, ist bei der TmpGlobalComm-Methode, dass der secret-cookie sowie einige Arts_*Server* Files aus dem /tmp/mcop-XXXXX Verzeichnis des Benutzers, der den Arts-Server betreibt, in das /tmp/mcop-YYYYY Verzeichnis des zweiten Benutzers kopiert wird. Bei mir macht das fuer die berechtigten Benutzer root mittels folgendem Script: #!/bin/bash # ASU : Arts Server User ASU="NameVonUserDerArtsServerBetreibt" if [ "$1a" == "a" ] then echo "usage: $0 USERNAME" exit 1 else MCOPUSER=$1 fi install -o $MCOPUSER -g audio -m 600 \ /tmp/mcop-$ASU/secret-cookie /tmp/mcop-$MCOPUSER install -o $MCOPUSER -g audio -m 600 \ /tmp/mcop-$ASU/Arts_* /tmp/mcop-$MCOPUSER Offenbar meckert die arts-SW, wenn die die Zugriffsrechte nicht ausreichend restriktiv sind, sonst koennte man viel einfacher mit chmod -R go+rwX auf dem /tmp/mcop-XXXXX hantieren. Auch bei dieser Nutzung von aRts ist wichtig, dass die device permissions fuer arts-Server-User u. arts-Client-User ausreichend sind, also z.B. chmod -R g+rwX /dev/dsp* /dev/snd /dev/mixer* Damit funkt's bei mir mit allen Anwendungen, die arts-Ausgabe beherrschen, sowie bei einigen Anwendungen, die man mit artsdsp -m ANWENDUNG -PARAMETER sozusagen anschieben kann, z.B. interessante Spiele, die auch unter Linux laufen :-) krecord und gramofile aber bspw. wollen's nun gar nicht mit aRts machen, bei Aufnahmen damit muss ich also doch wieder den artsd totschlagen ;-) -- Es gibt 10 Sorten von Menschen: Die, die binaer zaehlen koennen, und die anderen.