Like Tree184Likes

DSD in LMS con SOX

Pagina 16 di 114
prima
... 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 66 ... ultimo
Visualizzazione dei risultati da 151 a 160 su 1134
  1. #151
    tebibyte
    Registrato
    Aug 2011
    Età
    47
    Messaggi
    2,917
    configurazione

    Predefinito

    Originariamente inviato da marcoc1712
    Si, giusto.

    p.s.

    sox-9999 è anche il nome usato da Kimmo in Daphile, se è voluto ok, ma attenzione a non sovrapporsi! (sono comunque diversi).
    cmnq quella di Kimmo non é condivisa in un overlay, mi pare, quindi non puó sovrapporsi.

    é un caso....penso sia una prassi in gentoo per non sovrappore alle versioni ufficiali...comunque é sox-DSD-9999

    se lo si vuole installare solo con le avx

    CPU_FLAGS_X86="avx" emerge --ask ......

    o per sse2

    CPU_FLAGS_X86="sse2" emerge --ask .......

  2. #152
    tebibyte L'avatar di UnixMan
    Registrato
    Sep 2013
    Messaggi
    2,511
    configurazione

    Predefinito

    rispondo a un po' di cose che erano restate indietro...

    Originariamente inviato da marcoc1712
    b. abbiamo (sembra) svelato l'arcano del DSD nativo, poi qualcuno mi spiega cosa sono quei formati... ma dsd non è bitstream? Ed in pa?
    [...]
    NOTA BENE: BIG ENDIAN???

    Se davvero l'uscita verso USB deve essere in formato big endian, significa che squeezelite si deve passare byte per byte ed invertire l'ordine dei bit... assolutamente inefficiente, che non valgala pena inviare big endian già da sox.
    non ne ho idea ma, "a naso", non credo che SL faccia nulla del genere. Il problema è che, a differenza del DoP, per il DSD "nativo" non esiste alcuno standard "ufficiale": è una cosa che è stata aggiunta in modo indipendente da vari produttori di interfacce USB, ed ognuno ha fatto a modo suo. Posso sbagliarmi, ma presumo che in realtà si tratti semplicemente di una sorta di "flag" che indica ad ALSA il modo in cui deve gestire la comunicazione con i diversi hardware. Immagino che dando una occhiata ai sorgenti di SL non dovrebbe essere difficile capire come stanno le cose...

    Originariamente inviato da marcoc1712
    c. riscarica e ricompila, ho applicato le ulteriori patch, vediamo se risolvono il problema di allineamento.
    [...]
    Hai ricompilato squeezelite o sei sempre alla versione precedente? solo per sapere se le altre patch sono necessarie o solo eventualmente utili.
    Ancora alla precedente. Stasera provo quella nuova. Cosa fanno di bello queste nuove patch?

    Originariamente inviato da marcoc1712
    Bel risultato.
    yes!

    Originariamente inviato da marcoc1712
    Per finire, ti chiedo di provare squeezelite ultima versione (che forse toglie anche il click)
    sarebbe fantastico!!

    ...anche se temo che possa essere un problema legato al DAC: IIRC lo fa anche con HQPlayer. In quel caso non tra una traccia e l'altra, ma quando passi da stop a play o cambi da PCM a DSD o viceversa sì. Se anche solo si riuscisse ad arrivare alla medesima situazione (evitando almeno il click quando passa da una traccia all'altra) sarebbe già una gran cosa.

    Originariamente inviato da marcoc1712
    e di provare anche anche che funzioni ancora correttamente con DOP e PCM (questo lo faccio anch'io).
    in PCM (con la vers. precedente) già fatto, no problem. Stasera provo in DoP con questa, poi passo a quella nuova e provo tutti e tre i casi.
    antonellocaroli likes this.
    Ciao, Paolo.

    «Se tu hai una mela, e io ho una mela, e ce le scambiamo, allora tu ed io abbiamo sempre una mela per uno. Ma se tu hai un'idea, ed io ho un'idea, e ce le scambiamo, allora abbiamo entrambi due idee.»

  3. #153
    pebibyte L'avatar di marcoc1712
    Registrato
    Jan 2013
    Messaggi
    5,240
    configurazione

    Predefinito

    Originariamente inviato da UnixMan
    rispondo a un po' di cose che erano restate indietro...


    non ne ho idea ma, "a naso", non credo che SL faccia nulla del genere. Il problema è che, a differenza del DoP, per il DSD "nativo" non esiste alcuno standard "ufficiale": è una cosa che è stata aggiunta in modo indipendente da vari produttori di interfacce USB, ed ognuno ha fatto a modo suo. Posso sbagliarmi, ma presumo che in realtà si tratti semplicemente di una sorta di "flag" che indica ad ALSA il modo in cui deve gestire la comunicazione con i diversi hardware. Immagino che dando una occhiata ai sorgenti di SL non dovrebbe essere difficile capire come stanno le cose...


    Ancora alla precedente. Stasera provo quella nuova. Cosa fanno di bello queste nuove patch?


    yes!


    sarebbe fantastico!!

    ...anche se temo che possa essere un problema legato al DAC: IIRC lo fa anche con HQPlayer. In quel caso non tra una traccia e l'altra, ma quando passi da stop a play o cambi da PCM a DSD o viceversa sì. Se anche solo si riuscisse ad arrivare alla medesima situazione (evitando almeno il click quando passa da una traccia all'altra) sarebbe già una gran cosa.


    in PCM (con la vers. precedente) già fatto, no problem. Stasera provo in DoP con questa, poi passo a quella nuova e provo tutti e tre i casi.
    SE riceve n LE ed esce in BE... lo deve fare per forza, il codice c'è proprio nella patch aggiunta, capire cosa fanno quelle operazioni con valori binari... per me non è immediato.

    Se poi è solo un nome usato impropriamente ed in realtà non inverte l'ordine dei bit, allora ovvio non lo fa, ma mi sembrerebbe una scelta bizzarra usare un nome preciso con significato diverso.

    Le altre patch, sempre senza aver verificato nel dettaglio:

    1. 'lima' lo stream per evitare chunk incompleti alla fine (possibile causa dei click)
    2. fissa a 24bit il dop
    3. evita che parta il resampling wav in caso di dop.
    UnixMan likes this.
    Ciao, Marco.

    "Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction."
    — E. F. Schumacher (mis-attributed to A. Einstein)
    ________________________________________________________________________________
    Autore della patch R2 per Squeezelite e del plugin C-3PO. note libere
    Logitech media Server 7.9 > miniPc + squeezelite-R2 / SB+ > "Lu Scalmentu" NOS R2R DAC by TubeOne/ AudioResearch DAC 1-20 >
    Klimo Merlino Gold TPS > DIS Interconnect > Kent Gold > Reference > Monitor Audio Studio 20 SE

  4. #154
    tebibyte
    Registrato
    Aug 2011
    Età
    47
    Messaggi
    2,917
    configurazione

    Predefinito

    Allora Fedeliallalinea ha aggiornato la ebuild con la versione sul git di Marco...stasera Provo anche io la conversione da lms se va...
    UnixMan likes this.

  5. #155
    tebibyte L'avatar di UnixMan
    Registrato
    Sep 2013
    Messaggi
    2,511
    configurazione

    Predefinito

    Originariamente inviato da marcoc1712
    SE riceve n LE ed esce in BE... lo deve fare per forza, il codice c'è proprio nella patch aggiunta,
    visto. Sì, ci sono proprio dei "bit-shift" che fanno quello. Ovviamente, per essere manipolati e trasferiti in modo efficiente, i singoli bit del DSD devono necessariamente essere "impacchettati" in qualche modo all'interno di parole di n bytes (né più né meno che quanto avviene per il DoP, salvo che non c'è l'inutile overhead dei finti header PCM). Fin qui nulla di strano. Ma perché mai poi usino rappresentazioni con "endianess" diverse (che obbligano ad effettuare operazioni inutili per riallineare i bit) non ne ho proprio idea...
    Ciao, Paolo.

    «Se tu hai una mela, e io ho una mela, e ce le scambiamo, allora tu ed io abbiamo sempre una mela per uno. Ma se tu hai un'idea, ed io ho un'idea, e ce le scambiamo, allora abbiamo entrambi due idee.»

  6. #156
    pebibyte L'avatar di marcoc1712
    Registrato
    Jan 2013
    Messaggi
    5,240
    configurazione

    Predefinito

    Originariamente inviato da UnixMan
    visto. Sì, ci sono proprio dei "bit-shift" che fanno quello. Ovviamente, per essere manipolati e trasferiti in modo efficiente, i singoli bit del DSD devono necessariamente essere "impacchettati" in qualche modo all'interno di parole di n bytes (né più né meno che quanto avviene per il DoP, salvo che non c'è l'inutile overhead dei finti header PCM). Fin qui nulla di strano. Ma perché mai poi usino rappresentazioni con "endianess" diverse (che obbligano ad effettuare operazioni inutili per riallineare i bit) non ne ho proprio idea...
    Così l'audiofilo compra computer potenti...

    Comunque, se con pcm c'è realmente poco che il player possa fare nel ciclo di lettura e scrittura verso il DAC, qui le cose cambiano, le cose da fare e fatte sono tante, seppure alla fine il risultato sarà (sostanzialmente) identico in termini di bit (ma non esattamente), il 'modo' con cui viene fatto qui o in altri player può essere sostanzialmente diverso. Non ho verificato il carico, ma secondo me andiamo ben aldilà della conversione flac/pcm. Magari però il gioco vale la candela, questo lo potete dire soltanto voi.

    p.s.

    Perchè i diversi formati ci sono solo in Linux/alsa e non in Win o osX?
    Ultima modifica di marcoc1712 : 07-02-2017 a 15:40
    Ciao, Marco.

    "Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction."
    — E. F. Schumacher (mis-attributed to A. Einstein)
    ________________________________________________________________________________
    Autore della patch R2 per Squeezelite e del plugin C-3PO. note libere
    Logitech media Server 7.9 > miniPc + squeezelite-R2 / SB+ > "Lu Scalmentu" NOS R2R DAC by TubeOne/ AudioResearch DAC 1-20 >
    Klimo Merlino Gold TPS > DIS Interconnect > Kent Gold > Reference > Monitor Audio Studio 20 SE

  7. #157
    tebibyte L'avatar di UnixMan
    Registrato
    Sep 2013
    Messaggi
    2,511
    configurazione

    Predefinito

    Originariamente inviato da marcoc1712
    Non ho verificato il carico, ma secondo me andiamo ben aldilà della conversione flac/pcm.
    no, perché mai? Sono solo un paio di bit-shift. Ciascuno dei quali si traduce direttamente in una singola istruzione assembler (che lavora direttamente sui registri della CPU, senza accessi alla memoria) che a sua volta si traduce 1:1 in codice macchina. Insomma è una operazione semplicissima, leggerissima e velocissima. Che a dir tanto aggiunge un paio di cicli di clock per ogni "word" (cioè con una frequenza pari a DSDrate/32, pari a quella del PCM a 88.2K nel caso di DSD64, a 176.4K per il 128, ecc). Per quanto semplice, la decodifica flac è enormemente più complessa!

    Originariamente inviato da marcoc1712
    Perchè i diversi formati ci sono solo in Linux/alsa e non in Win o osX?
    ah... boh, non ci ho fatto caso. La domanda sorge spontanea: su quei sistemi SL supporta il DSD nativo?

    Posto che la risposta sia affermativa, è possibile che la cosa sia gestita diversamente (demandata ad altri sottosistemi). Ad es. su win il DSD non è supportato, se non attraverso ASIO (SL supporta ASIO?). È un mondo che conosco poco per non dire per niente, ma forse è possibile che sia proprio ASIO a definire una sorta di standard per il DSD e quindi che dal punto di vista di SL il formato di uscita sia unico. Dopo di che sarebbero i driver ASIO delle varie interfacce a gestire la cosa per lo specifico hardware che supportano.
    Ultima modifica di UnixMan : 07-02-2017 a 17:58
    Ciao, Paolo.

    «Se tu hai una mela, e io ho una mela, e ce le scambiamo, allora tu ed io abbiamo sempre una mela per uno. Ma se tu hai un'idea, ed io ho un'idea, e ce le scambiamo, allora abbiamo entrambi due idee.»

  8. #158
    tebibyte
    Registrato
    Aug 2011
    Età
    47
    Messaggi
    2,917
    configurazione

    Predefinito

    Marco ma la compilazione di sox sul tuo github non va a buon fine

    codice:
    Makefile:2530: set di istruzioni per l'obiettivo "libsox_la-dsf.lo" non riuscito
    make[1]: *** [libsox_la-dsf.lo] Errore 1
    Makefile:656: set di istruzioni per l'obiettivo "all-recursive" non riuscito
    make: *** [all-recursive] Errore 1

  9. #159
    tebibyte L'avatar di UnixMan
    Registrato
    Sep 2013
    Messaggi
    2,511
    configurazione

    Predefinito

    Originariamente inviato da antonellocaroli
    Marco ma la compilazione di sox sul tuo github non va a buon fine
    che comandi hai dato per compilare?

    Prima di usare la ebuild prova a mano, come avevo indicato in un post precedente.


    BTW: compilata la nuova versione di squeezelite-R2 con le patch. Sta suonando.

    Confermo che sembra funzionare tutto (DoP, DSD nativo e PCM).
    Ciao, Paolo.

    «Se tu hai una mela, e io ho una mela, e ce le scambiamo, allora tu ed io abbiamo sempre una mela per uno. Ma se tu hai un'idea, ed io ho un'idea, e ce le scambiamo, allora abbiamo entrambi due idee.»

  10. #160
    tebibyte
    Registrato
    Aug 2011
    Età
    47
    Messaggi
    2,917
    configurazione

    Predefinito

    Originariamente inviato da UnixMan
    che comandi hai dato per compilare?

    Prima di usare la ebuild prova a mano, come avevo indicato in un post precedente.
    ho provato prima con la ebuild e non andava a buon fine e poi a mano (messaggio di sopra)

    autoreconf -i
    ./configure
    make -s

Pagina 16 di 114
prima
... 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 66 ... ultimo

Informazioni Thread

Users Browsing this Thread

Ci sono attualmente 1 utenti che stanno visualizzando questa discussione. (0 utenti e 1 ospiti)

Regole d'invio

  • Non puoi inserire discussioni
  • Non puoi inserire repliche
  • Non puoi inserire allegati
  • Non puoi modificare i tuoi messaggi
  •  
nexthardware.com - © 2002-2018

Search Engine Optimization by vBSEO 3.6.1