DSD in LMS con SOX

[UnixMan]

Sto provando a compilare per rpi, durante la compilazione mi dà vari errori: risolti tutti tranne il seguente, secondo voi cosa può essere?

pi@raspberrypi:~/squeezelite-R2 $ make -f Makefile.rpi
[...]
output_alsa.o
output_alsa.c: In function ‘alsa_open’:
output_alsa.c:422:17: error: ‘SND_PCM_FORMAT_DSD_U16_BE’ undeclared (first use in this function)
   alsa.format = SND_PCM_FORMAT_DSD_U16_BE; break;
                 ^

C'è una versione di ALSA (libasound2) troppo vecchia, che non include ancora il supporto DSD...

[SimoneFil]

C'è una versione di ALSA (libasound2) troppo vecchia, che non include ancora il supporto DSD...

Vero! La cosa strana è che i binari scaricabili con apt-get sono rimasti alle lib 1.0.28, ho dovuto compilarle io alla versione 1.1.3! Così ho rimosso l'errore

Compilando poi dava errori perchè andava a prendersi stdint.h e inittypes.h dalla cartella include e non dalle librerie di sistema, dando errore perchè quelli nella cartella include sono utilizzabili solo con Mirosoft Visual Studio.
Cancellandoli la compilazione proseguiva per poi fermarsi inesorabilmente sul fantomatico mpg123

cc -Wall -fPIC -s -O3 -march=armv6 -mfloat-abi=hard -mfpu=vfp -DRESAMPLE -DFFMPEG -DVISEXPORT -DDSD -DIR -I./include  mpg.c -c -o mpg.o
In file included from mpg.c:23:0:
./include/mpg123.h:10:19: fatal error: tchar.h: No such file or directory
 #include <tchar.h>
                   ^
compilation terminated.
Makefile:82: recipe for target 'mpg.o' failed
make: *** [mpg.o] Error 1

Ovviamente ho installato le librerie per mpg123.

[UnixMan]

Vero! La cosa strana è che i binari scaricabili con apt-get sono rimasti alle lib 1.0.28, ho dovuto compilarle io alla versione 1.1.3! Così ho rimosso l'errore

che distribuzione hai, Debian wheezy? Jessie dovrebbe avere la 1.0.25, stretch la 1.0.27.

Direi che ti conviene aggiornare tutto. Oppure, se non è possibile, quanto meno fare un "backport" del pacchetto di alsa, e sostituire quelli di sistema. Altrimenti poi non funzionerà niente comunque...

[SimoneFil]

che distribuzione hai, Debian wheezy? Jessie dovrebbe avere la 1.0.25, stretch la 1.0.27.

Direi che ti conviene aggiornare tutto. Oppure, se non è possibile, quanto meno fare un "backport" del pacchetto di alsa, e sostituire quelli di sistema. Altrimenti poi non funzionerà niente comunque...

Debian Jessie, sostituiti quelli di sistema correttamente con gli ultimi disponibili 1.1.3 (e funziona tutto), anche se ormai questo problema è risolto. E' mpg123 che ha un rapporto complicato con me (o io con lui)

[antonellocaroli]

Ho fatto un po di prove

sox prodotto da MVS: Normale,AVX,SSE2 e x64 di Paolo..

Da linea di comando, conversione stesso file:
Hanno tutte la stessa identica tempistica..e quasi lo stesso uso di CPU leggermente di piú SSE2

In LMS la cosa si ribalta quella che usa leggermente meno cpu é SSE2

La 64 di Paolo non va in LMS (il perché non saprei) ma da questo errore all´avvio di LMS:

Non riesco a postare l´immagine, ma é una roba del genere: sox.exe - Errore di applicazione - impossibile avviare correttamente l´applicazione (0x000007b). fare clic su OK per chiudere lápplicazione.

Allora ho provato la 32 di Paolo, DSD256 Balbetta non ce la fa...come se non stessi sul mio I7 ma sull´I3
DSD128 va..

Questo sul mio sistema. Dove se dovessi scegliere adesso, a caldo e a naso, lascerei la SSE2.

[marcoc1712]

Sto provando a compilare per rpi, durante la compilazione mi dà vari errori: risolti tutti tranne il seguente, secondo voi cosa può essere?

pi@raspberrypi:~/squeezelite-R2 $ make -f Makefile.rpi
cc -Wall -fPIC -s -O3 -march=armv6 -mfloat-abi=hard -mfpu=vfp -DVISEXPORT -DDSD -DGPIO -DRPI -DIR -I./include main.c -c -o main.o
cc -Wall -fPIC -s -O3 -march=armv6 -mfloat-abi=hard -mfpu=vfp -DVISEXPORT -DDSD -DGPIO -DRPI -DIR -I./include slimproto.c -c -o slimproto.o
cc -Wall -fPIC -s -O3 -march=armv6 -mfloat-abi=hard -mfpu=vfp -DVISEXPORT -DDSD -DGPIO -DRPI -DIR -I./include utils.c -c -o utils.o
cc -Wall -fPIC -s -O3 -march=armv6 -mfloat-abi=hard -mfpu=vfp -DVISEXPORT -DDSD -DGPIO -DRPI -DIR -I./include buffer.c -c -o buffer.o
cc -Wall -fPIC -s -O3 -march=armv6 -mfloat-abi=hard -mfpu=vfp -DVISEXPORT -DDSD -DGPIO -DRPI -DIR -I./include stream.c -c -o stream.o
cc -Wall -fPIC -s -O3 -march=armv6 -mfloat-abi=hard -mfpu=vfp -DVISEXPORT -DDSD -DGPIO -DRPI -DIR -I./include decode.c -c -o decode.o
cc -Wall -fPIC -s -O3 -march=armv6 -mfloat-abi=hard -mfpu=vfp -DVISEXPORT -DDSD -DGPIO -DRPI -DIR -I./include flac.c -c -o flac.o
cc -Wall -fPIC -s -O3 -march=armv6 -mfloat-abi=hard -mfpu=vfp -DVISEXPORT -DDSD -DGPIO -DRPI -DIR -I./include pcm.c -c -o pcm.o
cc -Wall -fPIC -s -O3 -march=armv6 -mfloat-abi=hard -mfpu=vfp -DVISEXPORT -DDSD -DGPIO -DRPI -DIR -I./include mad.c -c -o mad.o
cc -Wall -fPIC -s -O3 -march=armv6 -mfloat-abi=hard -mfpu=vfp -DVISEXPORT -DDSD -DGPIO -DRPI -DIR -I./include vorbis.c -c -o vorbis.o
cc -Wall -fPIC -s -O3 -march=armv6 -mfloat-abi=hard -mfpu=vfp -DVISEXPORT -DDSD -DGPIO -DRPI -DIR -I./include output_alsa.c -c -o output_alsa.o
output_alsa.c: In function ‘alsa_open’:
output_alsa.c:422:17: error: ‘SND_PCM_FORMAT_DSD_U16_BE’ undeclared (first use in this function)
   alsa.format = SND_PCM_FORMAT_DSD_U16_BE; break;
                 ^
output_alsa.c:422:17: note: each undeclared identifier is reported only once for each function it appears in
output_alsa.c:424:17: error: ‘SND_PCM_FORMAT_DSD_U32_LE’ undeclared (first use in this function)
   alsa.format = SND_PCM_FORMAT_DSD_U32_LE; break;
                 ^
output_alsa.c:426:17: error: ‘SND_PCM_FORMAT_DSD_U32_BE’ undeclared (first use in this function)
   alsa.format = SND_PCM_FORMAT_DSD_U32_BE; break;
                 ^
Makefile.rpi:20: recipe for target 'output_alsa.o' failed
make: *** [output_alsa.o] Error 1

Me lo ha appena riferito anche Ralphy... Il problema pare essere la versione di Alsa in Debian 8 sul PI.

[marcoc1712]

Ho fatto un po di prove

sox prodotto da MVS: Normale,AVX,SSE2 e x64 di Paolo..

Da linea di comando, conversione stesso file:
Hanno tutte la stessa identica tempistica..e quasi lo stesso uso di CPU leggermente di piú SSE2

In LMS la cosa si ribalta quella che usa leggermente meno cpu é SSE2

La 64 di Paolo non va in LMS (il perché non saprei) ma da questo errore all´avvio di LMS:

Non riesco a postare l´immagine, ma é una roba del genere: sox.exe - Errore di applicazione - impossibile avviare correttamente l´applicazione (0x000007b). fare clic su OK per chiudere lápplicazione.

Allora ho provato la 32 di Paolo, DSD256 Balbetta non ce la fa...come se non stessi sul mio I7 ma sull´I3
DSD128 va..

Questo sul mio sistema. Dove se dovessi scegliere adesso, a caldo e a naso, lascerei la SSE2.

Ottimo. Il problema con la 64 è probabilmente socketwrapper, scartata.

Bisognerebbe controllare la portabilità della SSE2 e della 'normale' su win7 o 8. se va su tutte, decidi tu, io terrei una piccolissima preferenza per la normale, a scanso di possibili problemi su altri processori (AMD?).

Grazie della collaborazione.

[marcoc1712]

Mi prometto di farle...non si protrebbe mettere in prima pagina i link ai vari binari prodotti fino ad adesso?

? (?? servono almeno 3 caratteri)

[marcoc1712]

Vero! La cosa strana è che i binari scaricabili con apt-get sono rimasti alle lib 1.0.28, ho dovuto compilarle io alla versione 1.1.3! Così ho rimosso l'errore

Compilando poi dava errori perchè andava a prendersi stdint.h e inittypes.h dalla cartella include e non dalle librerie di sistema, dando errore perchè quelli nella cartella include sono utilizzabili solo con Mirosoft Visual Studio.
Cancellandoli la compilazione proseguiva per poi fermarsi inesorabilmente sul fantomatico mpg123

cc -Wall -fPIC -s -O3 -march=armv6 -mfloat-abi=hard -mfpu=vfp -DRESAMPLE -DFFMPEG -DVISEXPORT -DDSD -DIR -I./include  mpg.c -c -o mpg.o
In file included from mpg.c:23:0:
./include/mpg123.h:10:19: fatal error: tchar.h: No such file or directory
 #include <tchar.h>
                   ^
compilation terminated.
Makefile:82: recipe for target 'mpg.o' failed
make: *** [mpg.o] Error 1

Ovviamente ho installato le librerie per mpg123.

So che c'è il makefile per il PI, ma io non l'ho mai testato, è quello dello 'standrd'. Se le librerie sono diverse, bisogna frae una cartella nuova, tipo /include_RPI e passarla al compilatore, un po come per il mac.

Per la versione di alsa avete già risolto, scusate.

[antonellocaroli]

Ottimo. Il problema con la 64 è probabilmente socketwrapper, scartata.

Si, credo che il problema é propio quello.

Bisognerebbe controllare la portabilità della SSE2 e della 'normale' su win7 o 8. se va su tutte, decidi tu, io terrei una piccolissima preferenza per la normale, a scanso di possibili problemi su altri processori (AMD?).

intendi una com é adesso e l´altra cambiando set strumenti della piattaforma in Xp v.140?

o cambiare versione piattaforma di destinazione in 8.1?