DSD in LMS con SOX

[RiRo]

Aspe'.
Raramente, con alcuni pezzi (escluderei il clipping, discorso complesso ) ho scoppiettii e crepitii. Essendo il pc server lontano dal Daphile, non ho modo di capire se dipende dalle risorse di PC o rete. Non ho annotato l'ora.

[SimoneFil]

beh, non sarà impegnativo ma ci state lavorando in 3 da più di una settimana, poi manca tutta l'operaione di creazione dei pacchetti per i vari sistemi linux, dato che - così mi è sempre stato detto - non si può semplicemnete 'appoggiare' l'eseguibile. Se in futuro devo farlo io, mi spaventa.

SOX in Daphile è arretrato rispetto al nostro che comprende già le patch rielaborate da mansr, non ho inverstigato su quali siano le differenze però.

In più, credo che Daphile usi le versioni non ottimizzate, dato che non ha meccanismi per installare diversamente su target diversi, quindi se va su un futro a 32bit...

Chiaro, l'eseguibile lo puoi "appoggiare" solo se hai tutte le dipendenze installate. Il metodo più comodo per l'utente ovviamente è avere un pacchetto installabile che faccia tutto lui. Finchè c'è da aggiornare i binari il lavoro è quasi pari a 0, se c'è ogni volta da creare i pacchetti per tutti gli O.S. allora la situazione è molto più complicata. A questo punto consiglio piuttosto di tenere aggiornati i binari e scrivere per ogni o.s. quale dipendenze installare così l'utente si limita a fare un copia-incolla del comando già scritto e si risolve tutto così senza troppi intoppi.

[antonellocaroli]

@Marco
per squeezelite-R2 intendi mettere un link diretto ai sorgenti sul tuo github, cambiando la versione?

[UnixMan]

Ho aggiornato il link per il binario di squeezelite per raspbian, [...]

BTW: hai visto questo?

https://github.com/ralph-irving/sque...ment-282754001

...magari puoi rispondergli tu?

E' sottinteso che per quanto riguarda tutte le versioni di squeezelite l'utente dovrà installare le dipendenze perchè le librerie sono linkate dinamicamente.

è per quello che mi sarebbe piaciuto produrre un eseguibile linkato staticamente, che dipenda solo dalla (g)libc...

[...] nella nostra implementazione SoX lavora in single core o multi thread?

singolo core. Vedi un mio post di qualche giorno fa.

E' essenziale che non lavori su un singolo core per evitare di escludere molte cpu.

come dicevamo, è un'arma a doppio taglio... rischi di saturare la CPU creando problemi. Lo metterei come opzione, ma di certo non abilitata di default.

Come mai questa differenza di uso CPU? Daphile implementa qualche patch che rende la conversione più pesante?

bella domanda...

Chiaro, l'eseguibile lo puoi "appoggiare" solo se hai tutte le dipendenze installate. Il metodo più comodo per l'utente ovviamente è avere un pacchetto installabile che faccia tutto lui.

proprio per questo ho compilato i binari di sox con tutte le dipendenze (ad eccezione della glibc) linkate staticamente. Altrimenti la cosa sarebbe ingestibile.

Quei binari dipendono solo dalla glibc, che ovviamente è (necessariamente) già presente in qualsiasi sistema GNU/Linux. Perciò (purché la versione di glibc sia compatibile, ma quella non è una cosa che cambi spesso) li puoi semplicemente "appoggiare" su qualsiasi sistema e funzionano.

È esattamente ciò che fa LMS proprio con sox (e flac, ecc). Si tratta di binari compilati allo stesso modo che di fatto LMS si limita ad "appoggiare" nelle sue dir.

Sebbene squeezelite-R2 "minimale" abbia comunque pochissime dipendenze (di fatto glibc, libasound2 e poco altro), se si potesse fare la medesima cosa anche per quello sarebbe meglio. Ma resta un problema minore.

Invece sox lo si può far "installare" direttamente da C-3PO.

[SimoneFil]

BTW: hai visto questo?

https://github.com/ralph-irving/sque...ment-282754001

...magari puoi rispondergli tu?
Il punto è che non ho la più pallida idea del perchè gli sia venuto fuori quell'errore ...

è per quello che mi sarebbe piaciuto produrre un eseguibile linkato staticamente, che dipenda solo dalla (g)libc...
In questo campo credo che tu ne sappia più di me.. proverò comunque a fare qualche ricerca e ad andare a tentoni

singolo core. Vedi un mio post di qualche giorno fa.


come dicevamo, è un'arma a doppio taglio... rischi di saturare la CPU creando problemi. Lo metterei come opzione, ma di certo non abilitata di default.
Per me si hanno molti più svantaggi a non metterla come opzioni, escluderesti praticamente tutti gli i3, i pentium, i celeron, gli atom multicore che altrimenti andrebbero senza problemi. E' molto più semplice saturare un core solo impedendo così la conversione piuttosto che distribuire il carico su più core. In ogni caso sapresti dirmi cosa devo modificare in C-3PO per abilitare il multi thread? Magari l'opzione da aggiungere prevede anche specificare quanti core utilizzare ... e così ti risolveresti ogni problema.


proprio per questo ho compilato i binari di sox con tutte le dipendenze (ad eccezione della glibc) linkate staticamente. Altrimenti la cosa sarebbe ingestibile.

Quei binari dipendono solo dalla glibc, che ovviamente è (necessariamente) già presente in qualsiasi sistema GNU/Linux. Perciò (purché la versione di glibc sia compatibile, ma quella non è una cosa che cambi spesso) li puoi semplicemente "appoggiare" su qualsiasi sistema e funzionano.

È esattamente ciò che fa LMS proprio con sox (e flac, ecc). Si tratta di binari compilati allo stesso modo che di fatto LMS si limita ad "appoggiare" nelle sue dir.

Sebbene squeezelite-R2 "minimale" abbia comunque pochissime dipendenze (di fatto glibc, libasound2 e poco altro), se si potesse fare la medesima cosa anche per quello sarebbe meglio. Ma resta un problema minore.

Invece sox lo si può far "installare" direttamente da C-3PO.

Concordo sul fatto che sia un problema minore, linkare staticamente il tutto è assolutamente più comodo, ma far scrivere una riga in più all'utente facendo copia incolla del comando per installare le dipendenze non è complicato per nessuno ... Intanto sta sera testo a fondo l'eseguibile su Rasp per vedere se va in DSD nativo o meno

Ho preferito risponderti cambiando colore piuttosto che rifare tutti i quote

[marcoc1712]

@Marco
per squeezelite-R2 intendi mettere un link diretto ai sorgenti sul tuo github, cambiando la versione?

Sicuramente ci sarà una nuova release e - se non decidiamo qualcosa di diverso - ci saranno le 'solite' versioni binarie per win, osX e Debian-i3b6 (funzionante ovunque).

Francamente però sono confuso..., se torno alle discussioni fatte tempo fa, quando volevo distribuire solo i binari anche per debian e gentoo ed alle opposizioni veementi che ricevetti, non capisco bene dove si stia andando adesso.

Non voglio minimamente entrare nella questione, anzi, vorrei proprio tirarmene fuori, però voglio anche evitare che ci si a una fioritura incontrollata di versioni in giro e SOPRATTUTTO non voglio dover rispondere per problemi di installazione/integrazione in sistemi che non conosco.

Una cosa che metterò certamente come vincolo per chiunque voglia distribuire in formato eseguibile versioni modificate di R2 e è quello di evidenziarlo almeno nel codice versione e possibilmente nella documentazione online (-?), così da evitare problemi di supporto.

Sto cercando di farmi un'idea.

[marcoc1712]

BTW: hai visto questo?

https://github.com/ralph-irving/sque...ment-282754001

Ralphy ha, giustamente, chiuso la issue, dato che io avevo segnalato la persona ad usare il mio repo ed il problema si origina li, magari la riaprirà.

[SimoneFil]

Sto testando la versione appena compilata per RPI ma succede una cosa strana. La avvio , faccio partire il file convertito, il DAC cambia sample rate ma non si sente nulla

Log squeezelite:

[21:24:48.482583] codec_open:218 codec open: 'd'
[21:24:48.483085] stream_sock:384 connecting to 192.168.1.77:9000
[21:24:48.487477] stream_sock:413 header: GET /stream.mp3?player=64:d1:a3:2f:2f:da HTTP/1.0


[21:24:48.487605] sendSTAT:171 STAT: STMc
[21:24:48.487777] process_strm:357 set fade mode: 0
[21:24:48.487907] process:494 audg
[21:24:48.487970] process_audg:413 audg gainL: 3840 gainR: 3840 adjust: 0
[21:24:48.488032] set_volume:246 setting internal gain left: 65536 right: 65536
[21:24:48.560054] stream_thread:176 headers: len: 115
HTTP/1.1 200 OK
Server: Logitech Media Server (7.9.0 - 1487582706)
Connection: close
Content-Type: audio/dsf


[21:24:48.561203] sendRESP:202 RESP
[21:24:49.112308] _read_header:191 id: DSD  len: 28 consume: 28
[21:24:49.114216] _read_header:158 DSF version: 1 format: 0
[21:24:49.114696] _read_header:168 channels: 2
[21:24:49.114939] _read_header:169 sample rate: 5644800
[21:24:49.115044] _read_header:170 lsb first: 1
[21:24:49.115096] _read_header:171 sample bytes: 2305843009213693951
[21:24:49.115217] _read_header:172 block size: 4096
[21:24:49.115274] _read_header:191 id: fmt  len: 52 consume: 52
[21:24:49.115326] _read_header:178 found dsd len: 12
[21:24:49.115373] dsd_decode:527 setting track_start
[21:24:49.115448] dsd_decode:538 DOP output
[21:24:49.120114] _output_frames:61 start buffer frames: 55296
[21:24:49.130485] _output_frames:83 pause 220 frames
[21:24:49.130770] _output_frames:83 pause 0 frames
[21:24:49.130842] _output_frames:146 track start sample rate: 352800 replay_gain: 0
[21:24:49.140948] output_thread:638 open output device: hw:CARD=UD501,DEV=0
[21:24:49.141910] alsa_open:355 opening device at: 352800
[21:24:49.143150] alsa_open:406 opened device hw:CARD=UD501,DEV=0 using format: S32_LE sample rate: 352800 mmap: 1
[21:24:49.143364] alsa_open:485 buffer: 40 period: 4 -> buffer size: 14112 period size: 3528
[21:24:49.401384] _output_frames:83 pause 1764 frames
[21:24:49.401645] _output_frames:83 pause 0 frames
[21:24:50.122436] sendSTAT:171 STAT: STMs
[21:24:50.122691] sendSTAT:171 STAT: STMt
[21:24:51.123829] sendSTAT:171 STAT: STMt
[21:24:51.329553] process:494 strm
[21:24:51.329730] process_strm:256 strm command t
[21:24:51.329802] sendSTAT:171 STAT: STMt
[21:24:52.331147] sendSTAT:171 STAT: STMt
[21:24:53.332595] sendSTAT:171 STAT: STMt
[21:24:54.334031] sendSTAT:171 STAT: STMt
[21:24:55.329878] process:494 strm
[21:24:55.330080] process_strm:256 strm command t
[21:24:55.330147] sendSTAT:171 STAT: STMt
[21:24:56.331475] sendSTAT:171 STAT: STMt
[21:24:57.332908] sendSTAT:171 STAT: STMt
[21:24:58.334342] sendSTAT:171 STAT: STMt
[21:24:59.329718] process:494 strm
[21:24:59.329899] process_strm:256 strm command t
[21:24:59.329975] sendSTAT:171 STAT: STMt
[21:25:00.331337] sendSTAT:171 STAT: STMt
[21:25:01.332838] sendSTAT:171 STAT: STMt
[21:25:02.334296] sendSTAT:171 STAT: STMt
[21:25:03.330208] process:494 strm
[21:25:03.330395] process_strm:256 strm command t
[21:25:03.330459] sendSTAT:171 STAT: STMt
[21:25:04.331717] sendSTAT:171 STAT: STMt
[21:25:04.366296] process:494 audg
[21:25:04.366459] process_audg:413 audg gainL: 0 gainR: 0 adjust: 0
[21:25:04.366524] set_volume:246 setting internal gain left: 65536 right: 65536
[21:25:04.366980] process:494 strm
[21:25:04.367074] process_strm:256 strm command p
[21:25:04.367140] sendSTAT:171 STAT: STMp
[21:25:04.367376] process_strm:292 pause interval: 0
[21:25:07.333767] process:494 strm
[21:25:07.333944] process_strm:256 strm command t
[21:25:07.334010] sendSTAT:171 STAT: STMt
[21:25:11.334090] process:494 strm
[21:25:11.334249] process_strm:256 strm command t
[21:25:11.334310] sendSTAT:171 STAT: STMt
[21:25:15.330511] process:494 strm
[21:25:15.330675] process_strm:256 strm command t
[21:25:15.330736] sendSTAT:171 STAT: STMt
[21:25:19.332577] process:494 strm
[21:25:19.332740] process_strm:256 strm command t
[21:25:19.332835] sendSTAT:171 STAT: STMt
[21:25:23.331702] process:494 strm
[21:25:23.331836] process_strm:256 strm command t
[21:25:23.331882] sendSTAT:171 STAT: STMt
[21:25:27.330175] process:494 strm
[21:25:27.330343] process_strm:256 strm command t
[21:25:27.330404] sendSTAT:171 STAT: STMt
[21:25:31.332759] process:494 strm
[21:25:31.332920] process_strm:256 strm command t
[21:25:31.332981] sendSTAT:171 STAT: STMt
[21:25:35.334219] process:494 strm
[21:25:35.334382] process_strm:256 strm command t
[21:25:35.334444] sendSTAT:171 STAT: STMt
[21:25:39.331147] process:494 strm
[21:25:39.331307] process_strm:256 strm command t
[21:25:39.331465] sendSTAT:171 STAT: STMt
[21:25:43.330951] process:494 strm
[21:25:43.331120] process_strm:256 strm command t
[21:25:43.331183] sendSTAT:171 STAT: STMt

[marcoc1712]

Sto testando la versione appena compilata per RPI ma succede una cosa strana. La avvio , faccio partire il file convertito, il DAC cambia sample rate ma non si sente nulla

Log squeezelite:

[21:24:48.482583] codec_open:218 codec open: 'd'
[21:24:48.483085] stream_sock:384 connecting to 192.168.1.77:9000
[21:24:48.487477] stream_sock:413 header: GET /stream.mp3?player=64:d1:a3:2f:2f:da HTTP/1.0


[21:24:48.487605] sendSTAT:171 STAT: STMc
[21:24:48.487777] process_strm:357 set fade mode: 0
[21:24:48.487907] process:494 audg
[21:24:48.487970] process_audg:413 audg gainL: 3840 gainR: 3840 adjust: 0
[21:24:48.488032] set_volume:246 setting internal gain left: 65536 right: 65536
[21:24:48.560054] stream_thread:176 headers: len: 115
HTTP/1.1 200 OK
Server: Logitech Media Server (7.9.0 - 1487582706)
Connection: close
Content-Type: audio/dsf


[21:24:48.561203] sendRESP:202 RESP
[21:24:49.112308] _read_header:191 id: DSD  len: 28 consume: 28
[21:24:49.114216] _read_header:158 DSF version: 1 format: 0
[21:24:49.114696] _read_header:168 channels: 2
[21:24:49.114939] _read_header:169 sample rate: 5644800
[21:24:49.115044] _read_header:170 lsb first: 1
[21:24:49.115096] _read_header:171 sample bytes: 2305843009213693951
[21:24:49.115217] _read_header:172 block size: 4096
[21:24:49.115274] _read_header:191 id: fmt  len: 52 consume: 52
[21:24:49.115326] _read_header:178 found dsd len: 12
[21:24:49.115373] dsd_decode:527 setting track_start
[21:24:49.115448] dsd_decode:538 DOP output
[21:24:49.120114] _output_frames:61 start buffer frames: 55296
[21:24:49.130485] _output_frames:83 pause 220 frames
[21:24:49.130770] _output_frames:83 pause 0 frames
[21:24:49.130842] _output_frames:146 track start sample rate: 352800 replay_gain: 0
[21:24:49.140948] output_thread:638 open output device: hw:CARD=UD501,DEV=0
[21:24:49.141910] alsa_open:355 opening device at: 352800
[21:24:49.143150] alsa_open:406 opened device hw:CARD=UD501,DEV=0 using format: S32_LE sample rate: 352800 mmap: 1
[21:24:49.143364] alsa_open:485 buffer: 40 period: 4 -> buffer size: 14112 period size: 3528
[21:24:49.401384] _output_frames:83 pause 1764 frames
[21:24:49.401645] _output_frames:83 pause 0 frames
[21:24:50.122436] sendSTAT:171 STAT: STMs
[21:24:50.122691] sendSTAT:171 STAT: STMt
[21:24:51.123829] sendSTAT:171 STAT: STMt
[21:24:51.329553] process:494 strm
[21:24:51.329730] process_strm:256 strm command t
[21:24:51.329802] sendSTAT:171 STAT: STMt
[21:24:52.331147] sendSTAT:171 STAT: STMt
[21:24:53.332595] sendSTAT:171 STAT: STMt
[21:24:54.334031] sendSTAT:171 STAT: STMt
[21:24:55.329878] process:494 strm
[21:24:55.330080] process_strm:256 strm command t
[21:24:55.330147] sendSTAT:171 STAT: STMt
[21:24:56.331475] sendSTAT:171 STAT: STMt
[21:24:57.332908] sendSTAT:171 STAT: STMt
[21:24:58.334342] sendSTAT:171 STAT: STMt
[21:24:59.329718] process:494 strm
[21:24:59.329899] process_strm:256 strm command t
[21:24:59.329975] sendSTAT:171 STAT: STMt
[21:25:00.331337] sendSTAT:171 STAT: STMt
[21:25:01.332838] sendSTAT:171 STAT: STMt
[21:25:02.334296] sendSTAT:171 STAT: STMt
[21:25:03.330208] process:494 strm
[21:25:03.330395] process_strm:256 strm command t
[21:25:03.330459] sendSTAT:171 STAT: STMt
[21:25:04.331717] sendSTAT:171 STAT: STMt
[21:25:04.366296] process:494 audg
[21:25:04.366459] process_audg:413 audg gainL: 0 gainR: 0 adjust: 0
[21:25:04.366524] set_volume:246 setting internal gain left: 65536 right: 65536
[21:25:04.366980] process:494 strm
[21:25:04.367074] process_strm:256 strm command p
[21:25:04.367140] sendSTAT:171 STAT: STMp
[21:25:04.367376] process_strm:292 pause interval: 0
[21:25:07.333767] process:494 strm
[21:25:07.333944] process_strm:256 strm command t
[21:25:07.334010] sendSTAT:171 STAT: STMt
[21:25:11.334090] process:494 strm
[21:25:11.334249] process_strm:256 strm command t
[21:25:11.334310] sendSTAT:171 STAT: STMt
[21:25:15.330511] process:494 strm
[21:25:15.330675] process_strm:256 strm command t
[21:25:15.330736] sendSTAT:171 STAT: STMt
[21:25:19.332577] process:494 strm
[21:25:19.332740] process_strm:256 strm command t
[21:25:19.332835] sendSTAT:171 STAT: STMt
[21:25:23.331702] process:494 strm
[21:25:23.331836] process_strm:256 strm command t
[21:25:23.331882] sendSTAT:171 STAT: STMt
[21:25:27.330175] process:494 strm
[21:25:27.330343] process_strm:256 strm command t
[21:25:27.330404] sendSTAT:171 STAT: STMt
[21:25:31.332759] process:494 strm
[21:25:31.332920] process_strm:256 strm command t
[21:25:31.332981] sendSTAT:171 STAT: STMt
[21:25:35.334219] process:494 strm
[21:25:35.334382] process_strm:256 strm command t
[21:25:35.334444] sendSTAT:171 STAT: STMt
[21:25:39.331147] process:494 strm
[21:25:39.331307] process_strm:256 strm command t
[21:25:39.331465] sendSTAT:171 STAT: STMt
[21:25:43.330951] process:494 strm
[21:25:43.331120] process_strm:256 strm command t
[21:25:43.331183] sendSTAT:171 STAT: STMt

gli stai mandando DSD256 che tenta di rendere in DOP a 352800, sembra trasmettere correttamente.

Hai cmpilato l'ultima versione aggiornata da me domenica?

[UnixMan]

Sto testando la versione appena compilata per RPI ma succede una cosa strana. La avvio , faccio partire il file convertito, il DAC cambia sample rate ma non si sente nulla

mmmh... idea banale: per prima cosa prova a controllare (con alsamixer) che l'uscita non sia in "mute" o cose del genere...

P.S.: se stai provando in DSD, (ri)prova anche in PCM.