Nicolas Boulay a écrit 16008 commentaires

Ce que je sous-entendais c'est que les pro-vinyl parlent toujours de l'analogique comme du saint graal car il n'y a pas de discrétisation, (mais ne connaisse pas la notion de SNR). Or si il y a mixage numérique, il y a déjà eu une discrétisation.

"La première sécurité est la liberté"

Tu va soutenir qu'il existe encore de façon industriel, des personnes qui vont de l'enregistrement de la musique ou de la voie, jusqu'à la gravure d'un vinyl sans jamais passer par une numérisation ?

"La première sécurité est la liberté"

Pourquoi ?

Le monitoring est censé être ultra neutre. Ici, c'est surtout pour éviter les pertes et désagrément des filtres actifs. Pour séparer les fréquences, et garder le niveau sonore, sans trop de perte d'énergie, impose des choix techniques, pas forcément les meilleurs d'un point de vue sonor.

"La première sécurité est la liberté"

Avec 12V tu ne dois pas avoir 15W de puissance. Est-ce qu'elle n'est pas trop bruité ? C'est une alim a découpage.

"La première sécurité est la liberté"

L'important c'est ton alim, qu'est-ce que tu utilises ? Tu as 25W uniquement avec 20V.

"La première sécurité est la liberté"

pas seulement, le vinyl a aussi de contrainte mécanique de fabrication qui limite la précision, il y a l'usure aussi. Et je ne parle pas de mixage analogique qui n'existe plus.

60 dB de snr pour du vinyl… 90 pour un CD

"La première sécurité est la liberté"

Le classe A cela consomme, mais y'a pas mieux au niveau distortion.

A condition d'avoir un monstre de puissance, et de rester à des niveaux très raisonnable. De toute façon, le problème est "tué", un ampli a 400€ fait le boulot, cela sera le HP le problème. D'ailleurs, vu les problématiques de filtre pour chaque bobines, je ne comprends pas pourquoi aucun fabricant de fait des enceintes amplifié quitte à prendre du pure audio en entrée. Le format analogique change beaucoup moins vite que les formats numériques. Cabasse fait les Ki à 11k€/u…

Des haut parleurs avec entrée numérique + bananes cela serait top… il pourrait avoir un Tamp par bobines, cela serait suffisant. N'importes qui pourrait les utiliser même avec un jack.

"La première sécurité est la liberté"

"- Je n'ai parlé de vinyle. pour commencer. Même si mon oreille a sans doute été formée avec. Quand à la bouillie… je ne crois pas. Clair et net."

Si tu vires les CD, il reste quoi ? Les bandes magnétiques ?

D'un point de vue signal, les vinyles qui ont déjà 60db maximum de snr, utilisent de la compression fréquentielle dans les aigus et les graves. C'est limite un signal aléatoire dans ces fréquences là.

Les baffles les plus "cool" étaient en mon temps : Cabasse pour la musique classique et Bose pour la musique plus moderne

Aujourd'hui, cela dépend des modèles. J'ai des cabasses que j'aime beaucoup. Mais pour avoir le son le meilleur, il faudrait les décoller fortement du mur pour éviter le "rebond sonore" et cela s'entend beaucoup, plus qu'une +forte compression mp3 (cela détruit les détails du son). Donc mettre plus de 300 à 500€ la baffle, il faut pouvoir les placer exactement au bon endroit, souvent à plus d'un mètre d'un mur…

"La première sécurité est la liberté"

"Je me souviens d'un ampli de marque NAD, qui a 1 Watt de puissance "

Le mini d'un nad cela doit être 40W. Tu parles de quoi exactement ?

"Ces 1% sont largement "pètés" par le mp3 et autres formats destructeurs, mais aussi par le format CD numérique."

Le bit rate rentre beaucoup en compte au dessus de 224kbits c'est dur de faire la différence avec un CD. Par contre, ne parles pas de Hifi avec un vinyle, c'est juste de la bouillie d'un point de vue traitement du signal. C'est peut être de la bouillie agréable, mais cela reste de la bouillie. (un peu comme les ampli à tube, qui colore fortement le son)

"Le meilleur rendu que j'ai jamais obtenu est une "baffle" de basse ouverte avec un labyrinthe de 3 mètres afin d'éviter le court circuit acoustique."

Tu parles de l'onde arrière qui peut parfois "tuer" le son sur des plages de fréquences précises ? En général, sur la plus part des HP "hifi", il y a un paquet de mousse pour l’empêcher de sortir. (à l'inverse des bass reflex, qui retourne l'onde pour augmenter la puissance mais bien trop dans certaines fréquences)

"La première sécurité est la liberté"

Le hifiBerry se branche directement sur une Rasperry donc tu as ta réponse.

"La première sécurité est la liberté"

"Ou comme un contrôleur mémoire supplémentaire par le CPU, pour obtenir une machine NUMA (un peu comme les chip de SGI dans ses grosses machines). Bon après il vaut toujours mieux avoir le réseau haut débit qui va avec derrière."

Non, non et non. Surtout pas !

C'est un enfer à faire correctement ces machines là. La gestion de cohérence de cache et la localité de l'accès mémoire devienne primordial, ce qui demanderait un énorme boulot sur le noyau de Linux lui-même, avec aucune garanti de résultat.

Aujourd'hui, on ne fait plus de mémoire partagé, au contraire, on fait du "share nothing" avec des communications explicites, il faut donc des liens explicites de communication à latence ultra-faible, qui peuvent très bien reposer sur du TCP/IP pour la facilité.

"Ou je me trompe ?"

Oui tu te trompes, il n'est jamais question de faire le boulot en entier par une seul instruction, mais simplement de faire une partie de l’algorithme qui est lent.

"La première sécurité est la liberté"

D'après ici : http://www.ti.com/lit/ds/symlink/tas5713.pdf la puissance dépend directement de l'alimentation, qui peut monter à 20V.

"La première sécurité est la liberté"

"On peut monter le volume jusqu'à 70-80 dB sans grosses distorsions. Après, je pense que c'est le hifiberry qui ne suit plus."

C'est surtout tes haut parleurs qui ne suivent plus. Si les HIFIBerry sont basé sur du Tamp, Ils sont très très bon jusqu'à la moitié de leur puissance, ensuite cela se dégrade mais cela reste bon. Il faut aussi que l'alimentation suivent sans broncher.

Un haut parleur de base, c'est 200€, difficile de parler de hifi à moins chère. Avec 10W, difficile d'avoir autre chose que des bibliothèques, mais rien n’empêche d'avoir un caisson de basse en plus. Il faut donc trouver des HP avec un "bon rendement", en gros cela veut dire qu'ils utilisent moins de courant pour la même tension, et donc nécessite moins de puissance. Le 8 ohms que l'on voit partout n'est qu'une moyenne. J'ai des HP ou cela tombe à 2 ohm en basse fréquence (donc pour le même volume sonore, l'ampli doit fournir 4x plus de courant).

"La première sécurité est la liberté"

Disons que sans le succès de ses petites machines 32 bits only, il y aurait eu une pression énorme pour tout passer au 64 bits. Là, il avait toujours une excuse pour dire, "on va se couper d'une partie des utilisateurs non négligeable".

"La première sécurité est la liberté"

Maintenant oui, mais ma proposition était vrai aussi en 2005. Pour un même code C, j'avais en gros +20% de performance.

"La première sécurité est la liberté"

Tu n'as rien compris. Si tu es en 32 bits, avec 4 Go de ram, c'est pour les utiliser. Donc ton application va chercher à allouer des gros morceaux de mémoire contiguë en mémoire virtuelle. Or avant de faire son alloc, il y a déjà un paquet de truc présent dans l'espace mémoire virtuelle de l'application (alloc précédente, lib, code), et trouver des "gros morceaux" contiguë est difficile.

Le problème n'est pas la quantité, mais les tailles maximum des morceaux.

J'ai eu le problème avec une jvm embarqué qui alloue un gros morceau aux démarrages.

"La première sécurité est la liberté"

N’empêches que Intel a grave merdé d'avoir sorti de nouveau processeurs uniquement 32 bits, quand le 64 bits commençait à décoller. Cela a longuement retardé la bascule, et garder en vie windows XP bien trop longtemps.

"La première sécurité est la liberté"

Je crois que tu as complètement oublier l'intérêt des benchs : savoir ce qui va le plus vite pour l'utilisateur, et pas seulement, pourquoi cela va plus vite.

Cela peut être intéressant de faire des microbenchmark pour mesurer l'effet d'un seul paramètre. Mais l'utilisateur s'en contre-fou : c'est la vitesse de son application qui comptent, dans les versions facilement accessibles. Par exemple, si son application n'utilise pas SSE, alors quelle le pourrait, le gain attendu sera faible. C'était le cas de beaucoup de code au lancement du x64, qui n'avait pas de routines en assembleur.

C'est aujourd'hui, plus le cas. De toute façon, le code x64 est plus rapide en général uniquement grâce au doublement du nombre de registres généraux disponible.

"La première sécurité est la liberté"

Dans tout votre baratin, vous oubliez un problème très chiant quand vous adressez un problème utilisant toute la RAM et qui s'approche du maximum en 32 bits. C'est la pénurie d'espace d'adressage.

En gros, linux va mapper des lib partagé un peu partout dans l'espace d'adressage virtuel. Ensuite, l'application va vouloir allouer un gros bloc de 2 Go : et bien il ne pourra pas ! Car l'espace virtuelle (virtuelle pas physique) est saturé. Le problème se pose aussi avec les applications 32 bits sous noyau 64 bits. Sous windows, il y a en plus des libs de converssion 32/64 qui fragmentent encore plus. Ce qui veut dire que des applications fonctionnent avec un windows 32 bits, mais plus avec un windows 64. Il y a même un problème temporel car plus le dernier reboot est loin, et plus de library sont chargés.

"La première sécurité est la liberté"

Pour le savon d'alep, il y a 20% d'une huile essentiel végétale, c'est encore un peu plus agressif.

Si ils ont le droit de le faire, c'est simplement que la marque n'est pas déposée, comme pour Laguiole.

"La première sécurité est la liberté"

Un "savon de marseille" qui n'est pas avec 72% d'huile d'olive….

"La première sécurité est la liberté"

Le seul et unique cas ou le mot adressé n'est pas un octet, que j'ai vu, sont des anciens DSP de TI qui utilisait des mots de 16 bits à la place. Vu que "sizeof(char) = 1" par définition du langage C, et que un char utilise la plus petite unité de mémoire adressable, tu as des char 16 bits, avec "sizeof(char) = 1". Cela casse tellement de code C, qu'il y avait un mode avec le char en octet !

"La première sécurité est la liberté"

Si vous cherchez une solution à la "chinoise" avec un gros copro qui sait faire du calcul matriciel, c'est puissant, mais cela nécessite du code réécrit. Et un serveur est loin de faire beaucoup de calcul pure.

En cherchant une autre balance cpu/perf, cela pourrait fonctionner, comme avoir beaucoup de bandes passantes par cpu (remplacer qq Mo de cache par un port DDR 256 bits comme la PS4 au lieu de 128). Et pourquoi pas pouvoir mettre plusieurs ordinateurs sur le même PCB, relié entre eux par un bridge qui pourrait être vu comme une carte réseau par linux. Ce genre de config pourrait être bien quand il y a des dizaines de GO de mémoire (un cache de 16 Mo devenant moins intéressant avec l'augmentation de la taille mémoire).

Je crois aussi beaucoup à des instructions spécifiques pour ce qui prend du temps : compression gzip, crypto, hash,… Je parle bien d'instructions et non de coprocesseurs qui ne sont jamais assez flexible et qui sont "long à lancer" (écriture sur les registres, etc…). Pour supporter ce gens d'instruction, il "suffit" de porter la lib openSSL qui gère la crypto et la libgzip.

Concernant les mémoires rapides spécifiques, les problèmes sont souvent les mêmes : latence identique à la DDR, taille réduite, et prix élevé.

"La première sécurité est la liberté"

Niveau performance vous serez forcément à la ramasse par rapport à Intel. Quelle niche pensez-vous prendre avec un RISC-V ?

"La première sécurité est la liberté"

Quand tu fais un core tu es obligé de faire les modes avec, sinon les aller-retour sont trop coûteux en temps. Autant tout faire avec le cpu.

"La première sécurité est la liberté"