Gli streamer suonano?

[Membro_0015]

11 ore fa, Nacchero ha scritto:

Il suono, ovviamente, dipende quasi del tutto dal DAC e dalla sua sezione analogica d'uscita,

esatto. Poiche' il thread e sui lettori di rete davo per scontato che il DAC sia ... altro, La prova va fatta collegando i lettori allo stesso dac e commutando. Tra l'altro viene bene se si assume lo stesso livello di uscita (viene gratis con la USB che normalmente non prevede controllo di volume e qualora lo preveda si mette a 0 dBFS)

[roop]

16 ore fa, Simonef ha scritto:

La trasmissione è tramite TCP, i disturbi sono inifluenti, i dati arrivano integri

Cito te ma il discorso è generico, ovviamente non ho nulla contro di te, anzi.

sei sicuro che lo streaming avvenga via tcp?

 

[Simonef]

@roop Ci mancherebbe.

Queste sono le  connessioni che ha aperto l'app di Qobuz durante la riproduzione... come vedi tutte TCP

 

 

[one4seven]

@Simonef anche perché non potrebbe essere altrimenti. 

[Membro_0015]

@roop https://community.roonlabs.com/t/protocol-used-by-rock-for-qobuz-streaming/72458

 

[roop]

Premesso che non sono assolutamente nè un tecnico informatico, tantomeno un ingegnere elettronico (per fortuna🤣)

Mi spiegarono che la trasmissione in streaming di audio/video viene veicolata tramite protocollo UDP (da non confondersi con UDC e/o UDEUR) e che quindi la perdita di dati è prevista eccome rispetto al TCP (vedasi https://it.wikipedia.org/wiki/User_Datagram_Protocol)

Ecco, potenzialmente spiegato l' arcano del perchè gli streamer non suonano proprio uguali. Poi ci sarebbero da indagare anche altri aspetti ma, per il momento, preferisco fermarmi qui e fare una figura di m... per volta 😅

Se ho detto stupidaggini, me ne scuso in anticipo...

[varenx]

@roop Dipende da come implementi la trasmissione. Se usi gli standard di trasmissione audio video realtime 

allora per farli funzionare bene devi implementare il QOS su tutti gli apparati intermedi altrimenti la perdita di pacchetti 

( ammessa )  rovina la trasmissione 

Per la riproduzione in streaming non si usa il realtime ma si preferisce approfittare della banda più larga e del fatto che il contenuto è già completamente disponibile ad inizio trasmissione, bufferizzando prima di cominciare il play ( se guardi la trasmissione di dati su un endpoint ti accorgi che è un po a dente di sega ).

Tutti i protocolli di streaming sono implementati su tcp per approfittare dell'integrità della trasmissione.

v

[bibo01]

@roop Da quel che so Qobuz e Tidal usano le Rest API per lo streaming. In pratica il tuo computer server manda una richiesta REST su HTTP al server Qobuz/Tidal. Il tuo computer crea una connessione TCP/IP a Qobuz/Tidal e trasferisce la richiesta dopo che la connessione è avvenuta. Il server Qobuz/Tidal risponde alla richiesta REST/HTTP tramite una connessione TCP/IP. Quando il responso è completo, la connessione TCP/IP viene chiusa.

[roop]

Mi sa che queste cose dovreste spiegarle a Dazn, allora!!!😁

Cmq, ripensandoci meglio sarebbe strano che un servizio tipo Qobuz che si proclama di qualità, perdesse i pezzi per strada causa protocollo.

Mi sovviene...ma questo recupero (ipotetico) di bit mancanti via TCP non può portare a sfasamenti (timing) nella ricezione ed andare ad influire in qualche modo sulla percezione audio?

Ogni cosa ha il suo prezzo non credo che tcp abbia solo vantaggi...

Grazie

[one4seven]

47 minuti fa, roop ha scritto:

Ogni cosa ha il suo prezzo non credo che tcp abbia solo vantaggi...

Lo svantaggio è proprio quello che non è un protocollo adatto per trasmissioni in RealTime. Il fatto che preveda solamente una trasmissione senza perdita, fa si che sia soggetto a latenze e quindi non adatto a quei servizi che non possono funzionare con latenza (vedi games online)

[Membro_0015]

1 ora fa, roop ha scritto:

Mi sovviene...ma questo recupero (ipotetico) di bit mancanti via TCP non può portare a sfasamenti (timing) nella ricezione ed andare ad influire in qualche modo sulla percezione audio?

no perche' c'e' il buffering. Il jitter e' gestito dal DAC ovvero dalla connessione USB (asincrona, quindi a prova di priettile)

[Membro_0015]

2 ore fa, roop ha scritto:

Mi sa che queste cose dovreste spiegarle a Dazn, allora!!!

i server di DAZN sono sottomensionati. Non credo c'entrino i protocolli

2 ore fa, one4seven ha scritto:

quindi non adatto a quei servizi che non possono funzionare con latenza (vedi games online)

per il solo audio va benissmo. Qui si parla di questo

[campaz]

2 ore fa, roop ha scritto:

Mi sa che queste cose dovreste spiegarle a Dazn, allora!!

 

Sono due contesti diversi: DAZN trasmette un evento in tempo reale, un servizio di musica ti fornisce una risorsa stabile. Se ti devo consegnare un file che ho stabilmente in pancia ti faccio aspettare, faccio buffering e quindi inizio ad inviare le informazioni (è così che funzionano i servizi audio musicali oppure quelli VOD come Netflix). Se l'evento è in tempo reale, non ho il tempo di fare buffering: ti invio i dati senza pensarci su. Per questo un servizio che offre risorse stabili normalmente è meno impattato dalle interruzioni della connessione (se queste non superano un certo tempo). Poi, nel caso delle partite c'è tutto un mondo che si apre (CDN, connessioni client/server dedicate ecc.). Non mi stupirebbe se Qobuz usasse TCP mentr DAZN si affidasse al più veloce, ma meno affidabile, UDP: avrebbe un senso. m2c   

[Folkman]

5 ore fa, roop ha scritto:

col)

Ecco, potenzialmente spiegato l' arcano del perchè gli streamer non suonano proprio uguali

Meno male che non sei ingegnere con 2/3 dottorati perché per capire basta avere una visione del mondo a 360 gradi , non fare mai quelle ridicole prove in cieco , provare e poi prendere quello che più ci piace , spendere quello che è possibile e ascoltare  un sacco di musica .

 

[roop]

Peccato non abbiate capito che quella su Dazn era una battuta. Troppo presi dalla seriosità della (gaia) scienza del bit(ter). Sinceramente io valuto i risultati. Molto meno mi interessano come vengano tecnicamente raggiunti.