C'est pas juste un problème de droit d'accès aux périphériques de gravure ? Sous Sid j'ai eu un problème similaire il y a quelques semaines, il a suffit d'ajouter l'utilisateur dans le groupe cdrom.
Est-ce une raison pour interdire un nouvel entrant potentiel ?
Rien n'empêche l'arrivée de nouveaux entrants, il leur suffit d'implémenter la norme OpenGL et de respecter ses spécifications. S'ils le désirent, ils peuvent même proposer de nouvelles extensions qui pourront être ensuite normalisées par l'ARB.
Par ce raisonnement on peut dire aussi pourquoi faire Firefox, IE est suffisant, tous les sites sont compatibles, pas besoin de norme d'interoperabilité...
La norme d'interopérabilité, c'est le standard OpenGL, disponible ici : http://www.opengl.org/documentation/specs/
Après chacun est libre de créer ses propres extensions pour exploiter au mieux son matériel.
L'inconvénient par rapport à Direct3D, c'est que pour profiter au maximum de toutes les possibilités d'une carte, il faut écrire du code spécifique pour les extensions qu'on veut supporter.
L'avantage, c'est que les applications comme les jeux peuvent tirer parti de toute la puissance des cartes (UltraShadows de nvidia par exemple) sans faire de nivellement par le bas sur les fonctionnalités.
Ça encourage l'innovation chez les constructeurs et ça évite qu'une seule entité ne dicte la norme.
Donc programmation pour chaque fabriquant, donc si t'es pas dans le duo de tete, t'es un fabriquant mort car personne ne va etre compatible avec ton jeu.
Super idée.
La méthode utilisée par Microsoft n'est pas meilleure pour les nouveaux entrants et n'encourage pas vraiment à l'innovation chez les constructeurs :
« Direct3D is specified by one vendor (Microsoft) only, leading to a more consistent API, but denying access to vendor-specific features. nVidia's UltraShadow[1] technology, for instance, is not available in the stock Direct3D APIs at the time of writing. »
Autres morceaux choisis :
Fonctionnalités
Outside of a few minor functional differences, typically with regard to rendering to textures (the "framebuffer objects" extension did not cover everything, but the ARB is working to address this), the two APIs provide nearly the same level of functionality.
Performance
Direct3D 9 and below have a particular disadvantage with regard to performance. Drawing a vertex array in Direct3D requires that the CPU switch to kernel-mode and call the graphics driver immediately.
Outside of this, Direct3D and OpenGL applications have no significant performance differences.
Facilité d'utilisation
At this point, the Windows Vista issue aside, the reason for using one over the other is typically inertia. It is what they have used in the past, so it is what they use now.
j'ai entendu quelqu'un récement me dire que OpenGL c'était pourri et que ça ralentissait les jeux...
C'est sûr que ça fait un peu mal au coeur d'entendre des bêtises pareilles, mais en même temps n'importe quelle personne un tant soit peu concernée par les jeux vidéo sait que c'est une remarque complètement stupide.
Faire une interface de gestion de jeux simple qui permette par exemple de sélectionner un jeu dans une liste (un peu comme Cedega, mais en natif).
C'est surtout qu'OpenGL a quelques années de retard, et en jeux ca ne pardonne pas.
Hem, tu as déjà vu tourner Doom III ou Prey ? Tu as de quoi argumenter sur le retard d'OpenGL par rapport à Direct3D ?
sauf que maintenant c'est Shaders 3, qu'OpenGL ne gere pas.
Ce sont des appelations Microsoft, un peu logique qu'elles ne soient pas supportées par OpenGL. Tu peux dire quelles fonctionnalités présentes dans SM3 ne sont pas disponibles dans OpenGL ?
Encore moins les Shaders 4...
Qui sortiront en même temps que Vista et qu'aucune carte ne supporte actuellement...
Et les equivalent des des autres composants de DirectX, ben c'est plus dur de trouver... Certes, il y a SDL, mais c'est pas le meme niveau.
Par contre j'ai commenté les lignes suivantes dans mon /etc/X11/xorg.conf :
Essaye aussi de commenter ça pour voir, ça n'est pas présent dans mon xorg.conf sur une Geforce 6200 :
- BusID "PCI:1:0:0"
- Option "NvAgp" "1"
- Load "evdev"
Cependant, n'y a-t-il pas une méthode "plus propre" pour empêcher le système de charger le module agpgart ???
Normalement ça peut se faire via modconf (dans kernel/drivers/char/agp), mais ça ne fonctionnait pas pour nvidiafb chez moi. Ça marchera peut-être pour agpgart chez toi...
Ok, c'était juste pour vérifier que le problème ne venait pas de agpgart. Quand tu reviens à ta configuration initiale (sans support de l'AGP donc), est-ce que tes applications sont toujours lentes ? Si oui, ce n'est pas un problème d'AGP, Quake 3 devrait tourner correctement avec une Geforce 5200 sans support AGP.
Tu peux vérifier si l'accélération matérielle est bien prise en compte en faisant un glxinfo | grep direct, ça devrait afficher : direct rendering: Yes
Sinon, une solution bourrine temporaire consiste à renommer ton agpgart.ko (dans /lib/modules/2.6.16-2-k7) pour qu'il ne soit pas chargé au redémarrage suivant. Ça devrait peut-être permettre à X d'utiliser le driver AGP Nvidia. C'est ce que je faisais sous Sid quand il y avait un problème de chargement automatique de nvidiafb par le noyau.
C'est clair que l'utilisation de l'Ogg Vorbis est anecdotique comparée à celle du MP3 pour les balladeurs, mais il y a quand même quelques lecteurs supportés : http://wiki.xiph.org/index.php/VorbisHardware
Dans le secteur des jeux vidéos ça ma paraît pas mal utilisé par contre, et pas par les moins rentables (Unreal, Doom 3, Far Cry, GTA San Andreas, Splinter Cell, Halo, etc.) : http://wiki.xiph.org/index.php/Games_that_use_Vorbis
attend que les brevets sur le logiciel soient en vigueur, et tu verras si l'Ogg tient encore la route sur ce point.
Ils sont en vigueur aux Etats-Unis, comme pour le MP3, et on ne voit toujours rien venir...
Rien ne garanti que qu'aucune société ne viendra avec des brevets couvrant des méthodes utilisées dans le format ogg.
Rien ne le garantit, mais le Ogg Vorbis existe depuis pas mal de temps maintenant, est très connu et très utilisé. Si ça avait du arriver, je pense qu'on en aurait déjà entendu parler.
Windows (XP je crois) a "inventé" Cleartype : utilisation des sous-pixels (rouge/vert/bleu) sur les écrans LCD.
Cette technique existe depuis environ 30 ans (1976), elle était déjà utilisée sur les Apple II. Voir : http://www.grc.com/ctwho.htm
Communiqué de presse de Microsoft lors de la sortie de ClearType en 1998 :
« Tonight at COMDEX/Fall '98, Bill Gates, chairman and CEO of Microsoft Corp., unveiled an unprecedented innovation in font display technology during his keynote address. The software, called Microsoft® ClearType™ font technology, dramatically improves font display resolution and marks a genuine breakthrough in screen readability. »
Quote de Steve Wozniak (le créateur de l'Apple II, pour les plus jeunes ;) :
« So more than twenty years ago, Apple II graphics programmers were using this 'sub-pixel' technology to effectively increase the horizontal resolution of their Apple II displays. »
tiens, si quelqu'un peut m'expliquer pourquoi ces foutus FS sous linux sont case sensitive ?
Sans doute pour des raisons historiques de compatibilité avec Unix (tout comme pour NTFS sous MS Windows et HFSX sous Mac OS X) et parce que quand Unix a été créé, c'était plus simple de faire comme ça.
Je ne sais pas si le site de la BBC est bloqué...mais moi je peux lire le site de la BBC, et si besoin est je peux retransmettre les news à des gens en chine...et ceci en utilisant mon blog, une messagerie, le téléphone, des mails, la voip, le courrier classique, les réseaux p2p...
Je repose la question...quel "gigantesque parefeu"
Effectivement, tu peux retransmettre des informations, mais tu ne peux le faire qu'à ton échelle et ça ne couvre pas tous les besoins. Par exemple, certains programmeurs chinois ne peuvent plus accéder à SourceForge depuis février dernier, tu vas t'occuper de faire des commits et des checkouts sur CVS pour eux ?
Ce qui m'a plu ce sont les polices utilisées pour les titres et le texte ainsi que leur taille, la couleur des titres, l'interligne, les marges et le respect des césures. La forme générale du document aide aussi à rendre la lecture plaisante, avec un format classique et prédictible : page de garde, page des auteurs, table des matières, numérotation 1.2.3. des titres avec police variable, etc.
C'est un document de conception très simple qui n'a rien de particulièrement remarquable, mais tous les petits détails que je citais font que j'ai eu du plaisir à le lire. Par contre, il est par ailleurs bourré de défauts (qualité des illustrations, fautes d'orthographes et lourdeurs d'expression), mais le sentiment global reste très positif.
Ceci dit, les tailles de caractères, marges et interligne utilisés ne seraient peut être pas appropriés pour un document plus long comme une thèse ou un mémoire.
Raydium: (my)glut: WARNING: This is an *INDIRECT* rendering context.
Raydium: Found 1280x1024 with 16 bpp color and 16 bits zbuffer (stencil is 1)
Raydium: using Mesa GLX Indirect, from Mesa project: www.mesa3d.org (version 1.2 (1.5 Mesa 6.4.1))
Visiblement l'application n'utilise pas l'accélération matérielle, c'est peut-être lié à un problème d'installation du pilote nvidia. Que te dit « glxinfo | grep direct » ?
Blocage possible de l'accès au lecteur de cédéroms par le pilote SATA lors des installations à partir des cédéroms.
Sur les systèmes disposant d'un contrôleur IDE SATA sur lequel est également connecté le lecteur de cédéroms, l'installateur peut se geler pendant la détection du matériel de lecture des cédéroms ou échouer à lire le cédérom juste après cela. Une des raisons possibles est que le pilote SATA (ata_piix et peut-être d'autres) bloque l'accès au lecteur de cédéroms.
Vous pouvez essayer de contourner ce problème en lançant l'installateur en mode expert et, lors de l'étape « Détection et montage du cédérom », en ne sélectionnant que les pilotes nécessaires à la gestion des cédéroms. Il s'agit de (ide-)generic, ide-cd et isofs.
Les pilotes nécessaires pour accéder au disque seront toujours chargés, mais à une étape ultérieure. En chargeant de cette façon les pilotes de lecteur de cédéroms avant le pilote SATA, vous pourrez normalement terminer l'installation. Veuillez noter que l'accès au cédérom peut rester un problème après avoir redémarré sur le système installé.
Il y a une page sur le Wiki Debian à propos des problèmes rencontrés lors du passage à Xorg 7.0 sur unstable : http://wiki.debian.org/Xorg69To7
Mais comme je te l'ai dit il y a deux semaines (http://linuxfr.org/comments/701906.html#701933 ) et à moins que ça ne t'amuses de jongler avec les problèmes récurrents de unstable, tu devrais peut être essayer de passer en testing. Parce qu'à ce train là, tu vas demander de l'aide tous les quinze jours...
Doom 3 et Glest supportent Alsa, je pense que le problème vient d'ailleurs. Si tu veux simuler la présence d'une carte son, tu peux essayer de charger le module snd-dummy. Si tu as un serveur de son lancé, tu peux aussi essayer de le désactiver, via l'interface ou en faisant un killall artsd ou killall esd.
En général on emploie le terme upstream dans le cadre de la création de paquets pour des distributions. Ça désigne le code d'une application géré par ses développeurs par opposition au code géré par les mainteneurs du paquet. On pourrait traduire upstream par « amont ».
Je ne pense pas que ce lien s'adresse à des débutants. Si tu as déjà du mal à passer ton install en français, je pense que tu vas au devant de grosses désillusions avec unstable. Il y a régulièrement des problèmes qui sont beaucoup moins triviaux à régler.
Esd est l'équivalent de artsd sous KDE, un serveur de son pour Gnome. Pour le désactiver, il faut aller dans Bureau | Préférences | Son et décocher Activer le serveur de son au démarrage.
Je ne sais pas comment on désactive arts via KDE, en cherchant un peu tu devrais trouver. Sinon, tu peux toujours faire un killall artsd dans un terminal en tant que root.
[^] # Re: Debian testing ?
Posté par Frédéric Lopez . En réponse au message Problème de gravure. Évalué à 1.
Sinon, tu peux peut-être investir dans un kit de refroidissement en attendant l'hiver :)
[^] # Re: Debian testing ?
Posté par Frédéric Lopez . En réponse au message Problème de gravure. Évalué à 1.
[^] # Re: heu, c'est les vacances là ...
Posté par Frédéric Lopez . En réponse à la dépêche Agir contre la vente liée. Évalué à -1.
Rien n'empêche l'arrivée de nouveaux entrants, il leur suffit d'implémenter la norme OpenGL et de respecter ses spécifications. S'ils le désirent, ils peuvent même proposer de nouvelles extensions qui pourront être ensuite normalisées par l'ARB.
La norme d'interopérabilité, c'est le standard OpenGL, disponible ici : http://www.opengl.org/documentation/specs/
Après chacun est libre de créer ses propres extensions pour exploiter au mieux son matériel.
L'inconvénient par rapport à Direct3D, c'est que pour profiter au maximum de toutes les possibilités d'une carte, il faut écrire du code spécifique pour les extensions qu'on veut supporter.
L'avantage, c'est que les applications comme les jeux peuvent tirer parti de toute la puissance des cartes (UltraShadows de nvidia par exemple) sans faire de nivellement par le bas sur les fonctionnalités.
Ça encourage l'innovation chez les constructeurs et ça évite qu'une seule entité ne dicte la norme.
[^] # Re: heu, c'est les vacances là ...
Posté par Frédéric Lopez . En réponse à la dépêche Agir contre la vente liée. Évalué à 2.
La méthode utilisée par Microsoft n'est pas meilleure pour les nouveaux entrants et n'encourage pas vraiment à l'innovation chez les constructeurs :
« Direct3D is specified by one vendor (Microsoft) only, leading to a more consistent API, but denying access to vendor-specific features. nVidia's UltraShadow[1] technology, for instance, is not available in the stock Direct3D APIs at the time of writing. »
Autres morceaux choisis :
Fonctionnalités
Outside of a few minor functional differences, typically with regard to rendering to textures (the "framebuffer objects" extension did not cover everything, but the ARB is working to address this), the two APIs provide nearly the same level of functionality.
Performance
Direct3D 9 and below have a particular disadvantage with regard to performance. Drawing a vertex array in Direct3D requires that the CPU switch to kernel-mode and call the graphics driver immediately.
Outside of this, Direct3D and OpenGL applications have no significant performance differences.
Facilité d'utilisation
At this point, the Windows Vista issue aside, the reason for using one over the other is typically inertia. It is what they have used in the past, so it is what they use now.
Source : http://en.wikipedia.org/wiki/Direct3D_vs._OpenGL
[^] # Re: heu, c'est les vacances là ...
Posté par Frédéric Lopez . En réponse à la dépêche Agir contre la vente liée. Évalué à 1.
C'est sûr que ça fait un peu mal au coeur d'entendre des bêtises pareilles, mais en même temps n'importe quelle personne un tant soit peu concernée par les jeux vidéo sait que c'est une remarque complètement stupide.
Ça existe déjà :
http://liflg.org/
http://icculus.org/loki_setup/
http://gfsgl.sourceforge.net/
[^] # Re: heu, c'est les vacances là ...
Posté par Frédéric Lopez . En réponse à la dépêche Agir contre la vente liée. Évalué à 2.
Hem, tu as déjà vu tourner Doom III ou Prey ? Tu as de quoi argumenter sur le retard d'OpenGL par rapport à Direct3D ?
Ce sont des appelations Microsoft, un peu logique qu'elles ne soient pas supportées par OpenGL. Tu peux dire quelles fonctionnalités présentes dans SM3 ne sont pas disponibles dans OpenGL ?
Qui sortiront en même temps que Vista et qu'aucune carte ne supporte actuellement...
DirectInput : OIS, libgii, SDL
DirectPlay : Raknet, OpenTNL, HawkNL
DirectSound : OpenAL, FMOD, Audiere
[^] # Re: Complément d'infos...
Posté par Frédéric Lopez . En réponse au message Drivers NVidia et conflit avec le module agpgart. Évalué à 1.
Essaye aussi de commenter ça pour voir, ça n'est pas présent dans mon xorg.conf sur une Geforce 6200 :
- BusID "PCI:1:0:0"
- Option "NvAgp" "1"
- Load "evdev"
Normalement ça peut se faire via modconf (dans kernel/drivers/char/agp), mais ça ne fonctionnait pas pour nvidiafb chez moi. Ça marchera peut-être pour agpgart chez toi...
[^] # Re: Complément d'infos...
Posté par Frédéric Lopez . En réponse au message Drivers NVidia et conflit avec le module agpgart. Évalué à 2.
Tu peux vérifier si l'accélération matérielle est bien prise en compte en faisant un glxinfo | grep direct, ça devrait afficher : direct rendering: Yes
Sinon, une solution bourrine temporaire consiste à renommer ton agpgart.ko (dans /lib/modules/2.6.16-2-k7) pour qu'il ne soit pas chargé au redémarrage suivant. Ça devrait peut-être permettre à X d'utiliser le driver AGP Nvidia. C'est ce que je faisais sous Sid quand il y avait un problème de chargement automatique de nvidiafb par le noyau.
[^] # Re: Complément d'infos...
Posté par Frédéric Lopez . En réponse au message Drivers NVidia et conflit avec le module agpgart. Évalué à 2.
[^] # Re: l'ogg, je suis à fond pour mais...
Posté par Frédéric Lopez . En réponse à la dépêche Radio France arrêterait-elle le Ogg Vorbis ?. Évalué à 1.
http://wiki.xiph.org/index.php/VorbisHardware
Dans le secteur des jeux vidéos ça ma paraît pas mal utilisé par contre, et pas par les moins rentables (Unreal, Doom 3, Far Cry, GTA San Andreas, Splinter Cell, Halo, etc.) :
http://wiki.xiph.org/index.php/Games_that_use_Vorbis
[^] # Re: l'ogg, je suis à fond pour mais...
Posté par Frédéric Lopez . En réponse à la dépêche Radio France arrêterait-elle le Ogg Vorbis ?. Évalué à 0.
Ils sont en vigueur aux Etats-Unis, comme pour le MP3, et on ne voit toujours rien venir...
Rien ne le garantit, mais le Ogg Vorbis existe depuis pas mal de temps maintenant, est très connu et très utilisé. Si ça avait du arriver, je pense qu'on en aurait déjà entendu parler.
D'ailleurs, déjà, ici même en 2000 (6 ans déjà...) : http://linuxfr.org/2000/12/12/1435.html
[^] # Re: Détails sur les polices de caractère vectorielles
Posté par Frédéric Lopez . En réponse à la dépêche Fedora lance une campagne de test de la police DejaVu. Évalué à 7.
Cette technique existe depuis environ 30 ans (1976), elle était déjà utilisée sur les Apple II. Voir : http://www.grc.com/ctwho.htm
Communiqué de presse de Microsoft lors de la sortie de ClearType en 1998 :
« Tonight at COMDEX/Fall '98, Bill Gates, chairman and CEO of Microsoft Corp., unveiled an unprecedented innovation in font display technology during his keynote address. The software, called Microsoft® ClearType™ font technology, dramatically improves font display resolution and marks a genuine breakthrough in screen readability. »
Quote de Steve Wozniak (le créateur de l'Apple II, pour les plus jeunes ;) :
« So more than twenty years ago, Apple II graphics programmers were using this 'sub-pixel' technology to effectively increase the horizontal resolution of their Apple II displays. »
[^] # Re: Plop
Posté par Frédéric Lopez . En réponse à la dépêche Une licence plus permissive pour Java. Évalué à 3.
Sans doute pour des raisons historiques de compatibilité avec Unix (tout comme pour NTFS sous MS Windows et HFSX sous Mac OS X) et parce que quand Unix a été créé, c'était plus simple de faire comme ça.
[^] # Re: Liberté sous contrôle…
Posté par Frédéric Lopez . En réponse à la dépêche Quand la liberté viendra de Chine.... Évalué à 5.
Effectivement, tu peux retransmettre des informations, mais tu ne peux le faire qu'à ton échelle et ça ne couvre pas tous les besoins. Par exemple, certains programmeurs chinois ne peuvent plus accéder à SourceForge depuis février dernier, tu vas t'occuper de faire des commits et des checkouts sur CVS pour eux ?
http://en.wikipedia.org/wiki/Sourceforge#Banned_in_mainland_(...)
# Courier CPS : survol fonctionnel
Posté par Frédéric Lopez . En réponse au message Quels documents trouvez-vous agréables à lire. Évalué à 1.
http://www.adullact.org/IMG/pdf/doc-212.pdf
Ce qui m'a plu ce sont les polices utilisées pour les titres et le texte ainsi que leur taille, la couleur des titres, l'interligne, les marges et le respect des césures. La forme générale du document aide aussi à rendre la lecture plaisante, avec un format classique et prédictible : page de garde, page des auteurs, table des matières, numérotation 1.2.3. des titres avec police variable, etc.
C'est un document de conception très simple qui n'a rien de particulièrement remarquable, mais tous les petits détails que je citais font que j'ai eu du plaisir à le lire. Par contre, il est par ailleurs bourré de défauts (qualité des illustrations, fautes d'orthographes et lourdeurs d'expression), mais le sentiment global reste très positif.
Ceci dit, les tailles de caractères, marges et interligne utilisés ne seraient peut être pas appropriés pour un document plus long comme une thèse ou un mémoire.
[^] # Re: encore un bug ?
Posté par Frédéric Lopez . En réponse à la dépêche Première version publique de ManiaDrive (1.01). Évalué à 3.
Forum : http://memak.raydium.org/
Wiki : http://wiki.raydium.org/wiki/ManiaDrive
[^] # Re: configuration
Posté par Frédéric Lopez . En réponse à la dépêche Première version publique de ManiaDrive (1.01). Évalué à 3.
Visiblement l'application n'utilise pas l'accélération matérielle, c'est peut-être lié à un problème d'installation du pilote nvidia. Que te dit « glxinfo | grep direct » ?
# Avec GCC
Posté par Frédéric Lopez . En réponse au message Comment rattacher les lib OpenGl à l'éditeur de lien? pbm de "Linkage". Évalué à 2.
devient
-L/usr/X11R6/lib -lGL -lGLU -lX11 -lXext -lXi -lXmu
Rajouter -lglut si tu utilises Glut.
# Une piste...
Posté par Frédéric Lopez . En réponse au message Probeme d'installation de debian sur SATA. Évalué à 4.
Blocage possible de l'accès au lecteur de cédéroms par le pilote SATA lors des installations à partir des cédéroms.
Sur les systèmes disposant d'un contrôleur IDE SATA sur lequel est également connecté le lecteur de cédéroms, l'installateur peut se geler pendant la détection du matériel de lecture des cédéroms ou échouer à lire le cédérom juste après cela. Une des raisons possibles est que le pilote SATA (ata_piix et peut-être d'autres) bloque l'accès au lecteur de cédéroms.
Vous pouvez essayer de contourner ce problème en lançant l'installateur en mode expert et, lors de l'étape « Détection et montage du cédérom », en ne sélectionnant que les pilotes nécessaires à la gestion des cédéroms. Il s'agit de (ide-)generic, ide-cd et isofs.
Les pilotes nécessaires pour accéder au disque seront toujours chargés, mais à une étape ultérieure. En chargeant de cette façon les pilotes de lecteur de cédéroms avant le pilote SATA, vous pourrez normalement terminer l'installation. Veuillez noter que l'accès au cédérom peut rester un problème après avoir redémarré sur le système installé.
[^] # Re: Un homme averti...
Posté par Frédéric Lopez . En réponse au message plantage de xorg a l'install. Évalué à 2.
http://packages.debian.org/cgi-bin/search_packages.pl?search(...)
Notamment à cause du bug que tu mentionnes :
http://packages.qa.debian.org/x/xorg.html
# Un homme averti...
Posté par Frédéric Lopez . En réponse au message plantage de xorg a l'install. Évalué à 2.
http://wiki.debian.org/Xorg69To7
Mais comme je te l'ai dit il y a deux semaines (http://linuxfr.org/comments/701906.html#701933 ) et à moins que ça ne t'amuses de jongler avec les problèmes récurrents de unstable, tu devrais peut être essayer de passer en testing. Parce qu'à ce train là, tu vas demander de l'aide tous les quinze jours...
# Alsa ?
Posté par Frédéric Lopez . En réponse au message /dev//dsp et alsa .... Évalué à 2.
# Upstream
Posté par Frédéric Lopez . En réponse au message Hierarchie au sein des développeurs?. Évalué à 3.
[^] # Re: Locales
Posté par Frédéric Lopez . En réponse au message deian unstable en francais. Évalué à 2.
[^] # Re: Full duplex
Posté par Frédéric Lopez . En réponse au message Probleme ALSA Fullduplex. Évalué à 2.
Je ne sais pas comment on désactive arts via KDE, en cherchant un peu tu devrais trouver. Sinon, tu peux toujours faire un killall artsd dans un terminal en tant que root.