Il y a t-il des gens qui ont un avis sur l'utilisation du SPDIF sur RCA
pour transporté un signal numérique entre un PC (sous linux) et une
carte son externe?
Je sais que cela fonctionne mais cela peut-il fonctionner en qualité HiFi?
Une de mes interrogations sont liés notamment à la masse: les PC sont
souvent bruité au niveau de la masse, c'est la raison pour lequel
j'envisage de prendre une carte son externe.
Je compte prendre la M-audio audiophile Firewire, malheureusement Linux
ne gere pas très bien les cartes sons firewire, donc je l'utiliserais en
spdif.
Mon but final serait un PC totalement silencieux (sans aucun ventilateur
ni disque dur) et ue carte son externe relié a mon ampli HiFi. Rest
ensuite a trouvé un lecteur CD PC qui lise correctement a vitesse
constante....
Tu pourrais développer ce concept s'il te plaît ? En effet, comment "graver" le jitter dans le signal ?
Je vais tenter une analogie. Le SRC, souvent mis en avant comme outil d'éradication du jitter, peut être décrit ainsi: On prend une feuille de papier quadrillée, amplitude en ordonnée, temps en abcisse. Donc 65536 graduations en Y, et 44100 graduations par seconde sur les X.
Hum... je reviens là dessus car quelque chose me chiffouille : Sur le cd c'est du binaire qui est écrit. donc en fait on n'aurait pas plutôt 44100*16 sur l'axe du temps et 1/0 sur l'axe des valeurs?
Bah nan, la valeurs des 16 bits est justement celle reportée en ordonnée (d'où les 65536 graduations en Y).
Tu pourrais développer ce concept s'il te plaît ? En effet, comment
"graver" le jitter dans le signal ?
Je vais tenter une analogie.
Le SRC, souvent mis en avant comme outil d'éradication du jitter,
peut être décrit ainsi:
On prend une feuille de papier quadrillée, amplitude en
ordonnée, temps en abcisse. Donc 65536 graduations en Y, et 44100
graduations par seconde sur les X.
Hum... je reviens là dessus car quelque chose me chiffouille :
Sur le cd c'est du binaire qui est écrit. donc en fait on n'aurait
pas plutôt 44100*16 sur l'axe du temps et 1/0 sur l'axe des
valeurs?
Bah nan, la valeurs des 16 bits est justement celle reportée en ordonnée
(d'où les 65536 graduations en Y).
Tu pourrais développer ce concept s'il te plaît ? En effet, comment "graver" le jitter dans le signal ?
Je vais tenter une analogie. Le SRC, souvent mis en avant comme outil d'éradication du jitter, peut être décrit ainsi: On prend une feuille de papier quadrillée, amplitude en ordonnée, temps en abcisse. Donc 65536 graduations en Y, et 44100 graduations par seconde sur les X.
Hum... je reviens là dessus car quelque chose me chiffouille : Sur le cd c'est du binaire qui est écrit. donc en fait on n'aurait pas plutôt 44100*16 sur l'axe du temps et 1/0 sur l'axe des valeurs?
Bah nan, la valeurs des 16 bits est justement celle reportée en ordonnée (d'où les 65536 graduations en Y).
Laurent
Jean-Louis Matrat
en ce 28/03/2007 07:49, FiLH nous disait:
Mais bon j'en reviens à une de mes marottes anciennes, sachant qu'on fait passer du 100Mbs voir du Gbs sans erreur et à cette vitesse sur du bon paire torsadée, oser faire un merdier qui fout de la gigue à un débit très inférieur y a quelque chose qui cloche dans le design global.
Pas si simple: sur le gigabit, la gigue, jitter, bruit de phase, comme on veut, est un risque d'erreur, mais seulement un risque. Trop de gigue, et le paquet est mauvais. En audio, la position temporelle de la donnée est un élément de celle-ci. Tout décalage temporel _est_ une erreur.
Au fait dans ce genre de communication (ethernet) sachant que c'est aussi de l'asynchrone, comment ils font pour ne pas avoir de gigue ? (ou la corriger parfaitement).
Z'en ont plein, de gigue. Le niveau de gigue acceptable est bien plus élevé qu'en audio. Je ne suis pas spécialiste, mais on peut imaginer que 20 ou 30% de décalage d'un pulse par rapport à son timing théorique ne doit pas empêcher de le lire correctement (si quelqu'un a des infos précises dans le domaine, welcome). En audio, on dit que 100 ppm c'est une horreur, et on vise 10 ppm. Périodicité: 22 µs et quelque, 2 ns beurk, 200 ps souhaité. (sorti de sa boîte, la Squeezebox fait 300 ps et quelque, comme des transports de haute volée). Bon, c'est un peu plus compliqué que ça, corrélation ou pas du jitter avec le signal, fréquence de celui-ci: ce sont des ordres de grandeur.
Tiens, jetez un oeil sur ce spectrogramme: http://cjoint.com/?dCklKiqnz4 Et sur celui-là: http://cjoint.com/?dCkmSGnl7g Vous ne voyez pas une petite différence?
A part ça, on peut aussi avoir plusieurs sources numériques, et ne se payer qu'un seul bon DAC.
Hum... ça fait riche :)
Pas tant que ça: lecteur de CD, Squeezebox, lecteur de DVD (certaines pistes PCM), radios par un récepteur satellite FTA (avec mon faible haut débit, la radio par internet c'est limite).
JLM
en ce 28/03/2007 07:49, FiLH nous disait:
Mais bon j'en reviens à une de mes marottes anciennes, sachant qu'on
fait passer du 100Mbs voir du Gbs sans erreur et à cette vitesse sur du
bon paire torsadée, oser faire un merdier qui fout de la gigue à un
débit très inférieur y a quelque chose qui cloche dans le design global.
Pas si simple: sur le gigabit, la gigue, jitter, bruit de phase, comme
on veut, est un risque d'erreur, mais seulement un risque. Trop de
gigue, et le paquet est mauvais.
En audio, la position temporelle de la donnée est un élément de
celle-ci. Tout décalage temporel _est_ une erreur.
Au fait dans ce genre de communication (ethernet) sachant que c'est
aussi de l'asynchrone, comment ils font pour ne pas avoir de gigue ? (ou
la corriger parfaitement).
Z'en ont plein, de gigue.
Le niveau de gigue acceptable est bien plus élevé qu'en audio. Je ne
suis pas spécialiste, mais on peut imaginer que 20 ou 30% de décalage
d'un pulse par rapport à son timing théorique ne doit pas empêcher de le
lire correctement (si quelqu'un a des infos précises dans le domaine,
welcome).
En audio, on dit que 100 ppm c'est une horreur, et on vise 10 ppm.
Périodicité: 22 µs et quelque, 2 ns beurk, 200 ps souhaité.
(sorti de sa boîte, la Squeezebox fait 300 ps et quelque, comme des
transports de haute volée).
Bon, c'est un peu plus compliqué que ça, corrélation ou pas du jitter
avec le signal, fréquence de celui-ci: ce sont des ordres de grandeur.
Tiens, jetez un oeil sur ce spectrogramme:
http://cjoint.com/?dCklKiqnz4
Et sur celui-là:
http://cjoint.com/?dCkmSGnl7g
Vous ne voyez pas une petite différence?
A part ça, on peut aussi avoir plusieurs sources numériques, et ne se
payer qu'un seul bon DAC.
Hum... ça fait riche :)
Pas tant que ça: lecteur de CD, Squeezebox, lecteur de DVD (certaines
pistes PCM), radios par un récepteur satellite FTA (avec mon faible haut
débit, la radio par internet c'est limite).
Mais bon j'en reviens à une de mes marottes anciennes, sachant qu'on fait passer du 100Mbs voir du Gbs sans erreur et à cette vitesse sur du bon paire torsadée, oser faire un merdier qui fout de la gigue à un débit très inférieur y a quelque chose qui cloche dans le design global.
Pas si simple: sur le gigabit, la gigue, jitter, bruit de phase, comme on veut, est un risque d'erreur, mais seulement un risque. Trop de gigue, et le paquet est mauvais. En audio, la position temporelle de la donnée est un élément de celle-ci. Tout décalage temporel _est_ une erreur.
Au fait dans ce genre de communication (ethernet) sachant que c'est aussi de l'asynchrone, comment ils font pour ne pas avoir de gigue ? (ou la corriger parfaitement).
Z'en ont plein, de gigue. Le niveau de gigue acceptable est bien plus élevé qu'en audio. Je ne suis pas spécialiste, mais on peut imaginer que 20 ou 30% de décalage d'un pulse par rapport à son timing théorique ne doit pas empêcher de le lire correctement (si quelqu'un a des infos précises dans le domaine, welcome). En audio, on dit que 100 ppm c'est une horreur, et on vise 10 ppm. Périodicité: 22 µs et quelque, 2 ns beurk, 200 ps souhaité. (sorti de sa boîte, la Squeezebox fait 300 ps et quelque, comme des transports de haute volée). Bon, c'est un peu plus compliqué que ça, corrélation ou pas du jitter avec le signal, fréquence de celui-ci: ce sont des ordres de grandeur.
Tiens, jetez un oeil sur ce spectrogramme: http://cjoint.com/?dCklKiqnz4 Et sur celui-là: http://cjoint.com/?dCkmSGnl7g Vous ne voyez pas une petite différence?
A part ça, on peut aussi avoir plusieurs sources numériques, et ne se payer qu'un seul bon DAC.
Hum... ça fait riche :)
Pas tant que ça: lecteur de CD, Squeezebox, lecteur de DVD (certaines pistes PCM), radios par un récepteur satellite FTA (avec mon faible haut débit, la radio par internet c'est limite).
JLM
Côme Desplats
FiLH wrote:
Au fait dans ce genre de communication (ethernet) sachant que c'est aussi de l'asynchrone, comment ils font pour ne pas avoir de gigue ? (ou la corriger parfaitement).
Le protocole ethernet n'est pas temps réel, et il gère les erreurs de transmissions et les collisions de paquets, avec envoi de paquets de bourrage et retransmission si besoin.
Dans la pratique on peut simuler du temps réel avec une transmission suffisamment rapide et en bufferisant un peu. C'est d'ailleurs ce qui est fait entre la Squeezebox et le PC avec un gros buffer de plusieurs Mo.
FiLH wrote:
Au fait dans ce genre de communication (ethernet) sachant que c'est
aussi de l'asynchrone, comment ils font pour ne pas avoir de gigue ? (ou
la corriger parfaitement).
Le protocole ethernet n'est pas temps réel, et il gère les erreurs de
transmissions et les collisions de paquets, avec envoi de paquets de
bourrage et retransmission si besoin.
Dans la pratique on peut simuler du temps réel avec une transmission
suffisamment rapide et en bufferisant un peu. C'est d'ailleurs ce qui
est fait entre la Squeezebox et le PC avec un gros buffer de plusieurs Mo.
Au fait dans ce genre de communication (ethernet) sachant que c'est aussi de l'asynchrone, comment ils font pour ne pas avoir de gigue ? (ou la corriger parfaitement).
Le protocole ethernet n'est pas temps réel, et il gère les erreurs de transmissions et les collisions de paquets, avec envoi de paquets de bourrage et retransmission si besoin.
Dans la pratique on peut simuler du temps réel avec une transmission suffisamment rapide et en bufferisant un peu. C'est d'ailleurs ce qui est fait entre la Squeezebox et le PC avec un gros buffer de plusieurs Mo.
FiLH
Laurent writes:
FiLH wrote: > Jean-Louis Matrat writes: > >> en ce 27/03/2007 17:31, Laurent nous disait: >> >>> Tu pourrais développer ce concept s'il te plaît ? En effet, comment >>> "graver" le jitter dans le signal ? >> Je vais tenter une analogie. >> Le SRC, souvent mis en avant comme outil d'éradication du jitter, >> peut être décrit ainsi: >> On prend une feuille de papier quadrillée, amplitude en >> ordonnée, temps en abcisse. Donc 65536 graduations en Y, et 44100 >> graduations par seconde sur les X. > Hum... je reviens là dessus car quelque chose me chiffouille : > Sur le cd c'est du binaire qui est écrit. donc en fait on n'aurait > pas plutôt 44100*16 sur l'axe du temps et 1/0 sur l'axe des > valeurs?
Bah nan, la valeurs des 16 bits est justement celle reportée en ordonnée (d'où les 65536 graduations en Y).
Ben oui mais bon sur ton signal tu commences par récupérer un flux de bit en série. Pas un signal à 2^^16 niveaux (enfin là on serait de l'autre côté du dac...).
FiLH
-- FiLH photography. A taste of freedom in a conventional world. Web: http://www.filh.org e-mail FAQ fr.rec.photo : http://frp.parisv.com/ Sitafoto la photo a Bordeaux : http://sitafoto.free.fr/
Laurent <null@null.com> writes:
FiLH wrote:
> Jean-Louis Matrat <jeantiretlouispointmatrat@wanadoo.fr> writes:
>
>> en ce 27/03/2007 17:31, Laurent nous disait:
>>
>>> Tu pourrais développer ce concept s'il te plaît ? En effet, comment
>>> "graver" le jitter dans le signal ?
>> Je vais tenter une analogie.
>> Le SRC, souvent mis en avant comme outil d'éradication du jitter,
>> peut être décrit ainsi:
>> On prend une feuille de papier quadrillée, amplitude en
>> ordonnée, temps en abcisse. Donc 65536 graduations en Y, et 44100
>> graduations par seconde sur les X.
> Hum... je reviens là dessus car quelque chose me chiffouille :
> Sur le cd c'est du binaire qui est écrit. donc en fait on n'aurait
> pas plutôt 44100*16 sur l'axe du temps et 1/0 sur l'axe des
> valeurs?
Bah nan, la valeurs des 16 bits est justement celle reportée en
ordonnée (d'où les 65536 graduations en Y).
Ben oui mais bon sur ton signal tu commences par récupérer un
flux de bit en série. Pas un signal à 2^^16 niveaux (enfin
là on serait de l'autre côté du dac...).
FiLH
--
FiLH photography. A taste of freedom in a conventional world.
Web: http://www.filh.org e-mail filh@filh.org
FAQ fr.rec.photo : http://frp.parisv.com/
Sitafoto la photo a Bordeaux : http://sitafoto.free.fr/
FiLH wrote: > Jean-Louis Matrat writes: > >> en ce 27/03/2007 17:31, Laurent nous disait: >> >>> Tu pourrais développer ce concept s'il te plaît ? En effet, comment >>> "graver" le jitter dans le signal ? >> Je vais tenter une analogie. >> Le SRC, souvent mis en avant comme outil d'éradication du jitter, >> peut être décrit ainsi: >> On prend une feuille de papier quadrillée, amplitude en >> ordonnée, temps en abcisse. Donc 65536 graduations en Y, et 44100 >> graduations par seconde sur les X. > Hum... je reviens là dessus car quelque chose me chiffouille : > Sur le cd c'est du binaire qui est écrit. donc en fait on n'aurait > pas plutôt 44100*16 sur l'axe du temps et 1/0 sur l'axe des > valeurs?
Bah nan, la valeurs des 16 bits est justement celle reportée en ordonnée (d'où les 65536 graduations en Y).
Ben oui mais bon sur ton signal tu commences par récupérer un flux de bit en série. Pas un signal à 2^^16 niveaux (enfin là on serait de l'autre côté du dac...).
FiLH
-- FiLH photography. A taste of freedom in a conventional world. Web: http://www.filh.org e-mail FAQ fr.rec.photo : http://frp.parisv.com/ Sitafoto la photo a Bordeaux : http://sitafoto.free.fr/
FiLH
Jean-Louis Matrat writes:
en ce 28/03/2007 07:49, FiLH nous disait:
> Mais bon j'en reviens à une de mes marottes anciennes, sachant qu'on > fait passer du 100Mbs voir du Gbs sans erreur et à cette vitesse sur du > bon paire torsadée, oser faire un merdier qui fout de la gigue à un > débit très inférieur y a quelque chose qui cloche dans le design global.
Pas si simple: sur le gigabit, la gigue, jitter, bruit de phase, comme on veut, est un risque d'erreur, mais seulement un risque. Trop de gigue, et le paquet est mauvais.
Dans la vrai vie le taux d'erreur en service est nul :) Ou alors les équimenents mentent.
En audio, la position temporelle de la donnée est un élément de celle-ci. Tout décalage temporel _est_ une erreur.
Oui mais on bufferise et on ressort sur une bonne horloge.
> Au fait dans ce genre de communication (ethernet) sachant que c'est > aussi de l'asynchrone, comment ils font pour ne pas avoir de gigue ? (ou > la corriger parfaitement).
Z'en ont plein, de gigue. Le niveau de gigue acceptable est bien plus élevé qu'en audio.
Bon faut m'expliquer un truc : cette gigue elle est sur le signal numérique ou sur le signal analogique ?
Parce que là tout d'un coup j'ai comme du vague à l'âme.
Tiens, jetez un oeil sur ce spectrogramme: http://cjoint.com/?dCklKiqnz4 Et sur celui-là: http://cjoint.com/?dCkmSGnl7g Vous ne voyez pas une petite différence?
Heu non ? :) C'est quoi ces machins ?
>> A part ça, on peut aussi avoir plusieurs sources numériques, et ne se >> payer qu'un seul bon DAC. > Hum... ça fait riche :)
Pas tant que ça: lecteur de CD, Squeezebox, lecteur de DVD (certaines pistes PCM), radios par un récepteur satellite FTA (avec mon faible haut débit, la radio par internet c'est limite).
Ah oui : et on a des commutateurs de source ?
FiLH
-- FiLH photography. A taste of freedom in a conventional world. Web: http://www.filh.org e-mail FAQ fr.rec.photo : http://frp.parisv.com/ Sitafoto la photo a Bordeaux : http://sitafoto.free.fr/
> Mais bon j'en reviens à une de mes marottes anciennes, sachant qu'on
> fait passer du 100Mbs voir du Gbs sans erreur et à cette vitesse sur du
> bon paire torsadée, oser faire un merdier qui fout de la gigue à un
> débit très inférieur y a quelque chose qui cloche dans le design global.
Pas si simple: sur le gigabit, la gigue, jitter, bruit de phase, comme
on veut, est un risque d'erreur, mais seulement un risque. Trop de
gigue, et le paquet est mauvais.
Dans la vrai vie le taux d'erreur en service est nul :)
Ou alors les équimenents mentent.
En audio, la position temporelle de la donnée est un élément
de celle-ci. Tout décalage temporel _est_ une erreur.
Oui mais on bufferise et on ressort sur une bonne horloge.
> Au fait dans ce genre de communication (ethernet) sachant que c'est
> aussi de l'asynchrone, comment ils font pour ne pas avoir de gigue ? (ou
> la corriger parfaitement).
Z'en ont plein, de gigue.
Le niveau de gigue acceptable est bien plus élevé qu'en audio.
Bon faut m'expliquer un truc : cette gigue elle est sur le signal
numérique ou sur le signal analogique ?
Parce que là tout d'un coup j'ai comme du vague à l'âme.
Tiens, jetez un oeil sur ce spectrogramme:
http://cjoint.com/?dCklKiqnz4
Et sur celui-là:
http://cjoint.com/?dCkmSGnl7g
Vous ne voyez pas une petite différence?
Heu non ? :) C'est quoi ces machins ?
>> A part ça, on peut aussi avoir plusieurs sources numériques, et ne se
>> payer qu'un seul bon DAC.
> Hum... ça fait riche :)
Pas tant que ça: lecteur de CD, Squeezebox, lecteur de DVD
(certaines pistes PCM), radios par un récepteur satellite FTA (avec
mon faible haut débit, la radio par internet c'est limite).
Ah oui : et on a des commutateurs de source ?
FiLH
--
FiLH photography. A taste of freedom in a conventional world.
Web: http://www.filh.org e-mail filh@filh.org
FAQ fr.rec.photo : http://frp.parisv.com/
Sitafoto la photo a Bordeaux : http://sitafoto.free.fr/
> Mais bon j'en reviens à une de mes marottes anciennes, sachant qu'on > fait passer du 100Mbs voir du Gbs sans erreur et à cette vitesse sur du > bon paire torsadée, oser faire un merdier qui fout de la gigue à un > débit très inférieur y a quelque chose qui cloche dans le design global.
Pas si simple: sur le gigabit, la gigue, jitter, bruit de phase, comme on veut, est un risque d'erreur, mais seulement un risque. Trop de gigue, et le paquet est mauvais.
Dans la vrai vie le taux d'erreur en service est nul :) Ou alors les équimenents mentent.
En audio, la position temporelle de la donnée est un élément de celle-ci. Tout décalage temporel _est_ une erreur.
Oui mais on bufferise et on ressort sur une bonne horloge.
> Au fait dans ce genre de communication (ethernet) sachant que c'est > aussi de l'asynchrone, comment ils font pour ne pas avoir de gigue ? (ou > la corriger parfaitement).
Z'en ont plein, de gigue. Le niveau de gigue acceptable est bien plus élevé qu'en audio.
Bon faut m'expliquer un truc : cette gigue elle est sur le signal numérique ou sur le signal analogique ?
Parce que là tout d'un coup j'ai comme du vague à l'âme.
Tiens, jetez un oeil sur ce spectrogramme: http://cjoint.com/?dCklKiqnz4 Et sur celui-là: http://cjoint.com/?dCkmSGnl7g Vous ne voyez pas une petite différence?
Heu non ? :) C'est quoi ces machins ?
>> A part ça, on peut aussi avoir plusieurs sources numériques, et ne se >> payer qu'un seul bon DAC. > Hum... ça fait riche :)
Pas tant que ça: lecteur de CD, Squeezebox, lecteur de DVD (certaines pistes PCM), radios par un récepteur satellite FTA (avec mon faible haut débit, la radio par internet c'est limite).
Ah oui : et on a des commutateurs de source ?
FiLH
-- FiLH photography. A taste of freedom in a conventional world. Web: http://www.filh.org e-mail FAQ fr.rec.photo : http://frp.parisv.com/ Sitafoto la photo a Bordeaux : http://sitafoto.free.fr/
FiLH
Côme Desplats <invalid> writes:
FiLH wrote: > Au fait dans ce genre de communication (ethernet) sachant que c'est > aussi de l'asynchrone, comment ils font pour ne pas avoir de gigue ? (ou > la corriger parfaitement).
Le protocole ethernet n'est pas temps réel, et il gère les erreurs de transmissions et les collisions de paquets, avec envoi de paquets de bourrage et retransmission si besoin.
Je sais je sais.
Non pas de collision de paquets vu qu'on est un réseau switché et full duplex et 15 fois le temps de retransmettre (par rapport à une vitesse audio).
Le pb n'est pas de viser une perfection théorique temps réel, mais d'avoir statistiquement un meilleur résultat avec un truc pas temps réel qu'avec un truc temps réel.
Sur ce, si je prend l'exemple d'ethernet c'est que justement c'est un protocole qui n'est pas du tout optimisé tant réel et qui transmet sans erreur à une vitesse largement supérieure à ce dont on a besion :)
Dans la pratique on peut simuler du temps réel avec une transmission suffisamment rapide et en bufferisant un peu. C'est d'ailleurs ce qui est fait entre la Squeezebox et le PC avec un gros buffer de plusieurs Mo.
Dans la pratique on transmet un cd complet en quelques secondes sur un brin giga sans une seule erreur...
FiLH
-- FiLH photography. A taste of freedom in a conventional world. Web: http://www.filh.org e-mail FAQ fr.rec.photo : http://frp.parisv.com/ Sitafoto la photo a Bordeaux : http://sitafoto.free.fr/
Côme Desplats <invalid> writes:
FiLH wrote:
> Au fait dans ce genre de communication (ethernet) sachant que c'est
> aussi de l'asynchrone, comment ils font pour ne pas avoir de gigue ? (ou
> la corriger parfaitement).
Le protocole ethernet n'est pas temps réel, et il gère les
erreurs de transmissions et les collisions de paquets, avec envoi de
paquets de bourrage et retransmission si besoin.
Je sais je sais.
Non pas de collision de paquets vu qu'on est un réseau switché
et full duplex et 15 fois le temps de retransmettre (par rapport à
une vitesse audio).
Le pb n'est pas de viser une perfection théorique temps réel,
mais d'avoir statistiquement un meilleur résultat avec un truc pas
temps réel qu'avec un truc temps réel.
Sur ce, si je prend l'exemple d'ethernet c'est que justement c'est un
protocole qui n'est pas du tout optimisé tant réel et qui
transmet sans erreur à une vitesse largement supérieure à ce
dont on a besion :)
Dans la pratique on peut simuler du temps réel avec une
transmission suffisamment rapide et en bufferisant un peu. C'est
d'ailleurs ce qui est fait entre la Squeezebox et le PC avec un gros
buffer de plusieurs Mo.
Dans la pratique on transmet un cd complet en quelques secondes sur un
brin giga sans une seule erreur...
FiLH
--
FiLH photography. A taste of freedom in a conventional world.
Web: http://www.filh.org e-mail filh@filh.org
FAQ fr.rec.photo : http://frp.parisv.com/
Sitafoto la photo a Bordeaux : http://sitafoto.free.fr/
FiLH wrote: > Au fait dans ce genre de communication (ethernet) sachant que c'est > aussi de l'asynchrone, comment ils font pour ne pas avoir de gigue ? (ou > la corriger parfaitement).
Le protocole ethernet n'est pas temps réel, et il gère les erreurs de transmissions et les collisions de paquets, avec envoi de paquets de bourrage et retransmission si besoin.
Je sais je sais.
Non pas de collision de paquets vu qu'on est un réseau switché et full duplex et 15 fois le temps de retransmettre (par rapport à une vitesse audio).
Le pb n'est pas de viser une perfection théorique temps réel, mais d'avoir statistiquement un meilleur résultat avec un truc pas temps réel qu'avec un truc temps réel.
Sur ce, si je prend l'exemple d'ethernet c'est que justement c'est un protocole qui n'est pas du tout optimisé tant réel et qui transmet sans erreur à une vitesse largement supérieure à ce dont on a besion :)
Dans la pratique on peut simuler du temps réel avec une transmission suffisamment rapide et en bufferisant un peu. C'est d'ailleurs ce qui est fait entre la Squeezebox et le PC avec un gros buffer de plusieurs Mo.
Dans la pratique on transmet un cd complet en quelques secondes sur un brin giga sans une seule erreur...
FiLH
-- FiLH photography. A taste of freedom in a conventional world. Web: http://www.filh.org e-mail FAQ fr.rec.photo : http://frp.parisv.com/ Sitafoto la photo a Bordeaux : http://sitafoto.free.fr/
shal
Jean-Louis Matrat a écrit :
En audio, la position temporelle de la donnée est un élément de celle-ci. Tout décalage temporel _est_ une erreur.
Plus je lis d'info moins je comprends. Qui a une lien vers une page expliquant simplement mais pas de facon simpliste les différents problèmes?
Pour moi, le CD audio c'est du binaire, une suite de 0 et de 1. Il faut tant de données binaire pour décrire x ms de sons. Donc, il faut que le transport soit parfait pour envoyé dans l'ordre la totalités de ces bits. Le seul problème que je voit est comment maintenir toujours plein le buffer alimentant le DAC . Il faut ps non plus que si les données arrive trop vite et que le buffer est plein les données soient perdu mais cela peut se controlé avec un canal retour d'information a celui qui rempli le buffer.
Voila ce que je pense : J'ai rien compris ou quoi?
On tombe d'un problème de canal a sens unique pour une platine CD classique a un problème de management de buffer avec retour arrière d'informations.
Au fait dans ce genre de communication (ethernet) sachant que c'est aussi de l'asynchrone, comment ils font pour ne pas avoir de gigue ? (ou la corriger parfaitement).
Z'en ont plein, de gigue. Le niveau de gigue acceptable est bien plus élevé qu'en audio. Je ne suis pas spécialiste, mais on peut imaginer que 20 ou 30% de décalage d'un pulse par rapport à son timing théorique ne doit pas empêcher de le lire correctement (si quelqu'un a des infos précises dans le domaine, welcome).
De mémoire, un paquet ethernet comme par un ensemble alterné de 0 et de 1 qui serve a synchronisé l'horloge pour la lecture des bits suivant. Codage Manchester aprés (1 veut dire changement d'état du bit et non bit 1)
Jean-Louis Matrat a écrit :
En audio, la position temporelle de la donnée est un élément de
celle-ci. Tout décalage temporel _est_ une erreur.
Plus je lis d'info moins je comprends.
Qui a une lien vers une page expliquant simplement mais pas de facon
simpliste les différents problèmes?
Pour moi, le CD audio c'est du binaire, une suite de 0 et de 1. Il faut
tant de données binaire pour décrire x ms de sons.
Donc, il faut que le transport soit parfait pour envoyé dans l'ordre la
totalités de ces bits.
Le seul problème que je voit est comment maintenir toujours plein le
buffer alimentant le DAC . Il faut ps non plus que si les données arrive
trop vite et que le buffer est plein les données soient perdu mais cela
peut se controlé avec un canal retour d'information a celui qui rempli
le buffer.
Voila ce que je pense : J'ai rien compris ou quoi?
On tombe d'un problème de canal a sens unique pour une platine CD
classique a un problème de management de buffer avec retour arrière
d'informations.
Au fait dans ce genre de communication (ethernet) sachant que c'est
aussi de l'asynchrone, comment ils font pour ne pas avoir de gigue ? (ou
la corriger parfaitement).
Z'en ont plein, de gigue.
Le niveau de gigue acceptable est bien plus élevé qu'en audio. Je ne
suis pas spécialiste, mais on peut imaginer que 20 ou 30% de décalage
d'un pulse par rapport à son timing théorique ne doit pas empêcher de le
lire correctement (si quelqu'un a des infos précises dans le domaine,
welcome).
De mémoire, un paquet ethernet comme par un ensemble alterné de 0 et de
1 qui serve a synchronisé l'horloge pour la lecture des bits suivant.
Codage Manchester aprés (1 veut dire changement d'état du bit et non bit 1)
En audio, la position temporelle de la donnée est un élément de celle-ci. Tout décalage temporel _est_ une erreur.
Plus je lis d'info moins je comprends. Qui a une lien vers une page expliquant simplement mais pas de facon simpliste les différents problèmes?
Pour moi, le CD audio c'est du binaire, une suite de 0 et de 1. Il faut tant de données binaire pour décrire x ms de sons. Donc, il faut que le transport soit parfait pour envoyé dans l'ordre la totalités de ces bits. Le seul problème que je voit est comment maintenir toujours plein le buffer alimentant le DAC . Il faut ps non plus que si les données arrive trop vite et que le buffer est plein les données soient perdu mais cela peut se controlé avec un canal retour d'information a celui qui rempli le buffer.
Voila ce que je pense : J'ai rien compris ou quoi?
On tombe d'un problème de canal a sens unique pour une platine CD classique a un problème de management de buffer avec retour arrière d'informations.
Au fait dans ce genre de communication (ethernet) sachant que c'est aussi de l'asynchrone, comment ils font pour ne pas avoir de gigue ? (ou la corriger parfaitement).
Z'en ont plein, de gigue. Le niveau de gigue acceptable est bien plus élevé qu'en audio. Je ne suis pas spécialiste, mais on peut imaginer que 20 ou 30% de décalage d'un pulse par rapport à son timing théorique ne doit pas empêcher de le lire correctement (si quelqu'un a des infos précises dans le domaine, welcome).
De mémoire, un paquet ethernet comme par un ensemble alterné de 0 et de 1 qui serve a synchronisé l'horloge pour la lecture des bits suivant. Codage Manchester aprés (1 veut dire changement d'état du bit et non bit 1)
Jean-Louis Matrat
en ce 28/03/2007 10:32, FiLH nous disait:
Ben oui mais bon sur ton signal tu commences par récupérer un flux de bit en série. Pas un signal à 2^^16 niveaux (enfin là on serait de l'autre côté du dac...).
Le SRC dont on causait reçoit des bits en série et les traite en mots (comme dans word clock) de 16 bits.
JLM
en ce 28/03/2007 10:32, FiLH nous disait:
Ben oui mais bon sur ton signal tu commences par récupérer un
flux de bit en série. Pas un signal à 2^^16 niveaux (enfin
là on serait de l'autre côté du dac...).
Le SRC dont on causait reçoit des bits en série et les traite en mots
(comme dans word clock) de 16 bits.
Ben oui mais bon sur ton signal tu commences par récupérer un flux de bit en série. Pas un signal à 2^^16 niveaux (enfin là on serait de l'autre côté du dac...).
Le SRC dont on causait reçoit des bits en série et les traite en mots (comme dans word clock) de 16 bits.
JLM
shal
shal a écrit :
De mémoire, un paquet ethernet comme par un ensemble alterné de 0 et de 1 qui serve a synchronisé l'horloge pour la lecture des bits suivant. Codage Manchester aprés (1 veut dire changement d'état du bit et non bit 1)
Phrase illisible je corrige:
De mémoire, un paquet ethernet commence par un ensemble alterné de 0 et de 1 qui servent a synchroniser l'horloge pour la lecture des bits suivant. Codage Manchester aprés (1 veut dire changement d'état du bit et non bit 1)
shal a écrit :
De mémoire, un paquet ethernet comme par un ensemble alterné de 0 et de
1 qui serve a synchronisé l'horloge pour la lecture des bits suivant.
Codage Manchester aprés (1 veut dire changement d'état du bit et non bit 1)
Phrase illisible je corrige:
De mémoire, un paquet ethernet commence par un ensemble alterné de 0 et
de 1 qui servent a synchroniser l'horloge pour la lecture des bits
suivant. Codage Manchester aprés (1 veut dire changement d'état du bit
et non bit 1)
De mémoire, un paquet ethernet comme par un ensemble alterné de 0 et de 1 qui serve a synchronisé l'horloge pour la lecture des bits suivant. Codage Manchester aprés (1 veut dire changement d'état du bit et non bit 1)
Phrase illisible je corrige:
De mémoire, un paquet ethernet commence par un ensemble alterné de 0 et de 1 qui servent a synchroniser l'horloge pour la lecture des bits suivant. Codage Manchester aprés (1 veut dire changement d'état du bit et non bit 1)
FiLH
Jean-Louis Matrat writes:
en ce 28/03/2007 10:32, FiLH nous disait:
> Ben oui mais bon sur ton signal tu commences par récupérer un > flux de bit en série. Pas un signal à 2^^16 niveaux (enfin > là on serait de l'autre côté du dac...).
Le SRC dont on causait reçoit des bits en série et les traite en mots (comme dans word clock) de 16 bits.
Donc si je tâche de comprendre le phénomène de gigue tu le considérais par rapport au rythme de réception des mots, et non pas comme des erreurs d'échantillonage sur la réception des bits. Et donc l'erreur c'est plus sur le « rythme » de fonctionnement du DAC qui ne reçoit pas les données dans les temps que sur des erreurs de valeurs d'échantillonage.
C'est pas facile de comprendre des choses qui sont à la fois proche et éloignées de ce qu'on fait tous les jours.
FiLH qui se
-- FiLH photography. A taste of freedom in a conventional world. Web: http://www.filh.org e-mail FAQ fr.rec.photo : http://frp.parisv.com/ Sitafoto la photo a Bordeaux : http://sitafoto.free.fr/
> Ben oui mais bon sur ton signal tu commences par récupérer un
> flux de bit en série. Pas un signal à 2^^16 niveaux (enfin
> là on serait de l'autre côté du dac...).
Le SRC dont on causait reçoit des bits en série et les traite en
mots (comme dans word clock) de 16 bits.
Donc si je tâche de comprendre le phénomène de gigue tu le
considérais par rapport au rythme de réception des mots, et non
pas comme des erreurs d'échantillonage sur la réception des
bits. Et donc l'erreur c'est plus sur le « rythme » de
fonctionnement du DAC qui ne reçoit pas les données dans les
temps que sur des erreurs de valeurs d'échantillonage.
C'est pas facile de comprendre des choses qui sont à la fois proche
et éloignées de ce qu'on fait tous les jours.
FiLH qui se
--
FiLH photography. A taste of freedom in a conventional world.
Web: http://www.filh.org e-mail filh@filh.org
FAQ fr.rec.photo : http://frp.parisv.com/
Sitafoto la photo a Bordeaux : http://sitafoto.free.fr/
> Ben oui mais bon sur ton signal tu commences par récupérer un > flux de bit en série. Pas un signal à 2^^16 niveaux (enfin > là on serait de l'autre côté du dac...).
Le SRC dont on causait reçoit des bits en série et les traite en mots (comme dans word clock) de 16 bits.
Donc si je tâche de comprendre le phénomène de gigue tu le considérais par rapport au rythme de réception des mots, et non pas comme des erreurs d'échantillonage sur la réception des bits. Et donc l'erreur c'est plus sur le « rythme » de fonctionnement du DAC qui ne reçoit pas les données dans les temps que sur des erreurs de valeurs d'échantillonage.
C'est pas facile de comprendre des choses qui sont à la fois proche et éloignées de ce qu'on fait tous les jours.
FiLH qui se
-- FiLH photography. A taste of freedom in a conventional world. Web: http://www.filh.org e-mail FAQ fr.rec.photo : http://frp.parisv.com/ Sitafoto la photo a Bordeaux : http://sitafoto.free.fr/
