FluffyHamster a écrit 252 commentaires

PulseAudio a été conçu dans l'optique d'une utilisation sur un ordinateur de bureau.

J'entendais par la "utilisation bureautique", sur PC fixe ou portable, opposé à une utilisation professionnelle et les besoins spécifiques qui vont avec.

PA est très efficace niveau gestion énergétique, notamment grâce à cela :
http://0pointer.de/blog/projects/pulse-glitch-free.html

De plus, il à été porté sur Android et mis en compétition avec son système AudioFlinger, et les résultats préliminaires sont très encourageant (meilleur perf, latence et économie d'énergie), montrant encore une fois si c'étais nécessaire que oui, PA fonctionne en embarqué (il équipe également les N900).
http://arunraghavan.net/2012/01/pulseaudio-vs-audioflinger-fight/

Oui il y a eu du travail de fait sur le système de timing pour la lecture par bluetooth, et il devrait encore y en avoir dans les prochaines versions.

Effectivement, si intérêt il y a eu un jour de faire le mixage audio en hardware, il à complètement disparu aujourd'hui. Faire ça sur le CPU ne coûte rien (mais alors rien du tout) et c'est infiniment plus flexible (et ça ne t'oblige pas à re-coder l'accélération pour chaque carte audio)…

Et quand on aura 16 cores, lennart demandera à virer l'accélération gpu ?

Non, car pour égaler une carte graphique d'aujourd'hui il ne faut pas 16 coeurs mais plutôt 4096. La question ne se pose donc pas. Néanmoins tu évoque le sujet, poursuivons avec le cas du décodage vidéo en hardware.
Avec un i7 2600K, décoder du 1080p à gros bitrate prend moins de 10% d'un seul coeur. Partant de la, mais pourquoi se faire chier à faire fonctionner toute une carte graphique (+250W dans mon cas) à coté du CPU (déjà 100W) pour faire son petit décodage vidéo en hardware ? C'est le même type de problématique que le mixage audio hardware. "Hier" c'étais quasiment obligatoire, "demain" se sera complètement inutile. Ce n'est pas une question de "design" (bien au contraire, déléguer des tâches à du hardware spécifique relève plus du gros hack qu'autre chose), c'est une question de moyens qui évoluent, et de besoins qui restent les mêmes.

Même si le wifi n'a pas été conçu pour fonctionner à longue porté, il peut le faire en terrain découvert. Le record du monde est quand même de 382km, avec de simples WRT54 et des (ok, grosses) antennes.

Merci bien ! J'ai loupé la fonction d'édition ou c'est réservé aux admins ?

C'est pas faux. Je sais pas écrire, désolé.

Ils parlent bien des hommes et des femmes qui, à la moindre question sensible ne te répondent pas ? Ou c'est à ceux qui te renvoient systématiquement vers le service client téléphonique ? Ou alors c'est les hommes et femmes à qui ont doit envoyer des courriers recommandés pour un pauvre changement d'options, un désabonnement, ou toutes autres opérations qui ne les arranges pas ??

Franchement, leurs boutiques, je n'ai pas les mots pour décrire ça... C'est plus que du foutage de gueule, elles ne servent qu'à emballer les mamies.

Un jour, un commercial m'a proposé de prendre un forfait plus cher "pendant un mois", pour économiser sur le prix d'un téléphone. J'ai accepté (j'étais jeune et insouciant). Résultat ? J'ai payé 3 mois de forfait beaucoup plus cher (car finalement, holala surprise ! on ne pouvait pas rechanger de forfait), tous ça pour... Quand même payer le téléphone au tarif max. Plus moyen d'annuler ("Ha non monsieur, vous êtes engagé maintenant"). Mais le vendeur c'est quand même excusé de son erreur qu'il ne pouvait pas rectifier ("J'ai pas accès à ces opérations, faut que j'appel ma chef").

J'en ai d'autres des exemples comme ça. On en à tous d’ailleurs... Ces gens la pratiquent l'escroquerie organisée... Qu'ils viennent se plaindre maintenant...

J'ai trouvé plus d'info ici : http://source.android.com/tech/encryption/android_crypto_implementation.html

Donc cette option est accessible depuis android 3.0 et non 4.0, c'est basé sur le sous système dm-crypt du noyau (chiffrement "128 AES with CBC and ESSIV:SHA256"). Ça ne chiffre apparemment que la partition /data du mobile (le seul endroit ou des données peuvent être inscrites par l'utilisateur (outre la / les cartes mémoires bien entendu).

Il semble donc possible d'envisager le chiffrement de la carte mémoire sur une ROM de type cyanogenmod (ce serai une fonction sympa). Il y avait déjà une modification (bien antérieur à android 3) qui utilisait dm-crypt et luks pour le chiffrement du mobile.

Néanmoins ça tue un peu le concept de carte mémoire "amovible". A méditer...

Oui sur android 4.0 (par "défaut" donc, dans "sécurité" > "chiffrer le téléphone") il y a aussi une option pour chiffrer le stockage interne, avec déverrouillage à l'allumage par mot de passe.

Oui je trouvais aussi, mais bonne surprise lors de l'achat on peut même régler le pourcentage à donner entre chacune des deux associations caritatives !

Oui alors un peu passé seulement comme tu dis ^^

Il est maintenant possible de faire des calculs logiques sur des cartes dernières génération (avant pas possible), au prix de 25% d'utilisation d'une unité seulement, même 20% sur les ATI VLIW.
Il est possible par contre (la encore, sa doit vachement dépendre du modèle/marque de carte) de faire simultanément un calcul sur un entier 32bits et un calcul sur un vecteur de 3 flottants pour garder une utilisation maximale de l'unité (si les deux opérations ne sont pas interdépendantes bien sur, ce qui doit souvent être le cas quand on travail pas en 100% vectoriel).
Mais je ne sais pas si c'est le programmeur, le compilateur glsl/cuda/open cl > langage machine ou directement le matériel (probablement pas le matériel d’ailleurs) qui se charge de garder son pipeline bien remplit.

Il me semble qu'il n'y a pas que le cache des textures.

Effectivement, pas de cache de textures en tant que tel.

Je ne vois pas vraiment quel fonctionnalités d'un cache sur un CPU ne pourrait pas être dupliquée sur un cache mis dans un GPU, tu pense à quoi?

(Si je ne dis pas de bêtises, la il faudrait un expert) Certains GPU utilisent en plus de leur nombres hallucinant de registres de petits caches (~64kio), équivalent à ceux des L1 sur CPU, mais partagés entre "cluster" d'unités de shaders, et une sorte de cache L2 partagé entre ces clusters (pas directement avec les unités qui les composent). Ils peuvent êtres utilisés pour mettre des textures (au sens plage mémoire) en cache.

Et tous ça reste super dépendant du modèle de GPU que l'on prends comme exemple.

Après par exemple un "gros" cache L3 partagé entre tous les coeurs / thread (de 1 à 8 on va dire) d'un CPU n'aura pas sa place dans un GPU, car cela voudrai dire le partager entre 40 et 500 unités de shaders. Dur dur niveau cohérence on en reviens la. Mettre des caches par unités de shader n'est pas possible non plus, ça prendrait une place monstrueuse sur des puces déjà monstrueuses...

Mais je suis d'accord l'exemple est un peu spécial (bus partagé) et les shaders deviennent de plus en plus des cpu, il ne restera plus que la quasi-absence de cohérence mémoire.

Une différence qui semble perdurer c'est quand même que les shaders sont mauvais sur tous ce qui n'est pas du calcul vectoriel. Ou alors qu'on aura du mal a avoir des gains si on les utilisent pour faire du logique ou de l'entier. Partant de la, peut on les considérer comme se rapprochant des CPU ?

LLVMPIPE qui fournit un driver 3D purement logiciel, est surtout prévu pour tester et débugger des applis 3D ou des fonctionnalités de Mesa, car il contient des fonctionnalités intéressantes à ce niveau la.

Effectivement ça peut fournir l'accélération 3D suffisante pour Compiz par exemple si ont à une carte graphique sans driver matériel disponible.

Comme on peut le voir sur le benchmark de phoronix, 30fps sur open arena, on est quand même vachement loin d'un truc utilisable "in-game". Surtout qu'open arena utilise presque uniquement la rasterization et pas de shaders (ou très peu ?). Même si ils sont supportés par llvmpipe ils n'ont aucune chance d'être compétitif avec une carte graphique me très bas de gamme. Et les shaders c'est quand même le coeur d'une carte graphique actuelle...

Oui tout à fait, tous les logiciels pouvant utiliser l'api vdpau sont compatibles. Et cela inclus VLC et tous les autres logiciels basés sur ffmpeg/libav.

Alors dans l'ordre :

• C'est nouveau pour les drivers libres oui.
• C'est pour l'instant surtout réservé à certaines cartes graphiques qui utilisent les drivers Gallium3D r300 et r600. Cela demande le support de certaines instructions qui ne sont pas encore implémentées dans tous les drivers graphiques. Patience.
• A terme, ce sera pour à peu près toutes les ATI et NVIDIA suffisamment récentes.
• Pour l'instant c'est pour les vidéos encodées en mpeg 1 et 2. Donc pour les DVD mais aussi les Blu-ray qui sont encodés en mpeg 2 (ça existe oui).

Niveau consommation éléctrique ce n'est pas forcement rentable en effet.
Les puces dédiées au décodage vidéo qui sont sur les cartes graphiques, les drivers libres n'y ont pas accès, donc c'est réglé.

L’intérêt de la chose c'est en effet les petites configs (qui ont quand même des cartes graphiques avec suffisamment d'unités de shaders) ou alors pour les très grosses vidéos, car oui, c'est parfaitement possible de saturer son core i7 avec une bonne grosse vidéo.

J'ai eu le même problème avec syslog-ng, j'étais passé aussi à rsyslog mais maintenant ça semble réglé.

En fait, c’est arch-daemons.target qui fait ça.

Oui j'ai ressortis ça de mémoire, sinon effectivement la page Arch wiki de systemd permet de trouver toute les informations nécessaires pour effectuer des réglages plus fin ou régler les petits problèmes.

Sinon au boot de suis passé d'une quinzaine de secondes à quasi 0, j'ai à peine le temps de voir l'écran noir avec le montage des disques que le bureau s'affiche. systemd + un ssd, cavatrèsvite :-)

perso j'ai fais :
- pacman -S systemd systemd-arch-units (le deuxième lit le script rc.conf pour démarrer les services que tu veux)
- passer un paramètre au noyau lors du boot dans grub (init=/bin/systemd)

Et paf, j'ai gagné 10 secondes lors du boot. Tu peux même garder l'init normal si tu laisse une autre entrée grub sans le paramètre.
Systemd c'est juste du bon boulot...

Alsa et PulseAudio ne font pas la même chose. Alsa parle au matériel, en général lui envoie du son PCM sur un canal. Dmix, qui est un mixeur, est livré avec Asla en tant que plugin, sert à mixer plusieurs canaux ensembles, pour avoir du son de plusieurs sources en même temps, mais c'est tout, pas plus de fonctionnalités. Et encore une fois, pas du tout basé sur le même principe de fonctionnement pour mixer le son et contrôler les délais.
Donc voila la réponse, PulseAudio ne réécrit pas des bouts d'Alsa mais prend la place du mixeur en y ajoutant beaucoup de fonctionnalités, largement documenté ailleurs.

De plus avec tous les bugs qu'ils ont soulevés, les gens de PulseAudio sont à l'origine de beaucoup de travail sur le coeur de Alsa.

Effectivement c'est très malhonnête ce qu'il dit, il se défend catégoriquement de donner des noms, mais réponds que de la même manière « tous les opérateurs doivent fournir des adresses hypés à l'HADOPI ».
Ben non, c'est l'inverse mon ptit pote, c'est toi qui balance tes clients dans l'histoire...

echo "flat-volumes = no" >> /etc/pulse/daemon.conf

Comme ca les applis régleront leur volume maximum en fonction du volume "maître" (ex: vlc démarre à 100% des 60% du volume maître), et ne pourront plus prendre le pas sur le volume maître (et donc toujours le pousser à 100% au démarrage, cassage d'oreille assuré).

Je pense que ce paramètre pourrai être par défaut à non, car il déroute bon nombre d'utilisateurs...

De plus un autre projet, Breath utilise le SDK Unreal Engine 3, qui n'a aucunement l'intention de produire des jeux qui tournent sur autre chose que windows...

> il devient trivial pour un publicitaire de récupérer la liste de toutes les pages que je lis
Et il devient d'autant plus trivial de bloquer toutes les ip(v6) liées à ces publicitaires.

En admettant que ce ne soit pas une blague :

- le coût de la transition, tant au niveau matériel que formation du personnel
- les problèmes de compatibilités matérielles et logiciels
Voila 12 ans que ipv6 à été normalisé, la question serai plutôt POURQUOI il existe encore des problèmes d'incompatibilités, tant logiciel que matériel, et POURQUOI tous le monde n'a pas été formé ?
La procrastination jusqu’au dernier moment c'est bien gentil, mais c'est en aucun cas une excuse...

- la complexité de cette v6
Ha bon ?

Le problème du manque d'adresse est réel, et le problème poser par les NAT est également réel (traversé les NAT, ouvrir des ports à gogo dans les routeurs, tous ça...).
Rien que dans la pièce ou je me trouve, j'ai 6 appareils connectés, j'aimerai vraiment que chacun est une adresse unique, et tant qu'a faire qu'il n'y ai plus de différenciation adresse locale/internet.

- les questions graves sur la vie privée
Et encore, il y a pire : les adresses postales sont FIXE. Tu y crois ?? Vite, révolution !
Non mais sérieux, à un moment, pour aller d'un point A à un point B, il vaut mieux connaitre l'adresse du point B. C'est un problème difficilement solvable.
L'ip dynamique n'est pas une mesure anonimisation efficace. Et en plus très beaucoup de gens sont déjà en ipv4 statique.

- x264 c'est un encodeur h264.

ffmpeg, gstreamer ou phonon sont des "frameworks multimédia"
En gros ils permettent l'encodage, le décodage, la gestion des conteneurs, parfois le streaming, au travers d'interfaces unifiés (indépendantes des formats audio/vidéos/conteneurs utilisés)

A la différence près que :
- Phonon ne fait qu'utiliser des backend (gstreamer, ffmpeg, xine, ...).
- Gstreamer aussi utilise en grande partie d'autre logiciels (xine, ffmpeg, ...) et non pas du code qui lui est propre, au travers d'un système de plugins.
- ffmpeg contient lui entre autre "libavcodec" qui implémente à peu près toute les normes audio/vidéos existante et "libavformat" qui peut lire/écrire dans à peu près tous les conteneurs existants.

- xine quand à lui est un logiciel de lecture multimédia, qui jongle entre l'utilisation de librairies multimédia existantes et ses propres implémentations (enfin la je ne sais plus trop j'avoue), mais peut également exposer ses fonctionnalités et servir de backend pour d'autres logiciels/frameworks au travers de "xine-lib"


Voila voila, j'ai simplifié mais j’espère que c'est plus clair.
Enfin d'ailleurs en me relisant je pense que c'est moins clair maintenant. Mais c'est comme ça, c'est le bordel...