Je to asi dva roky co jsem začal používat HV rendering, konkrétně Bricasti M5. Software ROON na NUC s OS ROCK a M5 jako koncový bod. Teď jsem upgradoval na Bricasti M3, čímž jsem nahradil dosavadní DAC a preamp. Díky tomu, že M3 nemá ještě dokončený proces certifikace u Roonu (dle výrobce "few weeks"), jsem byl nucen vyzkoušet jeho "síťové funkce" něčím jiným. Použil jsem apku "Mconnect" v Iphone, je to celkem použitelné ale, celkem náročné na baterku v iphonu a nefunguje gapless ani v Tidalu ani z NASu.
Máte někdo tip na nějaký podobný SW, který by uměl streamovat do Upnp renderu z lokálních disků a Tidalu?

Audirvana

BubbleUPnP (na android)

JJ píše: ↑

11 led 2021 13:16

.. Máte někdo tip na nějaký podobný SW, který by uměl streamovat do Upnp renderu z lokálních disků a Tidalu?

K tomu vybíjení baterie mobilu: Přemýšlím, zda jsi použil formulaci ".. SW, který by uměl streamovat do Upnp renderu.." s vědomím toho, že opravdu ta apka v mobilu streamuje data do rendereru, anebo je to jen mírně zavádějící formulace, když ve skutečnosti máš apku jako tzv. "control point" a hudební data se přes mobil neposílají?

Jinak já taky používám BubbleUPnP.

mconnect na iOS bude asi jedna z těch aplikací, které neslouží jen jako dálkové ovládání. Při použítí Google Chromecast Audio se při vypnutí mconnect stream přeruší a playback ustane. V případě nativní aplikace TIDAL pro iOS, playback pokračuje dál.

mconnect jsem používal hlavně přes toto léto, kdy vinou zabugovaného updatu TIDAL aplikace nešlo používat Chromecast Audio. Jedinou vadou na kráse je nefungující gapless na Chromecast Audio.

V nastavení mconnectu gapless je - "by App" nebo "by Renderer" ani jedno nejde? Pokud není baterka opotřebovaná, nemělo by to na baterce být tak vidět. Nastavení > Baterie > Kondice baterie > Maximální kapacita.

FS píše: ↑

11 led 2021 19:25

K tomu vybíjení baterie mobilu: Přemýšlím, zda jsi použil formulaci ".. SW, který by uměl streamovat do Upnp renderu.." s vědomím toho, že opravdu ta apka v mobilu streamuje data do rendereru, anebo je to jen mírně zavádějící formulace, když ve skutečnosti máš apku jako tzv. "control point" a hudební data se přes mobil neposílají?

Jinak já taky používám BubbleUPnP.

Bricasti je pouze "render", nestačí tedy pouze "control point", ale musí někde běžet player - v mnou popsaném případě je to Mconnect v iPhonu. Není to tak, že by baterka extrémně rychle padala, spíš se vybíjí znatelně rychleji, než když Mconnect zapnutý není.
Nastavení gapless jsem už dříve našel ale nepomohlo, tady bych to viděl na drobný nesoulad díky volnější implementaci Upnp protokolu v některém ze zařízení.

Máte někdo zkušenosti s nároky na HW u Audirvany, leží mi doma nevyužitý Minimac 2012, jestli má smysl pokoušet se ji na tom rozjet?

Výkonnostně bude stačit určitě. Jen nevím, jaké verze Mac OS dnes Audirvana podporuje a jestli se dají nanistalovat na tento Mac Mini. Ale to se dá snadno zjistit. Sám mám ROON na MacMini z roku 2011 a ten se ani nezadýchá. Jen už tam nejde nainstalovat Big Sur, poslední podporovaná verze je Catalina.

Ještě upozorním, že když jsem si hrál s Audirvanou, zjistil jsem, že moje domácí wi-fi nezvládala úplně dobře streamovat hi-res flac, které vznikly převzorkováním v Audirvaně. Kousalo se to, ale po přechodu na ethernet powerline (přenos dat po silovém rozvodu) už to bylo OK.

Nebo použij ten MacMini jako Roon End Point a připoj DAC přes USB nebo optiku k MacMini.

Hmm, když má koupený dedikovaný endpoint Bricasti M5, tak přece nebude používat místo něj Mac
BRW, Bricasti M5 se mi docela líbí, něco podobného potřebuji, ale mířím k Metronome DSS kvůli kompatibilitě I2S s mým DAC.

@jj: Já mám stejně pocit, že tady něco nesedí s tím Mconnectem. Nainstaloval jsem si MconenctLite na Android a funguje podobně jako BubbleUPnP - tedy jen jako control point.

Možná je na místě si sjednotit terminologii a ujasnit "co je co". Vezmeme to logicky zezadu.

Renderer dostane adresu streamu (odkaz na track poskytnutý media sereverem, odkaz na Tidal track, ...) a pak už si sám tahá data mimo control point. Než dohraje skladbu do konce, nemá celkem potřebu komunikovat s control pointem (tohle není tak docela pravda ve všech případech), takže tu skladbu dohraje, i když by se control point mezitím odpojil od sítě (to lze jednoduše vyzkoušet).

Media server (ať už vlastní anebo z internetu) posílá data rendereru na základě odkazu zmíněného výše hudební data a stav control pointu jej v tomto okamžiku nezajímá (opět zjednodušení).

Control point je potom "jen" dálkový ovladač, který máme typicky na mobilu (ne však nutně) a ten slouží k tomu, abychom si mohli vybrat skladby a dát je to fronty k přehrávání. Control point potom funguje jako správce fronty (někdy se říká asi nesprávně playlistu) - stará se to, že až dohraje na rendereru skladba, tak pošle rendereru pokyn k přehrátí dalšího tracku.

Je to celé dost zjednodušující, ale control point by nemusel na mobilu celkem nic při přehrávání skladby dělat. V praxi to ale tak nebude - může neustále sledovat stav přehrávání a "žrát" baterku. Takže je celkem možné, že různé control pointy budou mít různý vliv na výdrž baterie.

Představa, že Mconect na Iphone funguje jako "player" a tečou přes něj data do Bricasti M5 by znamenala, že Mconnect funguje pro Bricasti jako media server. To znamená, že by tahal data z internetu do mobilu a ta dále poskytoval jako "server" pro přehrávání rendereru (Bricasti).

Netvrdím, že to tak nemůže být ... ale spíše tipuji, že není.
Otestovat to můžeš tak, že při přehrávání odpojíš mobil od sítě. Pokud bude přehrávání pokračovat po delší dobu (delší než cache na playeru), potom víš, že hudební data přes control point (mobil) netečou. Pokud se přehrávání zastaví před ukončením tracku, potom to ještě nemusí nic znamenat.
Alternativně bys to možná mohl odsledovat tak, že budeš sledovat spotřebu stažených dat na mobilu při přehrávání na Bricasti.

Díky za rady, nainstaloval jsem Audirvanu.

@jj: Tak to si IMHO vybral scénář, ve kterém taháš data do mobilu k Audirvane a ta je potom posílá na renderer. To bude mít nejspíše mnohem větší dopad na baterku a objem prenesených dat než použítí control pointu.

Vycházím z dokumentace Audirvany:
... To be able to decode files in advance, Audirvana plays the roles of control point and ad hoc media server. In other words, it is seen by the renderer as the file provider, which allows it to perform the necessary processingr. ...

Pokud je Audirvana nainstalaována na MacMini, tak to funguje jinak. Na mobil se nainstaluje řídící aplikace Audirvana Remote, přes kterou stream neteče. Ten je posílán z MacMini protokolem UPnP do rendereru.

Tak to potom ano

tesarpa píše: ↑

13 led 2021 10:23

Pokud je Audirvana nainstalaována na MacMini, tak to funguje jinak. Na mobil se nainstaluje řídící aplikace Audirvana Remote, přes kterou stream neteče. Ten je posílán z MacMini protokolem UPnP do rendereru.

Přesně tak. Mimochodem, knihovna lokálních souborů je oproti roonu na audiorvaně otřesná.

Sám jsem skončil u ROONu, po cestě jsem zanechal Squeeze/LMS, Linn Kazoo, Lumin App, Bubble UPNP server, Audirvana. Jediná, podle mého soudu, konkurenceschopná platforma je BluOS, ale ten si nenainstaluji na Raspberry Pi ani Mac jako end point.