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 .......
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.
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.»
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.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 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.
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
Allora Fedeliallalinea ha aggiornato la ebuild con la versione sul git di Marco...stasera Provo anche io la conversione da lms se va...
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.»
Così l'audiofilo compra computer potenti...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...
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 16: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
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!
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 18: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.»
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
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.»
Ci sono attualmente 3 utenti che stanno visualizzando questa discussione. (0 utenti e 3 ospiti)
|
nexthardware.com - © 2002-2022 |
Rispondi quotando