play is doing some sort of dma transfer, so should be better, together with large memory pages and the player as a service it should be a lot better. you can set asio to a very small buffer size and get more perceived detail, but I've never found it to be musical.
Whilst I have not listened to JPlay and I am aware of the misgivings many have about JPlay's SQ here, surely the features quoted - MQn as a service, DMA transfer, WDM-KS (and may be large memory pages, but I wouldn't know) are potentially where MQn ought to be going now that we are getting pretty small changes in the latest 4.xx versions?
Easy for me as a non-coder to say, but there would seem to be more 'low hanging fruit' in those areas than continuing refinement of WASAPI MQn?
What is scary is that starting from a MQn base of 4.74 or thereabouts, and implementing those additional enhancements, how good would the SQ end up being?
Jonathan
Maplin XM21X 12V float charging A123 26650 LiFePO4 battery/Maxwell Supercap PSU for Mitac PD10-BI J1900 Bay Trail, WTFPlay, Hiface Evo, Bow Technologies 1704 NOS DAC, StereoKnight TVC, Quad II monoblocks, ZU Audio Druid Mk4/Method Sub
why would a service sound better than a process anyway?
service has a lot of extra junks. security group, failure handling...
a service is also embedded within a svchost process... all these complications...
i bet if service sounds better, that would add 1% SQ.
think i once tweak mmcss and other audio services to have kernel or driver privileges, SQ didn't increase.
sound was tightened, texture seems improved, impressive at first, but incorrectly, because sound was also hardened. not natural.
jesuscheung wrote:why would a service sound better than a process anyway?
service has a lot of extra junks. security group, failure handling...
a service is also embedded within a svchost process... all these complications...
i bet if service sounds better, that would add 1% SQ.
think i once tweak mmcss and other audio services to have kernel or driver privileges, SQ didn't increase.
sound was tightened, texture seems improved, impressive at first, but incorrectly, because sound was also hardened. not natural.
squeezelite sounds better running as a service. slimserver sounds better running as a service etc
jesuscheung wrote:why would a service sound better than a process anyway?
service has a lot of extra junks. security group, failure handling...
a service is also embedded within a svchost process... all these complications...
i bet if service sounds better, that would add 1% SQ.
think i once tweak mmcss and other audio services to have kernel or driver privileges, SQ didn't increase.
sound was tightened, texture seems improved, impressive at first, but incorrectly, because sound was also hardened. not natural.
squeezelite sounds better running as a service. slimserver sounds better running as a service etc
play is doing some sort of dma transfer, so should be better, together with large memory pages and the player as a service it should be a lot better. you can set asio to a very small buffer size and get more perceived detail, but I've never found it to be musical.
Whilst I have not listened to JPlay and I am aware of the misgivings many have about JPlay's SQ here, surely the features quoted - MQn as a service, DMA transfer, WDM-KS (and may be large memory pages, but I wouldn't know) are potentially where MQn ought to be going now that we are getting pretty small changes in the latest 4.xx versions?
Easy for me as a non-coder to say, but there would seem to be more 'low hanging fruit' in those areas than continuing refinement of WASAPI MQn?
What is scary is that starting from a MQn base of 4.74 or thereabouts, and implementing those additional enhancements, how good would the SQ end up being?
Jonathan
if you listen to jplay, maybe it isn't the answer.
jrling wrote:Aleg - big thanks for keeping up such active interest in reviewing and reporting on the new versions as they flood out. Your insightful and descriptive comments are really most helpful to me (and many others I expect). Are you by chance a professional audio engineer?
One question if I may - what settings are you using in Pro Audio Clock Rate with the different 128, 256, 512 versions? I am using 3.61 512 Control and had Clock Rate at 448 as you suggested. But with SSE2/3 512 MQnplay versions (I do not have avx so many versions have to pass me by) I moved Clock Rate to 512 with slightly better results I think and have left it there since.
I am assuming that Gordon is not now changing Clock Rate within his code, which was the case a while back, I believe.
Thank you as always
Jonathan
think the mqnplay is still changing clockrate which i could really live without
id imagine its more difficult to hear the differences with sse2 versions as it doesnt have the same agility (ability to display micro detail) as avx
with avx the differences are still noticeable with two or three comparisons
ks probably needs alot of mucking out,
think were close to a really good version of avx mqn
improvement is infinite
were going to have to stop somewhere
sd card player, modded soekris dac, class a lifepo4 amp or gb class a/b amp, diy open baffle speakers based on project audio mundorf trio 10's
nige2000 wrote:
...
ks probably needs alot of mucking out,
think were close to a really good version of avx mqn
improvement is infinite
were going to have to stop somewhere
last time i heard ks vs wasapi, ks has more quantity in bass and seems smoother. that's was it.