Streamer haut de gamme

[volpone75]

(06-15-2018, 11:48 AM)Bruno a écrit : En dehors du fait que toutes les discussions finissent inévitablement de la même façon, un état entre jugement et prosélytisme, il y a 2 excès dans ce petit monde, exclure la raison et n'admettre qu'elle.

Avec la musique en prétexte qui n'en demande probablement pas tant.

Bien sur mais on peut aussi simplement se demander de façon très pragmatique si cela vaut le coup de dépenser 7000 euros ou plus dans un "streamer haut de gamme" et essayer d'avoir des critères pour le faire ou pas ... Sur les équipements analogiques (DAC compris) c'est sans doute plus facile d'avoir de tels critères même si bien sur il n'y a pas de stricte proportionnalité entre le prix et les performances.

[Pascal64]

Citation :un processeur fonctionne pareil si sa charge est à 20% ou à 80%...
plus un processeur est chargé implique en général que l´on va multiplier les accés mémoire....
et donc la possibilité d´avoir une reorganisation des pages mémoires, des tables ou voir d´avoir des cache flush...
 j´avoue que j´ai des doutes que cela puisse affecter la lecture d´un fichier audio...

C'est un paramètre bien connu des linuxiens : il faut solliciter le moins possible le processeur.
Mais attention, on ne parle pas de 20% ...c'est déjà beaucoup trop.
Pour bien faire il faut se rapprocher des 2 à 3 %
Et diminuer le nombre de fils / opérations / trucs inutiles 

Si la différence n'est pas audible c'est qu'il y a un problème ailleurs *
Sur les macs, certains copains jadis réticents  viennnent d'arriver à la même conclusion : plus c'est light, mieux c'est.

*R11 va nous dire que c'est encore la faute du local d'écoute .... que Bz31 n'a pas réussi à rejoindre en double aveugle 

Désolé 

[Chet]

Moins y'a de process, moins y'a de gestion des niveaux d'interruption !
On l'observe avec le % d'occupation du proc. mais ce n'est pas la cause.
Un "petit" processeur occupé à peu de process mais à 60% d'occupation donnera un meilleur résultat qu'un "puissant" proc. gérant de nombreux process même si il n'est qu'à 20%...
Conclusion : Machine dédiée, OS minimaliste.
-> Principe de base des systèmes "temps réel" ou "embarqués"

[Jacques92]

Je répète, il serait interessant que ce qui rapportent des différences d'écoutes entre deux plateformes "bit-perfect" apporte aussi des information sur le DAC mis en œuvre et l'interface utilisée.
On parle Streamer haut de gamme ici mais il reste une question de fond qui est suggérée ici mais pas formalisée : vaut-il mieux investir dans un Streamer de compète qui ne pollue pas et fournit toutes les données comme il faut ou dans un DAC résiliant à toutes les problèmes en amont ? C'est un peu ce que je voulais dire dans mes posts précédents.

A propos de la consommation CPU : le problème est assez simple. Avec un CPU chargé à 90%, les données arrivent-elles encore dans les temps pour un DAC USB asynchrone avec une bonne FIFO/PLL (genre Soekris) ? J'ose espérer que oui pour un Linux avec ALSA. Toutefois il est très clair qu'un CPU à 90% arrose plus les alentours au niveau électromagnétique et des alimentations.

[r11bordo]

(06-15-2018, 12:19 PM)Pascal64 a écrit : C'est un paramètre bien connu des linuxiens : il faut solliciter le moins possible le processeur.
Mais attention, on ne parle pas de 20% ...c'est déjà beaucoup trop.
Pour bien faire il faut se rapprocher des 2 à 3 %
Et diminuer le nombre de fils / opérations / trucs inutiles 

Si la différence n'est pas audible c'est qu'il y a un problème ailleurs *
Sur les macs, certains copains jadis réticents  viennnent d'arriver à la même conclusion : plus c'est light, mieux c'est.

*R11 va nous dire que c'est encore la faute du local d'écoute .... que Bz31 n'a pas réussi à rejoindre en double aveugle 

Désolé 

J'ai fait une petite expérience avec un transcodage FLAC -> WAV sous LMS, consommation CPU générée très light, inferieure à 4% de memoire, l'effet est bénéfique. 
Même opération faite sur Minimserver avec une hausse de la consommation CPU entre 7 et 13%. L'effet est ici moins bénéfique que sous LMS. J'ai désactivé la transco sous miniserver. 
J'étais en mode aveugle ce coup ci, j'avais enlevé mes lunettes ... 

[a supprimer merci]

Je ne pense pas que la charge CPU soit le seul facteur, notamment lorsqu'il s'agit d'utiliser une sortie USB audio. La façon dont le flux audio est transmis au port USB (timing, taille des paquets) à probablement une influence significative (à la fois en sortie du PC et en entrée du DAC).

[Chet]

La musique est une application temps réel.
L'idéal est donc d'utiliser un environnement "temps réel", CàD déterministe sur la durée du process. 
https://doc.fedora-fr.org/wiki/Fedora_et...3.A9el_.3F

[volpone75]

(06-15-2018, 12:36 PM)Jacques92 a écrit : Vaut-il mieux investir dans un Streamer de compète qui ne pollue pas et fournit toutes les données comme il faut ou dans un DAC résiliant à toutes les problèmes en amont ? C'est un peu se que je voulais dire dans mes posts précédents.
....

Tout à fait.
La question subsidiaire est de savoir sur quoi on peut se baser pour s'assurer qu'un streamer de compète ne pollue pas ou qu'un DAC est résilient ... On est probablement dans du relatif et pas sur que la lecture des specs aide beaucoup pas plus d'ailleurs que les impressions d'écoute des uns ou des autres.

[a supprimer merci]

(06-15-2018, 12:52 PM)Chet a écrit : La musique est une application temps réel.
L'idéal est donc d'utiliser un environnement "temps réel", CàD déterministe sur la durée du process. 
https://doc.fedora-fr.org/wiki/Fedora_et...3.A9el_.3F

Le temps réel n'est pas pertinent pour un usage audio "domestique", sauf si on fait du "multi-room" ou de la multi-amplification sur base de traitements informatiques. Dans un usage simple, grande majorité des cas ici, la latence n'a aucune importance.

[KIKIWILLYBEE]

Bonjour les Gars ! :-),

SVP, pour la musicologie, cette notion de Temps réels, est apparue dans les années '6o '7o,
ou les montages de musiques contemporaines se différencier en deux écoles TECHNIQUES,
L'une ou le montage technique, encore utopique, à l'époque permettrait l'expression en' temps réels',
l'autre pragmatique, et plus classique, à l'aide de bandes magnétiques par exemple ...ce faisait En Batch ..,(temps différés) ,
Pierre Boulez (vs M. Landowski), concrétisera , cette première expression, en 1981 avec la pièce 'RESPONS',
(prononcé ' REPON' v1 à v3 en 1984.).(essentiellement grâce aux progrès de l'informatique et aux centaines de millions de francs consacrés au labo de l'IRCAM (sous sol de Beaubour) et à la personnalité hégémonique de Pierre BOULEZ...) (débat ?... )


pour la techno, et @ JACQUES, stp, est il déjà possible de serier la sensibilité du DAC vis a vis de son entrée I2S.
(data, mclk, bclck,lrck). ???? :
Comme tu le précises un DAC R2R 'vec on board un FGPA FIFO RECLOCK serai moins sensible à l'intégrité du signal MCLK,
stream entrant,+ pour un DELTA SIGMA AKm qui fera un reckloking inside du MCLK, tandis qu'un ESS plus independant du MCLK
avec son horloge asynchrone interne pour lui ....???
`
bien à vous,
cdlt,
w :-)