HQPlayer: Introduzione e Indice argomenti

[marcoc1712]

I buffer più "critici" - quelli utilizzati nella comunicazione tra PC e DAC via USB - sono gestiti dal sistema e/o dal driver vero e proprio dell'interfaccia. Perciò i casi sono due:

1) tali buffer sono configurabili (e.g. attraverso le impostazioni di WASAPI);

2) tali buffer non sono configurabili, ed in tal caso ASIO4ALL non può farci un bel niente.

Nel primo caso deve esserci modo di farlo direttamente, senza bisogno di usare asio4all.

Nel secondo caso asio4all al più può introdurre un ulteriore buffer intermedio, tra il player e WASAPI. Dell'utilità di un tale buffer intermedio dubito fortemente, ma comunque sarebbe del tutto equivalente ad aumentare le dimensioni del buffer di uscita del player stesso.

BTW: non ricordo: il buffer di uscita di HQPlayer è configurabile? Se lo è, sai dove puoi provare ad agire...

vero per quanto concerne la latenza, ma se il buffer aggiunto è minore fa da collo di bottiglia e l'error rate aumenta di conseguenza.

[bit32]

Ecco la risposta di Miska (che m'immaginavo) al tuo problema con ASIO4ALL:

ASIO4ALL and JPlay need fixing. Other ASIO drivers don't crash.

Don't use ASIO4ALL, but use WASAPI instead if proper ASIO driver is not available...

Grazie bibo01 vorrei proprio sapere quali sono le librerie mancanti...
Va bhe cercherò di trovare una soluzione... se l'autore desse qualche spunto, tutto sarebbe più semplice
Grazie ancora

[bit32]

vero per quanto concerne la latenza, ma se il buffer aggiunto è minore fa da collo di bottiglia e l'error rate aumenta di conseguenza.

Non vorrei dire una bestialità, scusatemi... ma come fa asio4all a funzionare in windows server 2012r2 non essendo presente wasapi?
imoltre funziona sempre e comunque anche su windows 7-8-10 disabilitando i 3 servizi audio fondamentali percheè funzioni wasapi, e cioé:

AudioEndpointBuilder, Audiosrv, MMCSS

Non è che per caso interagisce con kernel streaming???
Saluti, e grazie a tutti
bit32

[bit32]

I buffer più "critici" - quelli utilizzati nella comunicazione tra PC e DAC via USB - sono gestiti dal sistema e/o dal driver vero e proprio dell'interfaccia. Perciò i casi sono due:

1) tali buffer sono configurabili (e.g. attraverso le impostazioni di WASAPI);

2) tali buffer non sono configurabili, ed in tal caso ASIO4ALL non può farci un bel niente.

Nel primo caso deve esserci modo di farlo direttamente, senza bisogno di usare asio4all.

Nel secondo caso asio4all al più può introdurre un ulteriore buffer intermedio, tra il player e WASAPI. Dell'utilità di un tale buffer intermedio dubito fortemente, ma comunque sarebbe del tutto equivalente ad aumentare le dimensioni del buffer di uscita del player stesso.

BTW: non ricordo: il buffer di uscita di HQPlayer è configurabile? Se lo è, sai dove puoi provare ad agire...

Non vorrei dire una bestialità, scusatemi... ma come fa asio4all a funzionare in windows server 2012r2 non essendo presente wasapi?
imoltre funziona sempre e comunque anche su windows 7-8-10 disabilitando i 3 servizi audio fondamentali percheè funzioni wasapi, e cioé:

AudioEndpointBuilder, Audiosrv, MMCSS

Non è che per caso interagisce con kernel streaming???
Saluti, e grazie a tutti
bit32

[UnixMan]

vero per quanto concerne la latenza, ma se il buffer aggiunto è minore fa da collo di bottiglia e l'error rate aumenta di conseguenza.

mmh... mi pare improbabile: se sei in mezzo ad altri due buffer, sulla stessa macchina (quindi stai semplicemente copiando dati da una parte all'altra della RAM), per riuscire a creare problemi bisogna mettercisi d'impegno... ma proprio tanto!

Non è che per caso interagisce con kernel streaming???

Non conosco asio4all nei dettagli ma, visto quando (e perché) è stato creato (molto prima dell'introduzione di WASAPI), mi pare possibilissimo che sia in grado di sfruttare qualsiasi sottosistema audio di windows che trovi disponibile, specie tra quelli più vecchi.

Vai a vedere sul sito e/o fatti una ricerca in rete, sicuramente da qualche parte c'è scritto a cosa si appoggia.

(magari poi scopriamo che non usa affatto WASAPI e così magari si spiegano anche le differenze all'ascolto che hai notato...)

[bibo01]

Non vorrei dire una bestialità, scusatemi... ma come fa asio4all a funzionare in windows server 2012r2 non essendo presente wasapi?
imoltre funziona sempre e comunque anche su windows 7-8-10 disabilitando i 3 servizi audio fondamentali percheè funzioni wasapi, e cioé:

AudioEndpointBuilder, Audiosrv, MMCSS

Non è che per caso interagisce con kernel streaming???
Saluti, e grazie a tutti
bit32

Infatti, funziona in KS... così come JPlay.

Proprio tramite KS, JPlay riesce ad usare buffer piccolissimi.

[bit32]

mmh... mi pare improbabile: se sei in mezzo ad altri due buffer, sulla stessa macchina (quindi stai semplicemente copiando dati da una parte all'altra della RAM), per riuscire a creare problemi bisogna mettercisi d'impegno... ma proprio tanto!


Non conosco asio4all nei dettagli ma, visto quando (e perché) è stato creato (molto prima dell'introduzione di WASAPI), mi pare possibilissimo che sia in grado di sfruttare qualsiasi sottosistema audio di windows che trovi disponibile, specie tra quelli più vecchi.

Vai a vedere sul sito e/o fatti una ricerca in rete, sicuramente da qualche parte c'è scritto a cosa si appoggia.

(magari poi scopriamo che non usa affatto WASAPI e così magari si spiegano anche le differenze all'ascolto che hai notato...)

Ciao, era come sospettavo... si tratta di Kernel Streaming

Qui lo dice proprio "Miska" https://www.computeraudiophile.com/f...comment-508357

Questo è un altro esempio: http://forum.polkaudio.com/discussio...rnel-streaming

Comunque sul mio sistema asio4all suona in modo a dir poco superiore rispetto a wasapi, e per me questo e quello che conta!!! spero che nelle successive versioni Miska metta a posto le cose, in modo che io possa acquistare una licenza.
ps: ci sono anche tanti altri utenti jplay che stanno aspettando la soluzione da parte dell'autore.

saluti
bit32

[bit32]

Infatti, funziona in KS... così come JPlay.

Proprio tramite KS, JPlay riesce ad usare buffer piccolissimi.

Ciao, piccolissimi e e anche grandissimi, si arriva mi pare sopra 1 secondo...

era come sospettavo... si tratta di Kernel Streaming

Qui lo dice proprio "Miska" https://www.computeraudiophile.com/f...comment-508357

Questo è un altro esempio: http://forum.polkaudio.com/discussio...rnel-streaming

Comunque sul mio sistema asio4all suona in modo a dir poco superiore rispetto a wasapi, e per me questo e quello che conta!!! spero che nelle successive versioni Miska metta a posto le cose, in modo che io possa acquistare una licenza.
ps: ci sono anche tanti altri utenti jplay che stanno aspettando la soluzione da parte dell'autore.

saluti
bit32

[bibo01]

https://www.computeraudiophile.com/f...comment=643533

Qui Miska mi ha risposto a proposito di ASIO4ALL... e anche un paio di post più sotto.

---------------------------------------

https://www.computeraudiophile.com/f...comment=643520

Qui una risposta a proposito dei driver ASIO della EMU

[marcoc1712]

mmh... mi pare improbabile: se sei in mezzo ad altri due buffer, sulla stessa macchina (quindi stai semplicemente copiando dati da una parte all'altra della RAM), per riuscire a crear

PLAYER _> DRIVER -> DAC

100/4 100/4 DIPENDE DAL FORMATO, COMUNQUE << 50/2.


1 interrupt da Driver ogni 50, 1 da Player ogni 50, rischio di bufferunderrun minimo (ci sono sempre almeno 50 msec (2 periodi) di 'tampone').


PLAYER -> WRAPPER _> DRIVER -> DAC

100/4 50/2 100/4 DIPENDE DAL FORMATO, COMUNQUE << 50/2.

stessi interrupt di prima per PLAYER + 1 ogni 25 da Wrapper + 1 ogni 25 da Driver.

Rishio di underrun ALTO, diriver chiede di essere riempito quando è a 50, wrapper si svuota completamente per riempirlo, qualsiasi minimo problema si trasforma in un underrun.

Risultato:

Latenza +25 ms
Numero di interrupt 'a regime' = +150%

Qualsiasi 'incidente' nel riempire WRAPPER si trasforma in underrun (improbabile), qualsiasi richiesta extra di DRIVER si trasforma in underrun . Se c'è un minimo drift tra la velocità con cui DAC svuota DRIVER ed il clock che governa le attività di PLAYER, WRAPPER e DRIVER, questo si trasforma in un underrun, con la frequenza dettata dalla dimensione di WRAPPER (50/2), non più di DRIVER, dato che DRIVER è 'tamponato' dalla capacità di WRAPPER: non può ricevere più di 25 per volta senza mandare WRAPPER in UNDERRUN.

E' ovviamente una condizione limite, ma non cambia di molto ogni qual volta si introduca un buffer intermedio la cui dimensione sia inferiore al 'mezzo pieno' del successivo, cosa che è normale avvenga per evitare improponibili aumenti della latenza.

Quanto sopra in bit perfect.

Prova.