DSD in LMS con SOX

[UnixMan]

Mi servirebbe una prova veloce:
[...]
funzionano tutti? (perchè li accetta tutti, ma non so quali suonano e quali no)

nel mio caso (e se non erro in tutti quelli provati finora) il formato giusto è "u32be".

Le stringhe corrette:

-D :u32be
-D 0:u32be
-D 1:u32be

funzionano tutte come previsto.

Quelle errate:

-D u32be
-D u32be:1
-D u32be:0

vengono accettate senza protestare(*), ma il parametro viene ignorato. In sostanza è come se si fosse specificato solo "-D" e quindi prende il default, cioè DOP:

*** /tmp/squeezelite.log ***
squeezelite-R2 -n R2@spmc -C 1 -D u32be -o hw:CARD=D20 -V DIYINHK USB Audio 2.0  -r 768000 -s 127.0.0.1 -m 00:1c:c0:37:22:73 -b 102400:102400 -a 499:3 -p 89 -d all=info -d slimproto=warn -f /tmp/squeezelite.log 
[...]
[00:09:05.295868] output_thread:697 open output device: hw:CARD=D20
[00:09:05.295915] alsa_open:367 opening device at: 44100
[00:09:05.296048] alsa_open:440 opened device hw:CARD=D20 using format: S32_LE sample rate: 44100 mmap: 1
[00:09:05.296082] alsa_open:531 buffer: 499 period: 3 -> buffer size: 22005 period size: 7335
[00:09:05.515491] _read_header:134 DSDIFF version: 1.5.0.0
[00:09:05.515634] _read_header:138 sample rate: 5644800
[00:09:05.515642] _read_header:142 channels: 2
[00:09:05.515649] _read_header:145 found dsd len: 18446744073709551615
[00:09:05.515655] dsd_decode:765 setting track_start
[00:09:05.515662] dsd_decode:819 DSD128 stream, format: DOP, rate: 352800Hz

[00:09:05.683420] _output_frames:61 start buffer frames: 261087
[00:09:05.683472] _output_frames:146 track start sample rate: 352800 replay_gain: 0
[00:09:05.693505] output_thread:697 open output device: hw:CARD=D20
[00:09:05.709728] alsa_open:367 opening device at: 352800
[00:09:05.710000] alsa_open:440 opened device hw:CARD=D20 using format: S32_LE sample rate: 352800 mmap: 1
[00:09:05.710022] alsa_open:531 buffer: 499 period: 3 -> buffer size: 131070 period size: 43690

(analogamente per gli altri deu casi).

(*) com'è ovvio, visto che nel codice attuale non ci sono controlli di quel genere. Non è certo un grosso problema, ma forse non sarebbe male metterceli, in modo che in caso di parametri errati se ne esca con un msg di errore appropriato...


P.S.: è tutto stasera che suona... liscio come l'olio. Quindi direi che posso confermare che il problema erano le priorità.

[antonellocaroli]

nel mio caso (e se non erro in tutti quelli provati finora) il formato giusto è "u32be".

Le stringhe corrette:

-D :u32be
-D 0:u32be
-D 1:u32be

funzionano tutte come previsto.

Quelle errate:

-D u32be
-D u32be:1
-D u32be:0

vengono accettate senza protestare(*), ma il parametro viene ignorato. In sostanza è come se si fosse specificato solo "-D" e quindi prende il default, cioè DOP:

*** /tmp/squeezelite.log ***
squeezelite-R2 -n R2@spmc -C 1 -D u32be -o hw:CARD=D20 -V DIYINHK USB Audio 2.0  -r 768000 -s 127.0.0.1 -m 00:1c:c0:37:22:73 -b 102400:102400 -a 499:3 -p 89 -d all=info -d slimproto=warn -f /tmp/squeezelite.log 
[...]
[00:09:05.295868] output_thread:697 open output device: hw:CARD=D20
[00:09:05.295915] alsa_open:367 opening device at: 44100
[00:09:05.296048] alsa_open:440 opened device hw:CARD=D20 using format: S32_LE sample rate: 44100 mmap: 1
[00:09:05.296082] alsa_open:531 buffer: 499 period: 3 -> buffer size: 22005 period size: 7335
[00:09:05.515491] _read_header:134 DSDIFF version: 1.5.0.0
[00:09:05.515634] _read_header:138 sample rate: 5644800
[00:09:05.515642] _read_header:142 channels: 2
[00:09:05.515649] _read_header:145 found dsd len: 18446744073709551615
[00:09:05.515655] dsd_decode:765 setting track_start
[00:09:05.515662] dsd_decode:819 DSD128 stream, format: DOP, rate: 352800Hz

[00:09:05.683420] _output_frames:61 start buffer frames: 261087
[00:09:05.683472] _output_frames:146 track start sample rate: 352800 replay_gain: 0
[00:09:05.693505] output_thread:697 open output device: hw:CARD=D20
[00:09:05.709728] alsa_open:367 opening device at: 352800
[00:09:05.710000] alsa_open:440 opened device hw:CARD=D20 using format: S32_LE sample rate: 352800 mmap: 1
[00:09:05.710022] alsa_open:531 buffer: 499 period: 3 -> buffer size: 131070 period size: 43690

(analogamente per gli altri deu casi).

(*) com'è ovvio, visto che nel codice attuale non ci sono controlli di quel genere. Non è certo un grosso problema, ma forse non sarebbe male metterceli, in modo che in caso di parametri errati se ne esca con un msg di errore appropriato...


P.S.: è tutto stasera che suona... liscio come l'olio. Quindi direi che posso confermare che il problema erano le priorità.

Lo stesso in win.
accetta sia -D :u32be -D 0:u32be -D 1:u32be che -D :u32le -D 0:u32le -D 1:u32le
ed esce in dsd...solo che poi é solo fruscio

[UnixMan]

Lo stesso in win.
accetta sia -D :u32be -D 0:u32be -D 1:u32be che -D :u32le -D 0:u32le -D 1:u32le
ed esce in dsd...solo che poi é solo fruscio

in win il bug è più serio... IIRC avevamo già notato che nel codice manca qualche "#IFDEF", e viene compilato parte del codice per ALSA anche se non dovrebbe.

[marcoc1712]

Grazie a tutti.

[marcoc1712]

in win il bug è più serio... IIRC avevamo già notato che nel codice manca qualche "#IFDEF", e viene compilato parte del codice per ALSA anche se non dovrebbe.

Dove?

[marcoc1712]

nel mio caso (e se non erro in tutti quelli provati finora) il formato giusto è "u32be".

Le stringhe corrette:

-D :u32be
-D 0:u32be
-D 1:u32be

funzionano tutte come previsto.

Quelle errate:

-D u32be
-D u32be:1
-D u32be:0

vengono accettate senza protestare(*), ma il parametro viene ignorato. In sostanza è come se si fosse specificato solo "-D" e quindi prende il default, cioè DOP:

(*) com'è ovvio, visto che nel codice attuale non ci sono controlli di quel genere. Non è certo un grosso problema, ma forse non sarebbe male metterceli, in modo che in caso di parametri errati se ne esca con un msg di errore appropriato...

Non sono previsti controlli sul valore dei parametri multipli nemmeno nei casi già presenti (es.alsa), bisognerebbe ristrutturare tutta la sezione, ma...

[marcoc1712]

Lo stesso in win.
accetta sia -D :u32be -D 0:u32be -D 1:u32be che -D :u32le -D 0:u32le -D 1:u32le
ed esce in dsd...solo che poi é solo fruscio

quando dici che esce in dsd è perché il DAC lo riconosce come tale?

[antonellocaroli]

quando dici che esce in dsd è perché il DAC lo riconosce come tale?

In effetti quello non l ho controllato

ho visto nel log di sq che era dsd
Ma visto il solo fruscio presumo che non gli arrivi un formato riconosciuto

[UnixMan]

Dove?

per cominciare, proprio il "parser" dei parametri... c'è solo un "#if DSD", poi il codice è unico per tutti i sistemi. Va da sé che (almeno al momento) andrebbero fatti parser diversi con un "#if ALSA".

Da verificare anche dsd.c : se non ricordo male, anche lì ALSA e PA non vengono trattati in modo diverso.

Non sono previsti controlli sul valore dei parametri multipli nemmeno nei casi già presenti (es.alsa), bisognerebbe ristrutturare tutta la sezione, ma...

...al momento, meglio lasciar perdere.

quando dici che esce in dsd è perché il DAC lo riconosce come tale?

ne dubito. Casomai il contrario: esce rumore perché manda dati DSD che vengono trattati come PCM...

Il punto è che dovrebbe uscire DoP, e quindi dovrebbe funzionare.

Filippo, non sarà che la catena "a valle" non era bit-perfect? (volume e/o mixer, ecc).

[antonellocaroli]

Il punto è che dovrebbe uscire DoP, e quindi dovrebbe funzionare.

Filippo, non sarà che la catena "a valle" non era bit-perfect? (volume e/o mixer, ecc).

Nono la catena a valle non centra...

ma stasera controllo meglio, io penso che SQ esce in DSD nativo (con i parametri per alsa?) ma non credo che PA lo interpreti tale...e non saprei Cosa arriva al dac o ai Driver asio...

Perché dovrebbe uscrire DoP?