Tír Na HiFi

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.

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.

sbgk wrote:

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

jrling wrote:SBGK wrote

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

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

jesuscheung wrote:jplay is such a scam in my opinion. always trying to impress people with technical things.

if they want to impress, i think they should install jplay as a driver. why not. already doing service.

2pc... lan after lan... cpu locking...
if they actually use their ears, simple coding sounds 10 times better.

if you want to know how wrong jplay sound?
go to your kids music school. and listen to actual musical instruments.

sbgk wrote: squeezelite sounds better running as a service. slimserver sounds better running as a service etc

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