Indice
Pubblicazioni
Cerca
Ultime immagini
Registrati
Accedi
allora, ho ottenuto risultati interessanti....
premessa: fb2k versione 1.1.10, ultimi driver m2tech, eeepc asus 1015pe dedicato e minimizzato con fidelizer in modalita' extremist, 2GB, M$ Win Starter 32b
confermo che con wasapi non e' possibile utilizzare i driver m2tech impostando i 32b, l'errore e' il solito "Unrecoverable playback error: Unsupported stream format: 384000 Hz / 32-bit / 2 channels"
non mi ero pero' mai accorto che impostando i 24b e' possibile andare oltre i 192k..... o per meglio dire, non mi ero mai accorto che la nuova versione di fb2k permettesse di farlo.... sono abbastanza sicuro (a meno che l'eta' non mi inizi a fare brutti scherzi....) di aver provato all'inizio con una versione di fb2k intorno alla 0.9.qualcosa, e sono altresi' abbastanza sicuro che wasapi non ne voleva sapere di andare oltre i 192, con nessuna profondita' di bit....
mea culpa....
impostando i 24b inizialmente mi ha dato un errore che non avevo ancora visto: "Unrecoverable playback error: Unsupported buffer size (0x88890016)".... uso il buffer di fb2k (non la cache di cui si discuteva, proprio il buffer che si trova nelle proprieta' di output e che in sostanza e' la coda dei sample da processare) al max possibile (16s), cosa evidentemente non gradita a wasapi (comportamento perfetto invece con ks).
ok, lascio i 24b e porto il buffer al default (1s), magia compaiono i 384 sul fido young!!!!! riproduzione molto buona, senza interruzioni. visto che mi ci trovo con SMP pro isolo fb2k su un thread per misurare il carico della elaborazione (abbastanza pesante: grap eq per la room correction, una prima passata di sox per portare lo stream a 192 - quindi resampling asincrono visto che suonava un cd - e una seconda passata a 2x per portarlo a 384), e il risultato mi lascia perplesso: meno del 40% mentre ks viaggia sopra al 50%. ok, non mi arrendo e porto anche ks a 24b, risultato: ks cala lievemente passando intorno ad una occupazione del 50%, ma sempre visibilmente superiore a quella di wasapi!!!!!!
a questo punto non posso far altro che con capo cosparso di abbondante cenere ammettere che i miei ragionamenti teorici erano SBAGLIATI (quanno ce vo' ce vo'... ammetto sempre i miei errori), wasapi e' visibilmente piu' leggero di ks e puo' far girare tranquillamente i 384k. ora mi tocchera' ricominciare daccapo con gli ascolti a confronto per vedere se vale la pena lasciare ks per i 32b (a naso facendo eq mi sa che gli 8 bit in piu' fanno comodo...) con un buffer ampio, oppure se all'ascolto wasapi a 24b e 1s (ho trovato che supporta fino a 2s max) di buffer e' uguale/superiore... ho sempre trovato ks superiore, piu' definito e dettagliato, ma ora mi ritocchera' ricomnciare tutto daccapo....
qui sotto una pic (scusate la qualita' schifosa) delle due situazioni a confronto: stesso brano, stessi settigs, nel cerchiato a destra si vede il carico con ks, a sx con wasapi.
premessa: fb2k versione 1.1.10, ultimi driver m2tech, eeepc asus 1015pe dedicato e minimizzato con fidelizer in modalita' extremist, 2GB, M$ Win Starter 32b
confermo che con wasapi non e' possibile utilizzare i driver m2tech impostando i 32b, l'errore e' il solito "Unrecoverable playback error: Unsupported stream format: 384000 Hz / 32-bit / 2 channels"
non mi ero pero' mai accorto che impostando i 24b e' possibile andare oltre i 192k..... o per meglio dire, non mi ero mai accorto che la nuova versione di fb2k permettesse di farlo.... sono abbastanza sicuro (a meno che l'eta' non mi inizi a fare brutti scherzi....) di aver provato all'inizio con una versione di fb2k intorno alla 0.9.qualcosa, e sono altresi' abbastanza sicuro che wasapi non ne voleva sapere di andare oltre i 192, con nessuna profondita' di bit....
mea culpa....
impostando i 24b inizialmente mi ha dato un errore che non avevo ancora visto: "Unrecoverable playback error: Unsupported buffer size (0x88890016)".... uso il buffer di fb2k (non la cache di cui si discuteva, proprio il buffer che si trova nelle proprieta' di output e che in sostanza e' la coda dei sample da processare) al max possibile (16s), cosa evidentemente non gradita a wasapi (comportamento perfetto invece con ks).
ok, lascio i 24b e porto il buffer al default (1s), magia compaiono i 384 sul fido young!!!!! riproduzione molto buona, senza interruzioni. visto che mi ci trovo con SMP pro isolo fb2k su un thread per misurare il carico della elaborazione (abbastanza pesante: grap eq per la room correction, una prima passata di sox per portare lo stream a 192 - quindi resampling asincrono visto che suonava un cd - e una seconda passata a 2x per portarlo a 384), e il risultato mi lascia perplesso: meno del 40% mentre ks viaggia sopra al 50%. ok, non mi arrendo e porto anche ks a 24b, risultato: ks cala lievemente passando intorno ad una occupazione del 50%, ma sempre visibilmente superiore a quella di wasapi!!!!!!
a questo punto non posso far altro che con capo cosparso di abbondante cenere ammettere che i miei ragionamenti teorici erano SBAGLIATI (quanno ce vo' ce vo'... ammetto sempre i miei errori), wasapi e' visibilmente piu' leggero di ks e puo' far girare tranquillamente i 384k. ora mi tocchera' ricominciare daccapo con gli ascolti a confronto per vedere se vale la pena lasciare ks per i 32b (a naso facendo eq mi sa che gli 8 bit in piu' fanno comodo...) con un buffer ampio, oppure se all'ascolto wasapi a 24b e 1s (ho trovato che supporta fino a 2s max) di buffer e' uguale/superiore... ho sempre trovato ks superiore, piu' definito e dettagliato, ma ora mi ritocchera' ricomnciare tutto daccapo....
qui sotto una pic (scusate la qualita' schifosa) delle due situazioni a confronto: stesso brano, stessi settigs, nel cerchiato a destra si vede il carico con ks, a sx con wasapi.
