11-29-2016, 08:29 PM
Bonjour
Il y aurait un moyen simple, et déjà implémenté pour une autre fonction de Jriver, pour que la convolution DLNA fonctionne en gapless, mais je me suis un peu/beaucoup fritté avec l'un des participants au fil qui raconte souvent des énormités (du genre "un DSD 64 est exactement identique à un PCM 24/176"), ayant pourtant développé un petit serveur UPNP....
Si qqun veut poster là bas, pas de problème, inutile de me citer. Voilà l'analyse et la solution.
Le gapless ne dépend pas que du bon emploi du SetNextAVTransportURI bien employé par le renderer. Son buffer est nécessairement plus ou moins grand et jamais infini. Les latences réseau et les latences de calcul existent aussi, les processeurs n'ont pas une vitesse infinie.
Ce problème de latence de calcul existe aussi quand on veut envoyer une piste issue d'une image ISO SACD. L'extraction et la décompression d'une piste depuis une image ISO prend du temps et des ressources.
Le gapless des ISO SACD fonctionne pourtant en UPNP. J'avais suggéré il y a bien longtemps une manière de faire cela qui a été implémentée depuis.
Il faut que Jriver ait connaissance de la playlist. Cela peut donc ne pas fonctionner totalement avec des applications de contrôle uniquement UPNP comme bubbleupnp, mais cela fonctionne avec Jremote ou EOS qui sont des télécommandes de Jriver et pas des Control Point UPNP.
Quand Jriver voit qu'il a une playlist issue d'images ISO SACD, il traite 2 pistes en même temps, la première et la seconde, puis la troisième dès que la seconde a commencé à jouer, etc.
Il n'y a que pour la première piste qu'il y a un léger délai avant que cela ne commence à jouer.
Jriver "fabrique" la piste N (extraction de l'image ISO, décompression) et la piste N+1 en même temps et les met toutes les deux dans le dossier temporaire de Jriver.
La piste "suivante" demandée par le renderer est redirigée vers la piste N+1 qui est déjà prête dans le dossier temporaire. Il n'y a donc plus de latence supplémentaire liée à l'extraction/décompression ISO.
Il n'y a qu'un cas où ce procédé ne marche pas, c'est pour les albums qui ont une succession de pistes de quelques secondes, et où Jriver n'a pas le temps de préparer complètement la piste suivante pendant la lecture en cours de la piste. J'ai quelques albums de ce genre, mais depuis, j'ai pris le temps d'extraire les pistes de mes rips de SACD, et je n'utilise plus d'ISO.
Le même procédé devrait pourvoir être utilisé pour la convolution:
- fabrication des deux pistes convoluées N et N+1 en même temps, le démarrage de la piste N+1 utilisant directement la piste convoluée sans latence supplémentaire. La convolution de la piste N+2 démarrant alors.
Amitiés
Il y aurait un moyen simple, et déjà implémenté pour une autre fonction de Jriver, pour que la convolution DLNA fonctionne en gapless, mais je me suis un peu/beaucoup fritté avec l'un des participants au fil qui raconte souvent des énormités (du genre "un DSD 64 est exactement identique à un PCM 24/176"), ayant pourtant développé un petit serveur UPNP....
Si qqun veut poster là bas, pas de problème, inutile de me citer. Voilà l'analyse et la solution.
Le gapless ne dépend pas que du bon emploi du SetNextAVTransportURI bien employé par le renderer. Son buffer est nécessairement plus ou moins grand et jamais infini. Les latences réseau et les latences de calcul existent aussi, les processeurs n'ont pas une vitesse infinie.
Ce problème de latence de calcul existe aussi quand on veut envoyer une piste issue d'une image ISO SACD. L'extraction et la décompression d'une piste depuis une image ISO prend du temps et des ressources.
Le gapless des ISO SACD fonctionne pourtant en UPNP. J'avais suggéré il y a bien longtemps une manière de faire cela qui a été implémentée depuis.
Il faut que Jriver ait connaissance de la playlist. Cela peut donc ne pas fonctionner totalement avec des applications de contrôle uniquement UPNP comme bubbleupnp, mais cela fonctionne avec Jremote ou EOS qui sont des télécommandes de Jriver et pas des Control Point UPNP.
Quand Jriver voit qu'il a une playlist issue d'images ISO SACD, il traite 2 pistes en même temps, la première et la seconde, puis la troisième dès que la seconde a commencé à jouer, etc.
Il n'y a que pour la première piste qu'il y a un léger délai avant que cela ne commence à jouer.
Jriver "fabrique" la piste N (extraction de l'image ISO, décompression) et la piste N+1 en même temps et les met toutes les deux dans le dossier temporaire de Jriver.
La piste "suivante" demandée par le renderer est redirigée vers la piste N+1 qui est déjà prête dans le dossier temporaire. Il n'y a donc plus de latence supplémentaire liée à l'extraction/décompression ISO.
Il n'y a qu'un cas où ce procédé ne marche pas, c'est pour les albums qui ont une succession de pistes de quelques secondes, et où Jriver n'a pas le temps de préparer complètement la piste suivante pendant la lecture en cours de la piste. J'ai quelques albums de ce genre, mais depuis, j'ai pris le temps d'extraire les pistes de mes rips de SACD, et je n'utilise plus d'ISO.
Le même procédé devrait pourvoir être utilisé pour la convolution:
- fabrication des deux pistes convoluées N et N+1 en même temps, le démarrage de la piste N+1 utilisant directement la piste convoluée sans latence supplémentaire. La convolution de la piste N+2 démarrant alors.
Amitiés