Les vraies raisons pour lesquelles Roon ne veut pas implémenter UPnP:
- ils ne l'ont pas inventé donc considèrent que c'est pourri. Un syndrôme bien connu
- il veulent pousser RAAT, leur protocole propriétaire. Si Roon supportait UPnP,
les constructeurs de hardware ne veraient pas grand intérêt à supporter RAAT
Dans la position de Roon sur UPnP il y a un peu de vrai, et pas mal de bullshit.
C'est un peu idiot de ne pas supporter UPnP car ils se coupent de millions de players (end-point) potentiels existants et d'autant de clients éventuels. Et ce n'est même pas difficile, en considerant un renderer UPnP juste comme un bête périphérique jouant un flux PCM (WAV ou LCPM) continu alimenté par Roon (plutôt que d'envoyer chaque piste séparement en laissant la redender faire le décodage, ce qui est nettement plus ardu).
Roon est un produit intéressant pour un certain type d'utilisateurs, mais vraiment de niche à cause du prix de la souscription.
Et le fait que RAAT est un protocole des plus fermés n'améliore pas vraiment les choses.
Je leur souhaite bien du bonheur dans leur negociations avec les centaines de constructeurs de hardware.
Bonjour et bienvenue Bubbie
Content de ta participation à ce forum.
Ce que je n'ai jamais très bien saisi en terme de stratégie, c'est d'un côté un positionnement utilisateur "IHM, contenu, intégration" et de l'autre un protocole audio, l'un et l'autre n'ayant pourtant aucun recouvrement, ni logiciel, ni fonctionnel.
Affirmer et faire croire aux utilisateurs que l'un est tributaire de l'autre est assez olé olé pour rester poli.
Amitiés
(03-06-2016, 03:23 PM)Patatorz a écrit : [ -> ]Vu de chez moi linn et ses concurrents ont tout intérêt dans la limite de la possibilité d'évolution hard et soft, de proposer un max de compatibilité. Auralic l'a déjà fait, Totaldac également (sur base Linux avec support MPD et LMS ca doit aider). C'est apparemment plus compliqué pour d'autres tels que Lumin ou belcanto (refstream pas compatible sauf évolution hardware) qui soit ne maîtrise tes leurs codes (belcanto est encore oem chez engineered) soit parce que le hard ne le permet pas.
Je suis d'accord avec ton analyse.
Je soulignais simplement que LINN étant un des promoteurs du consortium OPEN HOME (surcouche d'UPNP qui règle quelques problèmes majeurs genre lecture gapless et gestion locale des playlists) ils ont sans doute plus de mal à adopter RAAT qui est, dans un certain sens concurrent. Ceci dit ils y viendront peut être si le marché les pousse à cela.
(03-06-2016, 03:23 PM)Patatorz a écrit : [ -> ]Ce que j'ai du mal à comprendre c'est le lien entre songcast et roon : je vais me plonger dans ton lien.
Songcast est aussi supporté par LINN et a une architecture différente de celle d'UPnP plus proche de l'approche de RoonLabs.
Initialement, à sa sortie, ROON pouvait utiliser ce protocole pour streamer vers les players LINN. Apparemment ils ont des problèmes de stabilité et, classiquement, se renvoient la balle avec LINN sur qui doit régler quoi. Il y a un fil la dessus sur le forum de la communauté LINN avec les mêmes arguments pro et anti Roon que ceux que nous débattons:
http://forums.linn.co.uk/bb/showthread.php?tid=30334
(03-06-2016, 03:56 PM)bubbleguuum a écrit : [ -> ]Les vraies raisons pour lesquelles Roon ne veut pas implémenter UPnP:
- ils ne l'ont pas inventé donc considèrent que c'est pourri. Un syndrôme bien connu
- il veulent pousser RAAT, leur protocole propriétaire. Si Roon supportait UPnP,
les constructeurs de hardware ne veraient pas grand intérêt à supporter RAAT
Bonjour,
Super d'avoir ici quelqu'un qui maîtrise bien les protocoles, sait de quoi il parle et "sauve la mise" à pas mal d'utilisateurs avec BubbleUPNP server.
Ce que tu pointes n'est sans doute pas faux, mais leur positionnement étant de construire un nouvel ecosystème dédié à l'audio plutôt "haut de gamme" mais trés robuste et simple à mettre en oeuvre et à utiliser ce n'est pas illogique qu'ils aient cette position de vouloir maitriser le protocole et certifier les endpoints RoonReady versus le coté parfois très hétérogène, voir hétéroclite de certaines solutions concurrentes qui nécessite parfois de mettre un peu les mains dans le cambouis.
Que cela ne soit pas gagné d'avance d'imposer un nouveau protocole propriétaire est aussi vrai, je te rejoins la dessus.
Ceci dit ils ne semblent pas si mal accueillis par les fabricants audio, Je ne pense pas qu'ils demandent de royalties pour l'instant car ils doivent élargir leur parc de endpoints rapidement et voient les constructeurs comme des partenaires.
Avec le streaming l'environnement évolue très rapidement. L'avenir dira s'ils survivent et prospèrent mais pour moi c'est une boite sérieuse qui porte une vision que je trouve positive.
(03-06-2016, 03:56 PM)bubbleguuum a écrit : [ -> ]Dans la position de Roon sur UPnP il y a un peu de vrai, et pas mal de bullshit.
C'est un peu idiot de ne pas supporter UPnP car ils se coupent de millions de players (end-point) potentiels existants et d'autant de clients éventuels. Et ce n'est même pas difficile, en considérant un renderer UPnP juste comme un bête périphérique jouant un flux PCM (WAV ou LCPM) continu alimenté par Roon (plutôt que d'envoyer chaque piste séparément en laissant la redender faire le décodage, ce qui est nettement plus ardu).
Roon est un produit intéressant pour un certain type d'utilisateurs, mais vraiment de niche à cause du prix de la souscription.
Et le fait que RAAT est un protocole des plus fermés n'améliore pas vraiment les choses.
Je leur souhaite bien du bonheur dans leur négociations avec les centaines de constructeurs de hardware.
Pour les anglophones, le CTO de RoonLabs, détaille leur position vis à vis d'UPnP dans ce post:
https://community.roonlabs.com/t/roon-ra...np-av/8542
@bubbleguuum Brian Luczkiewicz évoque d'ailleurs la solution que tu préconises ici pour assurer une compatibilité UPnP basic.
(03-09-2016, 09:57 AM)volpone75 a écrit : [ -> ]Songcast est aussi supporté par LINN et a une architecture différente de celle d'UPnP plus proche de l'approche de RoonLabs.
Songcast est comparable à AirPlay mais supportant jusqu'a 192 kHz / 24 bit et le multiroom parfairtement synchronisé (AirPlay aussi). Et surtout Songcast est Open Source, comme presque tout ce que fait Linn. N'importe quel constructeur ou developeur est libre implementer Songcast dans son produit, sans avoir besoin de demander l'autorisation à Linn ou une quelconque certification (comme RAAT).
En fait, Linn et Roon ont deux philosophies de developement entièrement opposées:
- Linn promeut en encourage un ecosystème multi-vendeur ouvert, en publiant des specs (OpenHome, Songcast) et le code Open Source ad-hoc. C'est pour cela que BubbleUPnP Server, Lumin (l'appli), upmpdcli, probablement MinimServer (indirectement) et d'autres existent. Que Kazoo et Lumin peuvent causer à des renderers qui ne sont pas des Linn DS ou Lumin (le hardware) respectivement. Il viennent meme de publier un renderer OpenHome soft (ohPlayer) qui tourne a peut prêt partout. Et avec le code source, pas moins.
- RoonLabs veut tout contrôler de bout en bout: le control point (l'appli Roon), le renderer RAAT qui doit etre certifié par eux, les protocoles propriétaires.
Lumin, d'habitude très rapide pour offrir une fonctionnalité promise (Tidal, Quobuz, Tunein,..) n'a toujours rien pour Roon alors que c'est annoncé par Roon depuis fin 2015 ..
(03-09-2016, 02:16 PM)bubbleguuum a écrit : [ -> ] (03-09-2016, 09:57 AM)volpone75 a écrit : [ -> ]Songcast est aussi supporté par LINN et a une architecture différente de celle d'UPnP plus proche de l'approche de RoonLabs.
Songcast est comparable à AirPlay mais supportant jusqu'a 192 kHz / 24 bit et le multiroom parfairtement synchronisé (AirPlay aussi). Et surtout Songcast est Open Source, comme presque tout ce que fait Linn. N'importe quel constructeur ou developeur est libre implementer Songcast dans son produit, sans avoir besoin de demander l'autorisation à Linn ou une quelconque certification (comme RAAT).
En fait, Linn et Roon ont deux philosophies de developement entièrement opposées:
- Linn promeut en encourage un ecosystème multi-vendeur ouvert, en publiant des specs (OpenHome, Songcast) et le code Open Source ad-hoc. C'est pour cela que BubbleUPnP Server, Lumin (l'appli), upmpdcli, probablement MinimServer (indirectement) et d'autres existent. Que Kazoo et Lumin peuvent causer à des renderers qui ne sont pas des Linn DS ou Lumin (le hardware) respectivement. Il viennent meme de publier un renderer OpenHome soft (ohPlayer) qui tourne a peut prêt partout. Et avec le code source, pas moins.
- RoonLabs veut tout contrôler de bout en bout: le control point (l'appli Roon), le renderer RAAT qui doit etre certifié par eux, les protocoles propriétaires.
Oui, effectivement, on peut voir ça comme cela mais chacun à ses raisons en fonction de son coeur de métier. Celles de Roon ne me semblent pas mauvaises vu du coté de l'utilisateur final exigeant qui veut avoir le confort d'un bon système robuste facile à installer et à utiliser tout en ayant le choix des composants audio si l'offre de endpoints RoonReady se généralise ce qui semble s'amorcer au moins pour le "haut de gamme".
Par ailleurs je comprends très bien que l'on puisse préférer des standards ouverts et des softs gratuits ou financés par les constructeurs. Reste que l
'architecture centralisée de Roon telle décrite ici à des avantages et pour l'instant je n'ai vu aucun système UPnP proposant le même degré d'intégration, de facilité de mise en oeuvre et d'utilisation. Je suis néanmoins d'accord avec toi sur le fait que c'est un marché de niche, reste à savoir la taille de la niche
Pour ma part consacrer moins de 5% du budget de mon système au logiciel ne me semble pas aberrant surtout dans le cadre d'une utilisation réseau multiroom "familiale" avec un (et j'espère bientôt des) service de streaming en ligne bien intégrés.
(03-04-2016, 06:00 PM)volpone75 a écrit : [ -> ]Paradoxalement la très complète intégration de TIDAL dans Roon met la barre très haut et doit rendre difficile celle de QOBUz pour des raisons commerciales, juridiques et techniques. Un des obstacles était probablement les doutes que pouvait avoir Roon sur la pérennité du service en difficulté financière en regard de l'importance du chantier de développement a mener.
as-tu des informations précises ?
(03-09-2016, 03:48 PM)volpone75 a écrit : [ -> ]...et pour l'instant je n'ai vu aucun système UPnP proposant le même degré d'intégration, de facilité de mise en oeuvre et d'utilisation. ....
Bonjour Volpone,
quand tu parles d'intégration tu parles essentiellement de TIDAL et de liens HTTP vers des infos (artistes, titres, compositeurs ,...) ?
Merci
(03-09-2016, 03:48 PM)volpone75 a écrit : [ -> ] (03-09-2016, 02:16 PM)bubbleguuum a écrit : [ -> ] (03-09-2016, 09:57 AM)volpone75 a écrit : [ -> ]Songcast est aussi supporté par LINN et a une architecture différente de celle d'UPnP plus proche de l'approche de RoonLabs.
Songcast est comparable à AirPlay mais supportant jusqu'a 192 kHz / 24 bit et le multiroom parfairtement synchronisé (AirPlay aussi). Et surtout Songcast est Open Source, comme presque tout ce que fait Linn. N'importe quel constructeur ou developeur est libre implementer Songcast dans son produit, sans avoir besoin de demander l'autorisation à Linn ou une quelconque certification (comme RAAT).
En fait, Linn et Roon ont deux philosophies de developement entièrement opposées:
- Linn promeut en encourage un ecosystème multi-vendeur ouvert, en publiant des specs (OpenHome, Songcast) et le code Open Source ad-hoc. C'est pour cela que BubbleUPnP Server, Lumin (l'appli), upmpdcli, probablement MinimServer (indirectement) et d'autres existent. Que Kazoo et Lumin peuvent causer à des renderers qui ne sont pas des Linn DS ou Lumin (le hardware) respectivement. Il viennent meme de publier un renderer OpenHome soft (ohPlayer) qui tourne a peut prêt partout. Et avec le code source, pas moins.
- RoonLabs veut tout contrôler de bout en bout: le control point (l'appli Roon), le renderer RAAT qui doit etre certifié par eux, les protocoles propriétaires.
Oui, effectivement, on peut voir ça comme cela mais chacun à ses raisons en fonction de son coeur de métier. Celles de Roon ne me semblent pas mauvaises vu du coté de l'utilisateur final exigeant qui veut avoir le confort d'un bon système robuste facile à installer et à utiliser tout en ayant le choix des composants audio si l'offre de endpoints RoonReady se généralise ce qui semble s'amorcer au moins pour le "haut de gamme".
Par ailleurs je comprends très bien que l'on puisse préférer des standards ouverts et des softs gratuits ou financés par les constructeurs. Reste que l'architecture centralisée de Roon telle décrite ici à des avantages et pour l'instant je n'ai vu aucun système UPnP proposant le même degré d'intégration, de facilité de mise en oeuvre et d'utilisation. Je suis néanmoins d'accord avec toi sur le fait que c'est un marché de niche, reste à savoir la taille de la niche
Pour ma part consacrer moins de 5% du budget de mon système au logiciel ne me semble pas aberrant surtout dans le cadre d'une utilisation réseau multiroom "familiale" avec un (et j'espère bientôt des) service de streaming en ligne bien intégrés.
Soit tu es un bien piètre commercial de Roon soit tu es un technicien très maladroit.
Dans les deux cas tu fais une contre pub comme rarement j'ai vu.
Arrête un eu de jouer les clients "neutres" comment peux tu croire une seconde que l'on gobe ton petit jeu ?
Sur les forums, il y a des codes à respecter pour ne pas jouer à l'éléphant dans un magasin de porcelaine.
En ce qui concerne, tu as explosé tous les codes depuis longtemps, tu n'est vraiment plus crédible
