Le meilleur DAC ?

» 10 Nov 2002 2:05

PS : Sachez Mr que vous êtes privilegié puisque vous êtes le SEUL que je vouvoie ici, allez savoir pourquoi

Je sais, j'impressione tjrs.[/quote]

Je vous l'accorde, Suave, vous êtes particulièrement IM-PRES-SIO-NANT, par votre connerie :evil:

» 10 Nov 2002 2:11

Mr Suave a écrit:Là aussi, juste un petit buffer. Ceci dit tu peux virer 100 ech./secondes
de facon aleatoire sans que ce soit audible.

Alors, non, justement, si les deux signaux ne sont pas synchrones (effectivement, isochrone semble mieux adapté ), tu pourras mettre tout les buffers que tu veux, soit le DAC est plus rapide que la platine et son buffer tombera OBLIGATOIREMENT en pénurie.

Non le buffer est là. Ex: si DAC "plus rapide" d'1Hz il suffit de le
decaler le DAC de la lecture de quelques milli secondes.

Soit la platine est plus rapide que le DAC et alors le buffer du DAC sera OBLIGATOIREMENT saturé tot ou tard. Et ceci QUELLE QUE SOIT LA TAILLE DU BUFFER !!!

Un buffer de 16Mo permet a la platine des erreurs de +/- 50%
sur plusieur dixaine de seconde. Même l'horloge d'un lecteur
carrefour ne passe pas de 44100Hz a 20000Hz ou 60000Hz !

Apres, si virer 100 echantillons par secondes n'est pas audible, je n'en sait rien et je veux bien l'admettre. Cependant, la soit disant perfection en prend un serieux coup dans l'aile !!!

Fait toi même l'experience.

Et bien non, justement d'apres JB (et je lui fait confiance la dessus), la norme SPDIF ne transmet pas le signal d'horloge !!!

The physical link for S/PDIF carries a Biphase Manchester Coded
stream with a line level of 0.5 volts and transformer isolation at
both ends. Manchester Coding is a class of line coding methods which
combining a data stream with a clock on a single channel where there
are up to two transitions on the line for each bit conveyed. With
Biphase Manchester, there is a line transition at each end of a bit
period and a central transition if the data is a one.

» 10 Nov 2002 2:18

loloboy a écrit:
mr_suave a écrit:
mais quel est l'ampli et les enceintes qui ont le bonheur de s'y joindre ?

Tout comme la couleur de mes chausettes cela n'a aucune influence
sur le signal numerique en sortie.

Si on arretait la... on frise le pathetique... parlons plutot de DAC (sauf si tout le monde s'en fout) !!!

L'ampli et/ou les enceintes ne change en rien le signal numerique.

» 10 Nov 2002 2:21

Je vous l'accorde, Suave, vous êtes particulièrement IM-PRES-SIO-NANT

Merci.

» 10 Nov 2002 3:09

mr_suave a écrit:
Bon, je vois que c'est reparti comme sur Delphi

C'est pas parce que je t'ai ecrassé sur Delphi qu'il faut venir
te venger ici! Va troller sur Delphi.

"Beuh y'a pas de PHP sur ta page, je le sais j'ai édité le source html"
(c) Ninja40

C'est la ninja touch, on le repere de tres loin! Sans compter la
tripoté de pseudo qu'il a crée rien que pour être "plusieur"
contre moi!

Pauvre debile. Tu ne t'ameliores pas avec le temps.

» 10 Nov 2002 12:18

mr_suave a écrit:Non le buffer est là. Ex: si DAC "plus rapide" d'1Hz il suffit de le
decaler le DAC de la lecture de quelques milli secondes.
Un buffer de 16Mo permet a la platine des erreurs de +/- 50%
sur plusieur dixaine de seconde. Même l'horloge d'un lecteur
carrefour ne passe pas de 44100Hz a 20000Hz ou 60000Hz !

Bon, je reprend mon exemple de lecteur a 44104 Hz et de DAC a 44096 Hz (ce qui corresponds aux tolerances hautes et basses sur la fiabilite d'horloge des quartz... a temperature constante).
J'ai un buffer de 16 MO (16 777 216 Octets... voyons gros

) juste avant le DAC. En une seconde mon drive balance (sans tenir compte des données rajoutées par le protocole SPDIF) 44104 * 2 Octets soit 88208 Octets. Alors que mon DAC en consomme 88192. Il reste alors 16 Octets non consommés par le DAC dans le buffer. Au bout d'un peu plus de 1 000 000 de secondes (11 jours et demi de lecture non stop), mon buffer explosera. CQFD. La solution (sale je l'admet, mais simple) sera vraisemblablement de vider le buffer, causant un trou dans la lecture qui sera audible...
Bon, comme je suis en forme, je prends l'exemple opposé. le lecteur travaille à 44096 Hz et le DAC à 44104 Hz. J'ai toujours 16 Mo de buffer. J'appuie sur play j'attend que le buffer se remplisse (deja, je ne te cache pas que ca me fait chier, surtout quand je zappe d'une chanson a l'autre et que j'attend a chaque fois). Le lecteur balancant 88 192 Octets par seconde, mon buffer est plein au bout de 190 secondes... plus de 3 minutes avant d'entendre du son sortir de mes enceintes

deja je te renvoie ta platine a la gueule. Mais soit, maintenant, je suis tranquille... ben non, sachant qu'a chaque seconde mon DAC va consommer 16 Octets de plus que ce qu'envoie le lecteur, au bout de 11 jours et demi de lecture non stop, mon buffer sera vide et j'aurais un trou dans ma musique (pourquoi pas un trou de 3 minutes le temps que mon buffer se remplisse).
Voila !!!

mr_suave a écrit:
celui qui a raison $\"8)\"$ a écrit:Apres, si virer 100 echantillons par secondes n'est pas audible, je n'en sait rien et je veux bien l'admettre. Cependant, la soit disant perfection en prend un serieux coup dans l'aile !!!

Fait toi même l'experience.

La question n'est pas la. On parle ici de perfection... Tu sais, sinon autant tout ripper en MP3, dans un certain nombre de cas, si le MP3 est bien fait, la majorite des personnes ne verra pas la différence.

mr_suave a écrit:
The physical link for S/PDIF carries a Biphase Manchester Coded
stream with a line level of 0.5 volts and transformer isolation at
both ends. Manchester Coding is a class of line coding methods which
combining a data stream with a clock on a single channel where there
are up to two transitions on the line for each bit conveyed. With
Biphase Manchester, there is a line transition at each end of a bit
period and a central transition if the data is a one.

A vérifier...

» 10 Nov 2002 12:28

mr_suave a écrit:"Beuh y'a pas de PHP sur ta page, je le sais j'ai édité le source html"
(c) Ninja40

Enfin, si effectivement il a écrit ça, c'est pas PHP qu'il a découvert, mais le fonctionnement d'un serveur WEB... Mais bon, en partant comme ca, si il faut se foutre de la gueule des gens, je suppose que tu connais par coeur le RFC 2068 ? (PS : je m'adresse a Mr Suave)
PPS : et puis si on en est a ce niveau, sais-tu que Mr. est l'abreviation de Mister et que, etant dans un pays fracophone, tu t'es planté dans ton pseudo qui aurait du etre M. Suave (M. pour Monsieur)...
PPPS : je suis fière d'élever le niveau du débat de la sorte :cry:

» 10 Nov 2002 14:15

loloboy a écrit:
mr_suave a écrit:"Beuh y'a pas de PHP sur ta page, je le sais j'ai édité le source html"
(c) Ninja40

Enfin, si effectivement il a écrit ça, c'est pas PHP qu'il a découvert, mais le fonctionnement d'un serveur WEB... Mais bon, en partant comme ca, si il faut se foutre de la gueule des gens, je suppose que tu connais par coeur le RFC 2068 ? (PS : je m'adresse a Mr Suave)
PPS : et puis si on en est a ce niveau, sais-tu que Mr. est l'abreviation de Mister et que, etant dans un pays fracophone, tu t'es planté dans ton pseudo qui aurait du etre M. Suave (M. pour Monsieur)...
PPPS : je suis fière d'élever le niveau du débat de la sorte

Merci, mais je bosse aussi dans l'informatique et je sais comment fonctionne un serveur Apache. Sa page est completement statique et pas vraiment de la plus haute complexite. Je ne vois pas ou elle a besoin de php (adresse xxxx.php). A moins qu'il utilise en plus une base de donnees Oracle pour ses trois photos...
J'ai arrete de repondre a ce genre de conneries, parce que je me le suis deja coltine suffisamment pour savoir que c'est peine perdue.

Je t'invite instamment a parcourir la filiere indiquee au-dessus. Tu verras que toute discussion est peine perdue. Certains ont meme pousse la civilite jusqu'a inviter le gus chez eux pour ecouter (vers le 500e message). Invitations toujours refusees (et il faut voir comment ! 8438.509). Tu te rendras enfin compte (msg 700 et des poussieres et suivants) que tu as affaire a un nevrose qui ne se sent exister que par la provocation. Apres mon msg 709, j'ai arrete de le lire. C'est la seule facon de l'arreter. Ca a mis 1300 msg, mais c'est la conclusion a laquelle sont parvenus a peu pres tous les membres du forum Delphi.

» 10 Nov 2002 16:17

> C'est la seule facon de l'arreter.

Do not feed the troll...

» 10 Nov 2002 18:48

Salut Ninja,
je ne voulais pas te vexer ou t'insulter avec ma remarque sur les serveurs Web :oops:

Tu sais, quand je vois la complexite de son serveur musical et quand je lit qu'en plus il a ete necessaire de programmer des choses en PHP, PERL et en C, je me dit que Mr Suave est sans probleme capable de stocker son site web 100% statique dans une BDD pour le plaisir. A la rigueur, pourquoi pas, ca peut etre sympa pour une figure de style.
Perso, son serveur musical, je le ferais sous windows avec un bete partage de fichiers... je ne vois deja pas quelles fonctions differeraient. A part le partage es playlistes. Et si vraiment le partage des playliste est important, un serveur UNIX avec une floppee de terminaux X ferait l'affaire. Enfin...
Bon, puisque je crois que la discussion sur les DAC est terminée, est ce que quelqu'un pourrait me dire, en deux lignes, d'ou vient cette expression Troll ??? (je sais pas, ces creatures ne sont pas sympa dans la literature, mais j'ai jamais lu un bouquin ou elles polluaient les forum de discussions :lol:

)
A+

» 11 Nov 2002 0:23

Bon, je reprend mon exemple de lecteur a 44104 Hz et de DAC a 44096 Hz (ce qui corresponds aux tolerances hautes et basses sur la fiabilite d'horloge des quartz... a temperature constante).
J'ai un buffer de 16 MO (16 777 216 Octets... voyons gros ) juste avant le DAC. En une seconde mon drive balance (sans tenir compte des données rajoutées par le protocole SPDIF) 44104 * 2 Octets soit 88208 Octets. Alors que mon DAC en consomme 88192. Il reste alors 16 Octets non consommés par le DAC dans le buffer. Au bout d'un peu plus de 1 000 000 de secondes (11 jours et demi de lecture non stop), mon buffer explosera. CQFD.

Mais où trouves tu donc des CD avec des titres de 11 jours? En moyenne le format et 3 minutes...

Bon, comme je suis en forme, je prends l'exemple opposé. le lecteur travaille à 44096 Hz et le DAC à 44104 Hz. J'ai toujours 16 Mo de buffer. J'appuie sur play j'attend que le buffer se remplisse (deja, je ne te cache pas que ca me fait chier, surtout quand je zappe d'une chanson a l'autre et que j'attend a chaque fois). Le lecteur balancant 88 192 Octets par seconde, mon buffer est plein au bout de 190 secondes...

Pour un titre de taille moyenne, 3mns:
180 secondes * (44104 - 44096) * 32 = "Ca tient dans une RAM de 5Ko"

plus de 3 minutes avant d'entendre du son sortir de mes enceintes deja je te renvoie ta platine a la gueule.

Non. Decalage = (180 x (44104 - 44096)) / 41100

Soit environ 2 millisecondes !

mr_suave a écrit:
The physical link for S/PDIF carries a Biphase Manchester Coded
stream with a line level of 0.5 volts and transformer isolation at
both ends. Manchester Coding is a class of line coding methods which
combining a data stream with a clock on a single channel where there
are up to two transitions on the line for each bit conveyed. With
Biphase Manchester, there is a line transition at each end of a bit
period and a central transition if the data is a one.

A vérifier...

C'est plus que verifier!

» 11 Nov 2002 0:35

Merci, mais je bosse aussi dans l'informatique

Aller aller, a d'autre Ninja!

et je sais comment fonctionne un serveur Apache. Sa page est completement statique et pas vraiment de la plus haute complexite.

Ok Ninja il n'y a pas de logo en flamme!

Je ne vois pas ou elle a besoin de php (adresse xxxx.php).

Mais comment pourrais tu le voir?
A moins que tu aies une taupe chez Proxad tu ne peux RIEN voir.

A moins qu'il utilise en plus une base de donnees Oracle pour ses trois photos...

Probablement! Ce qui est amussant c'est n'ayant aucun argument pour tes delires acoustiques tu t'interesse au PHP de ma page!

» 11 Nov 2002 2:41

mr_suave a écrit:Mais où trouves tu donc des CD avec des titres de 11 jours? En moyenne le format et 3 minutes...

Si tu ecoutes un peu de classique, tu toubes vite sur des morceaux de 15 minutes. Et de plus, si j'appuie sur la touche REPEAT, la duree de la lecture n'est plus bornée (enfin si, par l'intervalle entre deux coupures de courant EDF

)

mr_suave a écrit:Pour un titre de taille moyenne, 3mns:
180 secondes * (44104 - 44096) * 32 = "Ca tient dans une RAM de 5Ko"

OK, et 25 Ko pour un titre de 15 mn. Donc, entre deux pistes, tu vide ton buffer pour ne pas etre géné. OK, mais comment tu fait pour les enregistrements live (ou il n'y a pas de pause entre les morceaux) ?

mr_suave a écrit:Non. Decalage = (180 x (44104 - 44096)) / 41100
Soit environ 2 millisecondes !

Oui, décallage si tes morceaux font 3mn et que tu vides ton buffer entre 2 morceaux, alors ca marche. Mais si par megarde, tes morceaux sont plus long, qu'ils s'enchaine sans temps mort (live) et qu'en plus tu passes en repeat, le decallage ne fonctionne plus et tu retombe sur les problemes de buffer.

mr_suave a écrit:C'est plus que verifier!

Peut etre pour toi...
A+

PS : bon, pour l'histoire du repeat, il parait evident qu'entre deux lectures du disque, les buffers sont reinitialises... cependant, le cout du live est quand meme valable. Ce qui nous oblige a avoir environ 150 Ko de buffer (voire plus si comme il est assez probable, la difference de cadence des deux horloges est plus importante... par exemple a cause d'un ecart de temperature)

» 11 Nov 2002 9:44

Discussion stérile, dommage, bye !

» 11 Nov 2002 14:59

PS : bon, pour l'histoire du repeat, il parait evident qu'entre deux lectures du disque, les buffers sont reinitialises... cependant, le cout du live est quand meme valable. Ce qui nous oblige a avoir environ 150 Ko de buffer (voire plus si comme il est assez probable, la difference de cadence des deux horloges est plus importante... par exemple a cause d'un ecart de temperature)

Le moindre µC integre 4Mo de RAM et d'ici peu la platine n'existera plus.