bonjour, bonsoir;
en fait voila: j'ai un terminal X (un pentium 200 avec 32 mo de ram) relié a mon ordinateur principal, et bon ca va ca marche bien sauf le son... en effet, quand je lance un programme type xmms depuis le terminal X, vu que tout s'execute sur le serveur X, ca sort sur la carte son du serveur... j'ai pensé a une solution, mais je suis pas sur que ca marche, donc j'aimerais demander votre avis, si vous avez une solution plus simple, au cas ou vous auriez deja eu le meme probleme.
je pensais lancer un petit serveur nfs sur le terminal X, monter sur la machine principale le /dev/ du terminal X en nfs genre dans /dev2 et apres, pour l'utilisateur qui se connecte depuis le terminal X changer les options de configuration de xmms et autres en indiquant que le peripherique de son se trouve sur /dev2/dsp
ca a des chances de marcher ca?
sinon un idée pour une autre solution?
Journal terminal x, son, et nfs
20
nov.
2003
# Re: terminal x, son, et nfs
Posté par Marc (site web personnel) . Évalué à 1.
# Re: terminal x, son, et nfs
Posté par M . Évalué à 3.
# Re: terminal x, son, et nfs
Posté par Bonnefille Guilhem (site web personnel) . Évalué à 3.
Il me semble que cette fonctionnalite a ete presentee dans un recent Linux Magazine France. Il s'agit de partager directement des bloc device. Dans l'exemple, on pouvait voir le lecteur de disquette du terminal depuis les applications tournant sur le serveur.
Par contre, en ecrivant ces ligne, je me rends compte de l'impossibilite : le /dev/dsp et un character device (et non un bloc device).
Desole.
[^] # Re: terminal x, son, et nfs
Posté par Nap . Évalué à 1.
# Re: terminal x, son, et nfs
Posté par Nÿco (site web personnel) . Évalué à 9.
Problème de notions terminal/serveur, espèce de Windowsiens va !
Ce que tu appelles terminal, c'est la bête en entier : écran + clavier + souris + unité centrale. En fait, il s'agit d'une bécane complète transformée en "terminal X" (installée+configurée pour cette tâche).
Un serveur est le logiciel qui sert les ressources aux clients : ici les ressources c'est l'affichage (XFree86 par exemple), les clients sont les logiciels qui ne demandent qu'à s'afficher (Mozilla, OpenOffice, toutes les applis KDE et GNOME, etc.).
Donc ton serveur X tourne sur ton terminal X, le pentium 200.
L'autre bécane qui héberge tes applis est... une autre bécane. Tu peux monter cette architecture ailleurs sans ce rapport de puissance machine, dans tous les sens : machine A héberge appli X + machine B l'affiche, machine B héberge appli Y + machine A et C l'affichent, etc.
Et oui, pas eu besoin d'attendre les PCAnywhere et *VNC pour déporter l'affichage sous *nix...
D'ailleurs, il existe des serveurs X sous Windows dont XFree86 porté par Cygwin : http://xfree86.cygwin.com/(...)
Petit conseil pour impressionner : faites tourner le serveur X en plein écran, barre des tâches masquée, et travaillez sous WindowMaker (un environnement qui tranche assez avec le look Windows...) et ne cachez pas votre écran... les badauds vont être légion, il ne reste qu'à les cueillir et leur expliquer Linux et les logiciels libres. ;-)
[^] # Re: terminal x, son, et nfs
Posté par Nÿco (site web personnel) . Évalué à 4.
Y'en a que je ne comprends pas... pourquoi moinsser ce post ? Il détaille techniquement une archi, et en profite pour donner des possibilités de monter GNU/Linux et d'intéresser les gens... c'est positif ça, et puis pertinent, et ça contribue positivement, non ?
[^] # Re: terminal x, son, et nfs
Posté par MrTout (site web personnel) . Évalué à 1.
L'explication qu'il donne n'est pas necessaire, Yhar Gla à déja un système qui fonctionne, il sait comment ça marche, il à juste un point de détail comme problème.
Et puis son conseil pour impressionner les gens est vraiment déplacé : d'une part je vais pas utiliser Window Maker uniquement dans le but d'impressionner les gens et d'autre part n'importe quelle gestionnaire de bureaux/fenetre esthetique peut impressionner tout autant si ce n'est plus.
Pour terminer l'explication du possible moinssage je dirais que les « Pas du tout efface », « espèce de Windowsiens va ! » et « Et oui, pas eu besoin d'attendre les PCAnywhere et *VNC pour déporter l'affichage sous *nix... » n'ont rien n'a faire là.
Sinon, l'architecture client / serveur dans le cas de terminaux X c'est :
Un serveur qui possède des trucs à distribuer : fichiers, applications, etc. C'est le serveur qui utilise ses ressources pour faire tourner les applications (ses processeurs, son matériel).
Un client qui affiche les programme qui tournent (les programmes qui tournent sur le serveur). Le clavier, souris et compagnie sont gérés par le client.
Pour réaliser ce genre de truc il faut donc d'une part que le client gère l'affichage et les claviers/souris : le client fait tourner un serveur X. Et d'autre part que le serveur fasse tourner les applications (donc clientes du serveur X).
Donc en fait si l'on parle du système en général ou de la technique en particulier, le sens client/serveur n'est pas le même.
# Re: terminal x, son, et nfs
Posté par GCN (site web personnel) . Évalué à 1.
http://www.redhat.com/support/wpapers/redhat/esd/advantages.html(...)
- ESD has the ability to do network transparent audio if desired.
- etc...
# Re: terminal x, son, et nfs
Posté par Anonyme . Évalué à 2.
[^] # Re: terminal x, son, et nfs
Posté par ploum (site web personnel, Mastodon) . Évalué à 2.
Mes livres CC By-SA : https://ploum.net/livres.html
# ARTS
Posté par wismerhill . Évalué à 2.
Donc tu démarre un artsd (avec les options qui vont bien, regarde artsd --help) et sur la machine où s'exécutent les programmes tu retouche un peu la config de arts pour lui dire de "suivre les paquets X" (je sais plus très bien comment on fait, mais tu peux trouver ça sur le site de KDE, ou peut-être le site des développeurs de KDE parmis la doc qui s'y trouve). Pour tous es programmes KDE pas de problème, xmms a un plugin arts et pour les autres tu peux utiliser artsdsp pour dévier le sn vers arts.
# Re: terminal x, son, et nfs
Posté par -=[ silmaril ]=- (site web personnel) . Évalué à 1.
en effet les fichiers de devices ne sont que des references logiques a des entrées dans le kernel, donc tu peut jouer un fichiers son sur une machine en utilisant un /remote/dev/dsp monté par NFS, il se jouera toujours sur ta machine pour autant que le fichier special /remote/dev/dsp est les bons numeros majeurs/mineurs.
Pour ton probleme tu a une seule solution: utiliser un serveur de son.
En plus de ESD/ARTS & co tu as une autre possibilite, d'autant plus que tu utilise
X11 c'est d'installer un serveur NAS sur ton terminal et les libraires clientes sur ton serveur, notamment la libaudiooss qui si elle est préloadé (LD_PRELOAD) permet une utilisation transparente du NAS sur toute application OSS.
L'avantage du système NAS: il utilise la configuration X11 pour déterminer l'adresse du serveur du son (et en plus c'est intégré aux terminaux type NCD :)).
J'ai installé ca sur un serveur linux pour NCD justement et ca marche tres bien,
bon la lib audiooss est moins efficace que les sorties NAS natives mais c'est toujours un bon point de depart.
# Re: terminal x, son, et nfs
Posté par Anonyme . Évalué à 1.
machine A : grosse machine ou tu fais tourner tout
machine B : la machine que tu utilises, et qui a un X qui tourne.
Tu tapes des trucs sur le clavier de la machine B, et ca lance
des programmes sur la machine A mais l'affichage
est aussi sur B, c'est ca ? (genre par un ssh
ou un telnet prealable).
Est-ce que tu ne pourrais pas tout simplement lancer xmms
directement sur la machine B ?
Est-ce que j'ai compris ta configuration ? :)
[^] # Re: terminal x, son, et nfs
Posté par -=[ silmaril ]=- (site web personnel) . Évalué à 1.
Ou plus simplement les terminaux X11.
En resumé c'est une machine qui ne fait qu'une seule chose: démarrer un serveur X11 en broadcast XDMCP (le top c'est les NCD et autre qui t'affiche une boite des machines ayant repondu au broadcast).
Ie tu n'est pas logué sur la machine B mais uniquement sur la machine A, la machine B ne sert qu'a envoyé les evenements souris/clavier et recevoir les affichages.
Tu pet teste cela chez toi avec une seule machine en utilisant Xnest (Xnest -broadcast :1) si ton serveur X11 n'est pas démarrer en -notcp ou -nolisten je sais pu
Donc (enfin ca depend de comment est configuré sa machine dans son cas) il ne peut pas lancé xmms sur 'B' vu que (en theorie tjrs :)) il n'y a sur B que le serveur X, sa config et un eventuel serveur audio, peut etre un sshd pour l'administrer mais ca devrait etre tout.
Un vrai terminal X n'a meme pas de disque :)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.