Décalage par rapport à l'appareil qui fait la lecture, ou décalage et bégaiement dans la lecture ?
Le premier est un problème de latence, et il est fréquent que vous ne vous en rendiez même pas compte, sauf lorsque vous utilisez la télécommande sur l'appareil qui envoie le signal, et que le téléviseur continue à décoder les données mises en mémoire tampon qu'il a déjà reçues, jusqu'à ce qu'il obtienne le signal d'arrêt.
Le correctif pour cela serait de mettre la gestion des appareils hors bande, et d'utiliser le contrôle de flux sur le flux ; la norme RTSP pour RealTime Streaming Protocol a cette capacité ; je suppose qu'AirPlay ne l'a pas (n'ayant pas regardé la spécification du protocole en détail), et qu'une seconde ou deux au plus dans un bouton de pause n'a pas été considérée comme un gros problème.
En revanche, si vous faites de la vidéo via AirPlay, et que vous lisez de l'audio directement à partir de l'ordinateur lui-même, vous pouvez vous attendre à ce que le décalage d'encodage/décodage pour le flux vidéo soit évident, et que les flux soient désynchronisés, parce que l'ordinateur n'a vraiment aucun moyen de savoir combien de temps le minuscule CPU de votre téléviseur va prendre pour décoder, ni la quantité de latence dans le pipeline de transmission, à part la latence dans le pipeline de décodage.
S'il s'agit d'un décalage audio vs vidéo, alors faites les deux lectures via le même appareil, et laissez-le gérer la synchronisation, au lieu d'attendre que les appareils se synchronisent de manière distribuée.
Note : L'une des publicités télévisées les plus percutantes que j'ai vues était une publicité pour le lecteur de musique Virgin, où l'on voyait une bande de gardes du palais utilisant l'appareil, et faisant tous des mouvements synchronisés sur la musique.
C'était percutant parce que ce n'était, bien sûr, pas possible.
C'était intéressant pour moi, parce que j'avais l'impression qu'il devrait être possible de le faire avec les iPhones et d'autres appareils.
J'ai même fait un logiciel de partage de temps de latence, tel que vous et quelqu'un d'autre sur une piste de danse pourriez avoir vos écouteurs, et un appareil pourrait être la lecture principale, et le(s) autre(s) appareil(s) pourraient être asservis, et le produit de retard de la bande passante calculé, de sorte qu'il serait possible de faire une "synchronisation de diffusion locale" comme ça.
Les écouteurs sans fil ont ruiné cela, mais j'ai effectivement écrit un logiciel prototype pour cela pour l'iPhone original, et j'avais une preuve de concept en cours d'exécution.
De la même manière que les appareils câblés vs non câblés vs. différentes marques de matériel de traitement audio après le point de décodage, sans retour d'information tout au long du pipeline rendent cette application impossible - il n'y a pas de retour d'information dans le pipeline depuis les appareils de lecture jusqu'à la source de transmission pour le décodage, pour permettre de synchroniser l'audio et la vidéo, lorsque la lecture ne se fait pas par les mêmes appareils, capables de mettre en œuvre ses propres barrières de synchronisation.
Cela ressemble juste à un mauvais film de "Théâtre de Kung Fu".