Comment faire pour avoir sur Air play le son des trucs qu'on écoute sur
internet ?
Lorsque j'écoute de la musique sur iTunes, je la redirige sur des
haut-parleurs via Air play, ça baigne. Mais si je regarde une vidéo sur
le site de France-Inter, par exemple, je ne sais pas rediriger le son
vers Air play, et je dois l'écouter sur les hp de l'ordi. Y a-t-il une
solution ?
Pour la musique : iTunes -> SoundSticks USB /et/ iTunes -> Airport Express -> Ampli -> Cabasses
Pour la vidéo : image diffusée par Firefox, en ligne son diffusé par les SoundSticks = pas de retard son diffusé par les Cabasse via Airplay et borne Airport Express > retard 2 secondes.
C'est plus clair? :-)
En fait la différence c'est que dans un cas c'est AirTunes et dans l'autre c'est AirPlay, c'est ça ? Donc la différence c'est que AirPlay est censé diffuser de la video et pas uniquement de la musique (même là tu ne diffuses que le son), donc débit potentiel requis plus élevé, donc buffering plus important.
Le 27/01/2015 21:53, Le Moustique a écrit :
Pour la musique :
iTunes -> SoundSticks USB /et/
iTunes -> Airport Express -> Ampli -> Cabasses
Pour la vidéo :
image diffusée par Firefox, en ligne
son diffusé par les SoundSticks = pas de retard
son diffusé par les Cabasse via Airplay et borne Airport Express > retard 2 secondes.
C'est plus clair? :-)
En fait la différence c'est que dans un cas c'est AirTunes et dans
l'autre c'est AirPlay, c'est ça ? Donc la différence c'est que AirPlay
est censé diffuser de la video et pas uniquement de la musique (même là
tu ne diffuses que le son), donc débit potentiel requis plus élevé, donc
buffering plus important.
Pour la musique : iTunes -> SoundSticks USB /et/ iTunes -> Airport Express -> Ampli -> Cabasses
Pour la vidéo : image diffusée par Firefox, en ligne son diffusé par les SoundSticks = pas de retard son diffusé par les Cabasse via Airplay et borne Airport Express > retard 2 secondes.
C'est plus clair? :-)
En fait la différence c'est que dans un cas c'est AirTunes et dans l'autre c'est AirPlay, c'est ça ? Donc la différence c'est que AirPlay est censé diffuser de la video et pas uniquement de la musique (même là tu ne diffuses que le son), donc débit potentiel requis plus élevé, donc buffering plus important.
Le Moustique
Le 27/01/2015 22:00, pehache a écrit :
En fait la différence c'est que dans un cas c'est AirTunes et dans l'autre c'est AirPlay, c'est ça ? Donc la différence c'est que AirPlay est censé diffuser de la video et pas uniquement de la musique (même là tu ne diffuses que le son), donc débit potentiel requis plus élevé, donc buffering plus important.
Je n'en suis pas certain : après tout, iTunes est capable de lire une vidéo... mais je ne sais pas s'il envoie l'image et le son vers un périphérique adapté (Apple TV?), n'en possédant pas.
-- /) -:oo= Guillaume ) Je nettoyais mon clavier, et le coup est parti tout seul.
Le 27/01/2015 22:00, pehache a écrit :
En fait la différence c'est que dans un cas c'est AirTunes et dans
l'autre c'est AirPlay, c'est ça ? Donc la différence c'est que AirPlay
est censé diffuser de la video et pas uniquement de la musique (même là
tu ne diffuses que le son), donc débit potentiel requis plus élevé, donc
buffering plus important.
Je n'en suis pas certain : après tout, iTunes est capable de lire une
vidéo... mais je ne sais pas s'il envoie l'image et le son vers un
périphérique adapté (Apple TV?), n'en possédant pas.
--
/)
-:oo= Guillaume
)
Je nettoyais mon clavier, et le coup est parti tout seul.
En fait la différence c'est que dans un cas c'est AirTunes et dans l'autre c'est AirPlay, c'est ça ? Donc la différence c'est que AirPlay est censé diffuser de la video et pas uniquement de la musique (même là tu ne diffuses que le son), donc débit potentiel requis plus élevé, donc buffering plus important.
Je n'en suis pas certain : après tout, iTunes est capable de lire une vidéo... mais je ne sais pas s'il envoie l'image et le son vers un périphérique adapté (Apple TV?), n'en possédant pas.
-- /) -:oo= Guillaume ) Je nettoyais mon clavier, et le coup est parti tout seul.
pehache
Le 27/01/2015 21:31, Benoit a écrit :
Bernd wrote:
Tardigradus wrote:
Cela dit; il y a un problème : j'ai un décalage de plusieurs secondes entre le son et l'image, visiblement dû à la mise en tampon du son dans la Freebox. L'image démarre alors que le son n'a pas commencé, et impossible d'arriver à les remettre synchro, même en faisant pause ou en remettant le curseur au départ. Grrrr
De même gros décalage (plusieurs secondes) d'une émission sur un transistor et la même sur un récepteur internet. Sans doute pour la même raison que tu invoques.
Pareil si tu regardes la TV sur la Freebox ou la TNT ou (snif) le réseau hertzien anologique d'autrefois : tu as des décalages qui sont dus au fait que chaque canal a ses propres contraintes de stockages de données avant réémission pour assurer un flux continu. On n'est plus en flux tendu. Sans parler du temps que met chaque machine a processer le signal avant de l'envoyer au suivant. (les directs-live de plusieurs chaînes sur le même sujet sont flagrants, regarde l'interview du président ou ses v½ux pour Noël sur TF1 et sur Antenne2/France2 : jamais synchro et pourtant ce sont les mêmes caméras qui fournissent le même signal).
On n'est pas pas en TCP, mais en UDP. La différence entre les deux est que le premier émet et attend de s'assurer que l'autre a bien reçu les données avant de continuer (avec un délai d'attente qui permet de continuer d'envoyer au cas où et revenir en arrière pour renvoyer des données qui ne sont pas ou mal arrivées). Le second, lui par contre, se contrefout de ce que tu reçois, si tu le reçois ou non il continue d'avancer.
Résultat, en UDP tu mets en mémoire tampon un peu de film/son pour éviter les coupures
A priori c'est le contraire : vu qu'en TCP un paquet peut arriver très en retard par rapport aux autres (si il a été perdu puis renvoyé), le besoin de buffering est plus important.
En UDP moins besoin de bufferiser : un paquet qui n'arrive pas plus ou moins en même temps que les autres a toutes les chances de ne jamais arriver, donc inutile de l'attendre.
Cela dit; il y a un problème : j'ai un décalage de plusieurs secondes
entre le son et l'image, visiblement dû à la mise en tampon du son dans
la Freebox. L'image démarre alors que le son n'a pas commencé, et
impossible d'arriver à les remettre synchro, même en faisant pause ou en
remettant le curseur au départ. Grrrr
De même gros décalage (plusieurs secondes) d'une émission sur un
transistor et la même sur un récepteur internet. Sans doute pour la même
raison que tu invoques.
Pareil si tu regardes la TV sur la Freebox ou la TNT ou (snif) le
réseau hertzien anologique d'autrefois : tu as des décalages qui sont
dus au fait que chaque canal a ses propres contraintes de stockages de
données avant réémission pour assurer un flux continu. On n'est plus en
flux tendu. Sans parler du temps que met chaque machine a processer le
signal avant de l'envoyer au suivant. (les directs-live de plusieurs
chaînes sur le même sujet sont flagrants, regarde l'interview du
président ou ses v½ux pour Noël sur TF1 et sur Antenne2/France2 : jamais
synchro et pourtant ce sont les mêmes caméras qui fournissent le même
signal).
On n'est pas pas en TCP, mais en UDP. La différence entre les deux
est que le premier émet et attend de s'assurer que l'autre a bien reçu
les données avant de continuer (avec un délai d'attente qui permet de
continuer d'envoyer au cas où et revenir en arrière pour renvoyer des
données qui ne sont pas ou mal arrivées). Le second, lui par contre, se
contrefout de ce que tu reçois, si tu le reçois ou non il continue
d'avancer.
Résultat, en UDP tu mets en mémoire tampon un peu de film/son pour
éviter les coupures
A priori c'est le contraire : vu qu'en TCP un paquet peut arriver très
en retard par rapport aux autres (si il a été perdu puis renvoyé), le
besoin de buffering est plus important.
En UDP moins besoin de bufferiser : un paquet qui n'arrive pas plus ou
moins en même temps que les autres a toutes les chances de ne jamais
arriver, donc inutile de l'attendre.
Cela dit; il y a un problème : j'ai un décalage de plusieurs secondes entre le son et l'image, visiblement dû à la mise en tampon du son dans la Freebox. L'image démarre alors que le son n'a pas commencé, et impossible d'arriver à les remettre synchro, même en faisant pause ou en remettant le curseur au départ. Grrrr
De même gros décalage (plusieurs secondes) d'une émission sur un transistor et la même sur un récepteur internet. Sans doute pour la même raison que tu invoques.
Pareil si tu regardes la TV sur la Freebox ou la TNT ou (snif) le réseau hertzien anologique d'autrefois : tu as des décalages qui sont dus au fait que chaque canal a ses propres contraintes de stockages de données avant réémission pour assurer un flux continu. On n'est plus en flux tendu. Sans parler du temps que met chaque machine a processer le signal avant de l'envoyer au suivant. (les directs-live de plusieurs chaînes sur le même sujet sont flagrants, regarde l'interview du président ou ses v½ux pour Noël sur TF1 et sur Antenne2/France2 : jamais synchro et pourtant ce sont les mêmes caméras qui fournissent le même signal).
On n'est pas pas en TCP, mais en UDP. La différence entre les deux est que le premier émet et attend de s'assurer que l'autre a bien reçu les données avant de continuer (avec un délai d'attente qui permet de continuer d'envoyer au cas où et revenir en arrière pour renvoyer des données qui ne sont pas ou mal arrivées). Le second, lui par contre, se contrefout de ce que tu reçois, si tu le reçois ou non il continue d'avancer.
Résultat, en UDP tu mets en mémoire tampon un peu de film/son pour éviter les coupures
A priori c'est le contraire : vu qu'en TCP un paquet peut arriver très en retard par rapport aux autres (si il a été perdu puis renvoyé), le besoin de buffering est plus important.
En UDP moins besoin de bufferiser : un paquet qui n'arrive pas plus ou moins en même temps que les autres a toutes les chances de ne jamais arriver, donc inutile de l'attendre.
pehache
Le 27/01/2015 22:03, Le Moustique a écrit :
Le 27/01/2015 22:00, pehache a écrit :
En fait la différence c'est que dans un cas c'est AirTunes et dans l'autre c'est AirPlay, c'est ça ? Donc la différence c'est que AirPlay est censé diffuser de la video et pas uniquement de la musique (même là tu ne diffuses que le son), donc débit potentiel requis plus élevé, donc buffering plus important.
Je n'en suis pas certain : après tout, iTunes est capable de lire une vidéo... mais je ne sais pas s'il envoie l'image et le son vers un périphérique adapté (Apple TV?), n'en possédant pas.
Tout ça n'est pas très clair, mais à la base AirTunes c'est du son uniquement. Et c'est uniquement iTunes qui peut envoyer de l'AirTunes.
Le 27/01/2015 22:03, Le Moustique a écrit :
Le 27/01/2015 22:00, pehache a écrit :
En fait la différence c'est que dans un cas c'est AirTunes et dans
l'autre c'est AirPlay, c'est ça ? Donc la différence c'est que AirPlay
est censé diffuser de la video et pas uniquement de la musique (même là
tu ne diffuses que le son), donc débit potentiel requis plus élevé, donc
buffering plus important.
Je n'en suis pas certain : après tout, iTunes est capable de lire une
vidéo... mais je ne sais pas s'il envoie l'image et le son vers un
périphérique adapté (Apple TV?), n'en possédant pas.
Tout ça n'est pas très clair, mais à la base AirTunes c'est du son
uniquement. Et c'est uniquement iTunes qui peut envoyer de l'AirTunes.
En fait la différence c'est que dans un cas c'est AirTunes et dans l'autre c'est AirPlay, c'est ça ? Donc la différence c'est que AirPlay est censé diffuser de la video et pas uniquement de la musique (même là tu ne diffuses que le son), donc débit potentiel requis plus élevé, donc buffering plus important.
Je n'en suis pas certain : après tout, iTunes est capable de lire une vidéo... mais je ne sais pas s'il envoie l'image et le son vers un périphérique adapté (Apple TV?), n'en possédant pas.
Tout ça n'est pas très clair, mais à la base AirTunes c'est du son uniquement. Et c'est uniquement iTunes qui peut envoyer de l'AirTunes.
pehache
Le 27/01/2015 21:59, Le Moustique a écrit :
Le 27/01/2015 21:23, pehache a écrit :
Euh, pourquoi ça passe par Wifi ou par filaire suivant le logiciel utilisé ?
Ca, je suis incapable de le préciser. Je sais que iTunes envoie la musique en filaire (via le réseau gigabit de la maison) vers la borne, parce que si je débranche le câble éthernet le son est coupé (avec une ou deux secondes de délai, la borne semblant faire tampon).
Remarque annexe : si la borne bufferise le son, comment se fait-il qu'il n'y ait aucun décalage avec les soundsticks en direct sur le Mac ?
(je me réponds à moi-même : peut-être parce que iTunes retarde volontairement le son envoyé sur les soundstick en tenant compte du décalage son de la borne...)
Par contre je ne sais pas si AirPlay fonctionne de la même manière... Logiquement, avec le nom qu'il porte, ça devrait être en wifi.
AirPlay utilise le réseau local disponible pour communiquer entre l'émetteur et le récepteur, quel qu'il soit : wifi, ethernet... Il existe d'ailleurs des équipements compatibles AirPlay qui ne se branchent qu'en ethernet.
Le 27/01/2015 21:59, Le Moustique a écrit :
Le 27/01/2015 21:23, pehache a écrit :
Euh, pourquoi ça passe par Wifi ou par filaire suivant le logiciel
utilisé ?
Ca, je suis incapable de le préciser.
Je sais que iTunes envoie la musique en filaire (via le réseau gigabit
de la maison) vers la borne, parce que si je débranche le câble éthernet
le son est coupé (avec une ou deux secondes de délai, la borne semblant
faire tampon).
Remarque annexe : si la borne bufferise le son, comment se fait-il qu'il
n'y ait aucun décalage avec les soundsticks en direct sur le Mac ?
(je me réponds à moi-même : peut-être parce que iTunes retarde
volontairement le son envoyé sur les soundstick en tenant compte du
décalage son de la borne...)
Par contre je ne sais pas si AirPlay fonctionne de la même manière...
Logiquement, avec le nom qu'il porte, ça devrait être en wifi.
AirPlay utilise le réseau local disponible pour communiquer entre
l'émetteur et le récepteur, quel qu'il soit : wifi, ethernet... Il
existe d'ailleurs des équipements compatibles AirPlay qui ne se
branchent qu'en ethernet.
Euh, pourquoi ça passe par Wifi ou par filaire suivant le logiciel utilisé ?
Ca, je suis incapable de le préciser. Je sais que iTunes envoie la musique en filaire (via le réseau gigabit de la maison) vers la borne, parce que si je débranche le câble éthernet le son est coupé (avec une ou deux secondes de délai, la borne semblant faire tampon).
Remarque annexe : si la borne bufferise le son, comment se fait-il qu'il n'y ait aucun décalage avec les soundsticks en direct sur le Mac ?
(je me réponds à moi-même : peut-être parce que iTunes retarde volontairement le son envoyé sur les soundstick en tenant compte du décalage son de la borne...)
Par contre je ne sais pas si AirPlay fonctionne de la même manière... Logiquement, avec le nom qu'il porte, ça devrait être en wifi.
AirPlay utilise le réseau local disponible pour communiquer entre l'émetteur et le récepteur, quel qu'il soit : wifi, ethernet... Il existe d'ailleurs des équipements compatibles AirPlay qui ne se branchent qu'en ethernet.
benoit
pehache wrote:
A priori c'est le contraire : vu qu'en TCP un paquet peut arriver très en retard par rapport aux autres (si il a été perdu puis renvoyé), le besoin de buffering est plus important.
En UDP moins besoin de bufferiser : un paquet qui n'arrive pas plus ou moins en même temps que les autres a toutes les chances de ne jamais arriver, donc inutile de l'attendre.
Bin si, tu bufferises parce que tu sais que tu reçois du signal de qualité variable (une compression qui fait que s'il te manque des bouts, il ne te manque pas un morceau de l'image mais une image de moindre qualité) tu mets donc en stock et tu attends de recevoir pas mal de paquets avant de l'afficher.
Ensuite, les paquets n'arrivent pas obligatoirement dans le bon ordre, tu dois donc avoir un stock pour mettre tout ça au carré avant de l'envoyer à l'écran ou au haut-parleur.
-- "La théorie, c'est quand on sait tout et que rien ne fonctionne. La pratique, c'est quand tout fonctionne et que personne ne sait pourquoi. Ici, nous avons réuni théorie et pratique : Rien ne fonctionne... et personne ne sait pourquoi !" [ Albert Einstein ]
pehache <pehache.7@gmail.com> wrote:
A priori c'est le contraire : vu qu'en TCP un paquet peut arriver très
en retard par rapport aux autres (si il a été perdu puis renvoyé), le
besoin de buffering est plus important.
En UDP moins besoin de bufferiser : un paquet qui n'arrive pas plus ou
moins en même temps que les autres a toutes les chances de ne jamais
arriver, donc inutile de l'attendre.
Bin si, tu bufferises parce que tu sais que tu reçois du signal de
qualité variable (une compression qui fait que s'il te manque des bouts,
il ne te manque pas un morceau de l'image mais une image de moindre
qualité) tu mets donc en stock et tu attends de recevoir pas mal de
paquets avant de l'afficher.
Ensuite, les paquets n'arrivent pas obligatoirement dans le bon
ordre, tu dois donc avoir un stock pour mettre tout ça au carré avant de
l'envoyer à l'écran ou au haut-parleur.
--
"La théorie, c'est quand on sait tout et que rien ne fonctionne. La
pratique, c'est quand tout fonctionne et que personne ne sait pourquoi.
Ici, nous avons réuni théorie et pratique : Rien ne fonctionne... et
personne ne sait pourquoi !" [ Albert Einstein ]
A priori c'est le contraire : vu qu'en TCP un paquet peut arriver très en retard par rapport aux autres (si il a été perdu puis renvoyé), le besoin de buffering est plus important.
En UDP moins besoin de bufferiser : un paquet qui n'arrive pas plus ou moins en même temps que les autres a toutes les chances de ne jamais arriver, donc inutile de l'attendre.
Bin si, tu bufferises parce que tu sais que tu reçois du signal de qualité variable (une compression qui fait que s'il te manque des bouts, il ne te manque pas un morceau de l'image mais une image de moindre qualité) tu mets donc en stock et tu attends de recevoir pas mal de paquets avant de l'afficher.
Ensuite, les paquets n'arrivent pas obligatoirement dans le bon ordre, tu dois donc avoir un stock pour mettre tout ça au carré avant de l'envoyer à l'écran ou au haut-parleur.
-- "La théorie, c'est quand on sait tout et que rien ne fonctionne. La pratique, c'est quand tout fonctionne et que personne ne sait pourquoi. Ici, nous avons réuni théorie et pratique : Rien ne fonctionne... et personne ne sait pourquoi !" [ Albert Einstein ]
benoit
pehache wrote:
Remarque annexe : si la borne bufferise le son, comment se fait-il qu'il n'y ait aucun décalage avec les soundsticks en direct sur le Mac ?
(je me réponds à moi-même : peut-être parce que iTunes retarde volontairement le son envoyé sur les soundstick en tenant compte du décalage son de la borne...)
Oui. Et je pense qu'iTunes reçoit de l'info en retour pour synchroniser. Quand le sans-fil a démarré iTunes ne savait fonctionner, de mémoire, qu'avec une paire d'enceintes, si on en mettait une seconde paire ailleurs on avait de l'écho et un son asynchrone entre les différentes pièces. Ça a été « corrigé », mais il est vrai qu'au début ce n'était pas prévu pour sonoriser une grande surface (dans tous les sens du terme), mais une pièce.
Ce n'est pas lui qui retarde le son mais lui qui envoie les données aux enceintes en buffer et ensuite leur dit de démarrer en même temps. Si une reçoit des paquets un peu tard elle a de quoi continuer en synchro.
Si on reste sur le son : tu as du mp3 en 256 Ko/s et un réseau wifi qui fait des dizaines de Mo/s. Tu peux donc imaginer d'envoyer un morceau en entier à tout le monde et ensuite un top départ toutes les secondes. Si les machines ont une montre assez précise et synchronisée, tout roule. Si les machines émettent immédiatement ce qu'elles recoivent avec des trous... c'est moyen.
-- "La théorie, c'est quand on sait tout et que rien ne fonctionne. La pratique, c'est quand tout fonctionne et que personne ne sait pourquoi. Ici, nous avons réuni théorie et pratique : Rien ne fonctionne... et personne ne sait pourquoi !" [ Albert Einstein ]
pehache <pehache.7@gmail.com> wrote:
Remarque annexe : si la borne bufferise le son, comment se fait-il qu'il
n'y ait aucun décalage avec les soundsticks en direct sur le Mac ?
(je me réponds à moi-même : peut-être parce que iTunes retarde
volontairement le son envoyé sur les soundstick en tenant compte du
décalage son de la borne...)
Oui. Et je pense qu'iTunes reçoit de l'info en retour pour
synchroniser. Quand le sans-fil a démarré iTunes ne savait fonctionner,
de mémoire, qu'avec une paire d'enceintes, si on en mettait une seconde
paire ailleurs on avait de l'écho et un son asynchrone entre les
différentes pièces. Ça a été « corrigé », mais il est vrai qu'au début
ce n'était pas prévu pour sonoriser une grande surface (dans tous les
sens du terme), mais une pièce.
Ce n'est pas lui qui retarde le son mais lui qui envoie les données
aux enceintes en buffer et ensuite leur dit de démarrer en même temps.
Si une reçoit des paquets un peu tard elle a de quoi continuer en
synchro.
Si on reste sur le son : tu as du mp3 en 256 Ko/s et un réseau wifi
qui fait des dizaines de Mo/s. Tu peux donc imaginer d'envoyer un
morceau en entier à tout le monde et ensuite un top départ toutes les
secondes. Si les machines ont une montre assez précise et synchronisée,
tout roule. Si les machines émettent immédiatement ce qu'elles recoivent
avec des trous... c'est moyen.
--
"La théorie, c'est quand on sait tout et que rien ne fonctionne. La
pratique, c'est quand tout fonctionne et que personne ne sait pourquoi.
Ici, nous avons réuni théorie et pratique : Rien ne fonctionne... et
personne ne sait pourquoi !" [ Albert Einstein ]
Remarque annexe : si la borne bufferise le son, comment se fait-il qu'il n'y ait aucun décalage avec les soundsticks en direct sur le Mac ?
(je me réponds à moi-même : peut-être parce que iTunes retarde volontairement le son envoyé sur les soundstick en tenant compte du décalage son de la borne...)
Oui. Et je pense qu'iTunes reçoit de l'info en retour pour synchroniser. Quand le sans-fil a démarré iTunes ne savait fonctionner, de mémoire, qu'avec une paire d'enceintes, si on en mettait une seconde paire ailleurs on avait de l'écho et un son asynchrone entre les différentes pièces. Ça a été « corrigé », mais il est vrai qu'au début ce n'était pas prévu pour sonoriser une grande surface (dans tous les sens du terme), mais une pièce.
Ce n'est pas lui qui retarde le son mais lui qui envoie les données aux enceintes en buffer et ensuite leur dit de démarrer en même temps. Si une reçoit des paquets un peu tard elle a de quoi continuer en synchro.
Si on reste sur le son : tu as du mp3 en 256 Ko/s et un réseau wifi qui fait des dizaines de Mo/s. Tu peux donc imaginer d'envoyer un morceau en entier à tout le monde et ensuite un top départ toutes les secondes. Si les machines ont une montre assez précise et synchronisée, tout roule. Si les machines émettent immédiatement ce qu'elles recoivent avec des trous... c'est moyen.
-- "La théorie, c'est quand on sait tout et que rien ne fonctionne. La pratique, c'est quand tout fonctionne et que personne ne sait pourquoi. Ici, nous avons réuni théorie et pratique : Rien ne fonctionne... et personne ne sait pourquoi !" [ Albert Einstein ]
voir_le_reply-to
pehache wrote:
Tout ça n'est pas très clair, mais à la base AirTunes c'est du son uniquement.
C'est inexact : iTunes permet de diffuser des vidéos (onglets "Films", "Séries TV", "Podcasts"(vidéos))... et même d'en acheter, incluant des "clips"!
Et je confirme que, sans problème lié au téléviseur éventuellement asthmatique (que j'ai décris), les diffusions iTunes sont parfaitement synchrones... allant jusqu'à retarder significativement le début de diffusion sur l'ordi lui-même si on choisit "hauts-parleurs multiples" dans le menu local situé à droite du curseur de volume dans la barre du haut (je pense qu'il n'apparaît que si on dispose d'une solution de diffusion Airplay), pour que les points de diffusion soient tous synchrones (et d'ailleurs, selon moi, il manque la possibilité d'insérer un "retard" pour les diffusions en grands espaces !) -- Gérald
pehache <pehache.7@gmail.com> wrote:
Tout ça n'est pas très clair, mais à la base AirTunes c'est du son
uniquement.
C'est inexact : iTunes permet de diffuser des vidéos (onglets "Films",
"Séries TV", "Podcasts"(vidéos))... et même d'en acheter, incluant des
"clips"!
Et je confirme que, sans problème lié au téléviseur éventuellement
asthmatique (que j'ai décris), les diffusions iTunes sont parfaitement
synchrones... allant jusqu'à retarder significativement le début de
diffusion sur l'ordi lui-même si on choisit "hauts-parleurs multiples"
dans le menu local situé à droite du curseur de volume dans la barre du
haut (je pense qu'il n'apparaît que si on dispose d'une solution de
diffusion Airplay), pour que les points de diffusion soient tous
synchrones (et d'ailleurs, selon moi, il manque la possibilité d'insérer
un "retard" pour les diffusions en grands espaces !)
--
Gérald
Tout ça n'est pas très clair, mais à la base AirTunes c'est du son uniquement.
C'est inexact : iTunes permet de diffuser des vidéos (onglets "Films", "Séries TV", "Podcasts"(vidéos))... et même d'en acheter, incluant des "clips"!
Et je confirme que, sans problème lié au téléviseur éventuellement asthmatique (que j'ai décris), les diffusions iTunes sont parfaitement synchrones... allant jusqu'à retarder significativement le début de diffusion sur l'ordi lui-même si on choisit "hauts-parleurs multiples" dans le menu local situé à droite du curseur de volume dans la barre du haut (je pense qu'il n'apparaît que si on dispose d'une solution de diffusion Airplay), pour que les points de diffusion soient tous synchrones (et d'ailleurs, selon moi, il manque la possibilité d'insérer un "retard" pour les diffusions en grands espaces !) -- Gérald
voir_le_reply-to
pehache wrote:
Remarque annexe : si la borne bufferise le son, comment se fait-il qu'il n'y ait aucun décalage avec les soundsticks en direct sur le Mac ?
(je me réponds à moi-même : peut-être parce que iTunes retarde volontairement le son envoyé sur les soundstick en tenant compte du décalage son de la borne...)
Oui, déjà répondu à pehache : si tu choisis "haut-parleurs multiples" dans iTunes, tu constateras que le le début de lecture est retardé de 2 secondes environ pour permettre cette synchronisation. C'est bien fichu.
-- Gérald
pehache <pehache.7@gmail.com> wrote:
Remarque annexe : si la borne bufferise le son, comment se fait-il qu'il
n'y ait aucun décalage avec les soundsticks en direct sur le Mac ?
(je me réponds à moi-même : peut-être parce que iTunes retarde
volontairement le son envoyé sur les soundstick en tenant compte du
décalage son de la borne...)
Oui, déjà répondu à pehache : si tu choisis "haut-parleurs multiples"
dans iTunes, tu constateras que le le début de lecture est retardé de 2
secondes environ pour permettre cette synchronisation. C'est bien fichu.
Remarque annexe : si la borne bufferise le son, comment se fait-il qu'il n'y ait aucun décalage avec les soundsticks en direct sur le Mac ?
(je me réponds à moi-même : peut-être parce que iTunes retarde volontairement le son envoyé sur les soundstick en tenant compte du décalage son de la borne...)
Oui, déjà répondu à pehache : si tu choisis "haut-parleurs multiples" dans iTunes, tu constateras que le le début de lecture est retardé de 2 secondes environ pour permettre cette synchronisation. C'est bien fichu.
-- Gérald
voir_le_reply-to
Le Moustique wrote:
Comme je le précisais, pas de décalage de son (en audio, sans vidéo) entre le signal envoyé par iTunes à la borne Airport et celui diffusé par les SoundSticks USB. Diffusion simultanée, et le son délivré par les Cabasse d'un côté, les SoundSticks de l'autre (plus "ronds", moelleux) est tout à fait agréable à entendre. :-)
Ah, le moelleux ! J'aime le moelleux ! Mais je n'ai pas le droit, pour moi c'est MAL ! (pour de la création sonore il faut le son le plus "droit" possible).
Là, je constatais la différence entre le son d'une vidéo (lue sur Firefox) diffusé soit par les SoundSticks (pas de "lag"), soit par les Cabasse via la borne Airport Express : là, un net décalage (entre 1 et 2 secondes, pas plus) entre les paroles et les mouvements des lèvres.
mmm... je me demande ce que ça donnerait avec Safari (qui utilise QuickTime pour la diffusion, compatible Airplay). Une différence de comportement signerait la source du problème.
hth,
-- Gérald
Le Moustique <ze.mosquito@free.fr> wrote:
Comme je le précisais, pas de décalage de son (en audio, sans vidéo)
entre le signal envoyé par iTunes à la borne Airport et celui diffusé
par les SoundSticks USB. Diffusion simultanée, et le son délivré par les
Cabasse d'un côté, les SoundSticks de l'autre (plus "ronds", moelleux)
est tout à fait agréable à entendre. :-)
Ah, le moelleux ! J'aime le moelleux ! Mais je n'ai pas le droit, pour
moi c'est MAL ! (pour de la création sonore il faut le son le plus
"droit" possible).
Là, je constatais la différence entre le son d'une vidéo (lue sur
Firefox) diffusé soit par les SoundSticks (pas de "lag"), soit par les
Cabasse via la borne Airport Express : là, un net décalage (entre 1 et
2 secondes, pas plus) entre les paroles et les mouvements des lèvres.
mmm... je me demande ce que ça donnerait avec Safari (qui utilise
QuickTime pour la diffusion, compatible Airplay). Une différence de
comportement signerait la source du problème.
Comme je le précisais, pas de décalage de son (en audio, sans vidéo) entre le signal envoyé par iTunes à la borne Airport et celui diffusé par les SoundSticks USB. Diffusion simultanée, et le son délivré par les Cabasse d'un côté, les SoundSticks de l'autre (plus "ronds", moelleux) est tout à fait agréable à entendre. :-)
Ah, le moelleux ! J'aime le moelleux ! Mais je n'ai pas le droit, pour moi c'est MAL ! (pour de la création sonore il faut le son le plus "droit" possible).
Là, je constatais la différence entre le son d'une vidéo (lue sur Firefox) diffusé soit par les SoundSticks (pas de "lag"), soit par les Cabasse via la borne Airport Express : là, un net décalage (entre 1 et 2 secondes, pas plus) entre les paroles et les mouvements des lèvres.
mmm... je me demande ce que ça donnerait avec Safari (qui utilise QuickTime pour la diffusion, compatible Airplay). Une différence de comportement signerait la source du problème.
