HQPlayer: Introduzione e Indice argomenti

[bibo01]

Bibo, c'è un grosso problema... l'ultima versione di HQPlayer:
su Debian Stretch non funziona!! Va immediatamente in crash all'avvio:
...

Segnalo e ti faccio sapere

[bibo01]

@UnixMan

Miska ha scritto:

Illegal instruction exception happens when CPU encounters an instruction it doesn't understand (support). What is the CPU in question?

Please provide "model name" and "flags" lines from "cat /proc/cpuinfo" output.

[UnixMan]

Illegal instruction exception happens when CPU encounters an instruction it doesn't understand (support). What is the CPU in question?

Please provide "model name" and "flags" lines from "cat /proc/cpuinfo" output.

per quanto riguarda il mio PC, dove va in crash HQPlayer desktop:

model name      : Pentium(R) Dual-Core  CPU      E5200  @ 2.50GHz
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good nopl aperfmperf pni dtes64 monitor ds_cpl est tm2 ssse3 cx16 xtpr pdcm lahf_lm dtherm

datato, ma fa ancora egregiamente il suo mestiere. Con versioni precedenti di HQP (IIRC avevo testato fino alla 3.12 o 3.13) reggeva anche la conversione da PCM fino a DSD128.

Per quanto riguarda invece NAD, i crash (con il medesimo errore) li ho verificati su un vecchio thin-client, un Fujitsu "Futro S550". Ora non ce l'ho sottomano per verificare i dati esatti, ma la CPU è una (altrettanto vecchia) AMD (Opteron, mi pare... cmq architettura "K8").

Puoi passargli questi dati, relativi alle opzioni utilizzate per compilare un Kernel Linux dedicato:

# cpuinfo2cpuflags-x86
CPU_FLAGS_X86="3dnow 3dnowext mmx mmxext sse sse2 sse3"

# gcc -march=native -E -v - </dev/null 2>&1 | grep cc1
/usr/libexec/gcc/x86_64-pc-linux-gnu/4.9.3/cc1 -E -quiet -v - -march=k8-sse3 -mmmx -m3dnow -msse -msse2 -msse3 -mno-ssse3 -mno-sse4a -mcx16 -msahf -mno-movbe -mno-aes -mno-sha -mno-pclmul -mno-popcnt -mno-abm -mno-lwp -mno-fma -mno-fma4 -mno-xop -mno-bmi -mno-bmi2 -mno-tbm -mno-avx -mno-avx2 -mno-sse4.2 -mno-sse4.1 -mno-lzcnt -mno-rtm -mno-hle -mno-rdrnd -mno-f16c -mno-fsgsbase -mno-rdseed -mprfchw -mno-adx -mfxsr -mno-xsave -mno-xsaveopt -mno-avx512f -mno-avx512er -mno-avx512cd -mno-avx512pf -mno-prefetchwt1 --param l1-cache-size=64 --param l1-cache-line-size=64 --param l2-cache-size=512 -mtune=k8 -fstack-protector-strong

[bibo01]

per quanto riguarda il mio PC, dove va in crash HQPlayer desktop:

model name      : Pentium(R) Dual-Core  CPU      E5200  @ 2.50GHz
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good nopl aperfmperf pni dtes64 monitor ds_cpl est tm2 ssse3 cx16 xtpr pdcm lahf_lm dtherm

datato, ma fa ancora egregiamente il suo mestiere. Con versioni precedenti di HQP (IIRC avevo testato fino alla 3.12 o 3.13) reggeva anche la conversione da PCM fino a DSD128.

Per quanto riguarda invece NAD, i crash (con il medesimo errore) li ho verificati su un vecchio thin-client, un Fujitsu "Futro S550". Ora non ce l'ho sottomano per verificare i dati esatti, ma la CPU è una (altrettanto vecchia) AMD (Opteron, mi pare... cmq architettura "K8").

Puoi passargli questi dati, relativi alle opzioni utilizzate per compilare un Kernel Linux dedicato:

# cpuinfo2cpuflags-x86
CPU_FLAGS_X86="3dnow 3dnowext mmx mmxext sse sse2 sse3"

# gcc -march=native -E -v - &1 | grep cc1
/usr/libexec/gcc/x86_64-pc-linux-gnu/4.9.3/cc1 -E -quiet -v - -march=k8-sse3 -mmmx -m3dnow -msse -msse2 -msse3 -mno-ssse3 -mno-sse4a -mcx16 -msahf -mno-movbe -mno-aes -mno-sha -mno-pclmul -mno-popcnt -mno-abm -mno-lwp -mno-fma -mno-fma4 -mno-xop -mno-bmi -mno-bmi2 -mno-tbm -mno-avx -mno-avx2 -mno-sse4.2 -mno-sse4.1 -mno-lzcnt -mno-rtm -mno-hle -mno-rdrnd -mno-f16c -mno-fsgsbase -mno-rdseed -mprfchw -mno-adx -mfxsr -mno-xsave -mno-xsaveopt -mno-avx512f -mno-avx512er -mno-avx512cd -mno-avx512pf -mno-prefetchwt1 --param l1-cache-size=64 --param l1-cache-line-size=64 --param l2-cache-size=512 -mtune=k8 -fstack-protector-strong

Risposta di Miska:

In this case, the kernel doesn't matter. In first case, CPU is missing the needed minimum features (SSE 4.2) and that's why the process exits. With Windows you can use the 32-bit binary on this particular hardware.

When it comes to networkaudiod, the 32-bit binary should work on PentiumPro level and newer hardware. With networkaudiod 32/64-bit doesn't really matter.

[UnixMan]

In first case, CPU is missing the needed minimum features (SSE 4.2) and that's why the process exits. With Windows you can use the 32-bit binary on this particular hardware.

fantastico... quindi chi ha PC di qualche anno fa se la prende in saccoccia... specie se ha un sistema aggiornato, per cui non può neanche usare una vecchia versione (missing dependencies).

A me personalmente (visto che non uso HQP) la cosa interessa ben poco, ma conosco chi ha acquistato la licenza (per Linux) ed ha un PC della stessa epoca del mio... e che di certo non sarà affatto felice di questa bella novità.

IMHO sarebbe corretto quanto meno mettere a disposizione una versione "legacy" che funzioni anche su PC più datati. Oppure, meglio ancora, fare come fa ad es. "ffmpeg", che riconosce automaticamente le features della CPU su cui sta girando e si regola di conseguenza (in sostanza utilizzando codice diverso).

When it comes to networkaudiod, the 32-bit binary should work on PentiumPro level and newer hardware. With networkaudiod 32/64-bit doesn't really matter.[/I]

OK, quindi in questo caso si può risolvere installando la versione a 32bit. Ma... ne vale la pena? Che differenze ci sono tra le ultime versioni e quella "vecchia" (networkaudiod_3.4.0-29_amd64.deb) per "trusty"?

[bibo01]

Ovviamente, io non posso farci niente.
Suppongo che la versione "legacy" sia quanto meno la 3.13 che usavi prima.
Probabilmente nelle ultime versioni sono stati implementati dei filtri molto più gravosi in termini di cpu - "xtr" è 6 volte più pesante di un "poly-sinc" - che necessitano di tali dipendenze.

Riguardo il nad, non so esattamente. La versione corrente 3.5 rispetto alla vecchia 3.4 ha il supporto di WASAPI (che non t'interessa) e solo "minor improvements and fixes".

[UnixMan]

Ovviamente, io non posso farci niente.

ça va sans dire... però puoi fargli presente che non è carino lasciare qualcuno con un pugno di mosche in mano.

Suppongo che la versione "legacy" sia quanto meno la 3.13 che usavi prima.

il problema è che su sistemi aggiornati (Ubuntu 16.04 / Mint 18.x / Debian Stretch) le vecchie versioni non si possono installare (versioni incompatibili delle librerie qt).

Per giunta, sul sito vedo solo il link all'ultima versione... quelle vecchie sono ancora disponibili da qualche parte?

Probabilmente nelle ultime versioni sono stati implementati dei filtri molto più gravosi in termini di cpu - "xtr" è 6 volte più pesante di un "poly-sinc" - che necessitano di tali dipendenze.

non ne dubito: ho avuto modo di vedere che con i filtri xtr si fa fatica a farlo andare perfino su un i7!

Senza dubbio l'uso dei set di istruzioni avanzate delle CPU di ultima generazione è utile per migliorare le prestazioni. Però resta il problema per chi non ha un hardware adeguato, ma potrebbe continuare ad usarlo con impostazioni meno estreme.

Riguardo il nad, non so esattamente. La versione corrente 3.5 rispetto alla vecchia 3.4 ha il supporto di WASAPI (che non t'interessa) e solo "minor improvements and fixes".

OK, quindi probabilmente nell'immagine che sto preparando per i "Futro" posso lasciarci il 3.4.