MQN

[nige2000]

Can confirm that stopping MQn doesn't work after using Audiophile's Optimizer. It deactivates a service that is needed by taskkill command (but don't know which, so far). If pressing X in MQnControl.exe this Executable is terminated, but MQnPlay.exe is not.

whats it sound like?

we will need to be able to stop playback

To me it sounds very, very good. I've been beta tester for Audiophil's Optimizer for several weeks now and think that finally it has reached a really professional level.

But of course, we need to be able stopping playback! I've talked with Audiophil about this issue and I'm sure he will find out the relevant service(s) and consider them with the next version. Furthermore it would be possible to replace the taskkill command with something that works better.

With the 1.21beta could it be got working to stop playback
or will we be waiting for release version

[sbgk]

what other instruction could be used, presumably you can still stop processes manually ?

[Peter Stockwell]

I find that it takes too long (Let's say an album's worth of tunes from the NAS) to load, to be a real winner. TBH, I'm not yet convinced it's any better than JRiver MC19 when JRiver is fed the same files. JRiver runs faster, probably because it loads one song at a time into memory.

Should have said JRiver loads faster, but moving the files to local (SSD) Disk D before loading up MQn makes the load time issue go away. So that one is the network at mine, NAS on a gigabyte Network switch, but connected via Homeplug to router/modem and NUC connected directly to modem. The homeplug connection is the problem there.

I'm coming around, I think tonal & ambient information is better rendered by MQn, compared to JRiver MC19 memory playback.

[taggart]

With the 1.21beta could it be got working to stop playback
or will we be waiting for release version

At least with current 1.21beta I couldn't get it to work without issues. I replaced taskkill command in both batches with a Process.exe call which works if the processes (werfault.exe, mqnplay.exe, mqncontol.exe, cmd.exe) are killed in correct order. But the X key within MQnControl.exe still doesn't work because it is part of sbgk's code and isn't influenced by these changes. Maybe best to wait what the next beta of optimizer or the final version 1.21 brings.

[taggart]

what other instruction could be used, presumably you can still stop processes manually ?

Yes, still possible to kill mqn processes manually. And because Process.exe works too, it should be possible to get it to work within mqncontrol.exe, when using Win32 API. Outside of MQnControl.exe I'll address this issue with the planed alternative of mqn.bat.

[nige2000]

I find that it takes too long (Let's say an album's worth of tunes from the NAS) to load, to be a real winner. TBH, I'm not yet convinced it's any better than JRiver MC19 when JRiver is fed the same files. JRiver runs faster, probably because it loads one song at a time into memory.

Should have said JRiver loads faster, but moving the files to local (SSD) Disk D before loading up MQn makes the load time issue go away. So that one is the network at mine, NAS on a gigabyte Network switch, but connected via Homeplug to router/modem and NUC connected directly to modem. The homeplug connection is the problem there.

I'm coming around, I think tonal & ambient information is better rendered by MQn, compared to JRiver MC19 memory playback.

there are tracks that jriver can play poorly that mqn plays well, because jriver gets it difficult to keep the timing right

Jkenny mentioned one of these tracks
jriver makes a mess of it

The thing is it is more noticeable in some tracks than in others. The track that I use & find it most noticeable on is the Oscar Peterson track 03 "My One & Only Love" - probably because it has lots of notes :) - the piano playing is fast (allegro?). With MQN I hear a very distinct & realistic rendition. With Foobar it is just that bit more indistinct. I'm happy to provide a 30sec or 1 min download link of this track (I don't think this breaches any copyright laws, once it is for research/educational purposes, right?)

[sbgk]

what other instruction could be used, presumably you can still stop processes manually ?

Yes, still possible to kill mqn processes manually. And because Process.exe works too, it should be possible to get it to work within mqncontrol.exe, when using Win32 API. Outside of MQnControl.exe I'll address this issue with the planed alternative of mqn.bat.

what command does process.exe use to top the process ?

[sbgk]

In this situation, MQN exists in a software layer, several layers above a bunch of other software, correct?. Perhaps its the randomness of the MQN/SW filling the buffer that in turn feeds the SPDIF transmitter that is at issue here? (Even though it always provides enough samples for the transmitter to work on)

I'm really struggling to see how MQN affects timing and I'm just trying to tease out a few ideas no matter how unlikely they are.

If MQN really is different, I think the causes are elsewhere.

Dave

The usage scenario with MQn is mostly via USB, using the asynch protocol, so in theory I think the DAC interface is driving the demand for packets from the USB bus, which in turn is pulling samples into the buffer from the Wasapi service (it gets so complicated in Windows at this level, so I could be off beam). At some level MQn is providing those samples to the WASAPI service.

What is really unclear to me is at what point the samples get turned into USB packets, which are formatted according the a generic UAC spec and contain headers and all the usual network layer stuff. My assumption is that the cpu does that packing and formatting because it has access to the relevant data and gets the interrupts from the USB interface coming in from the DAC. And we talk about Wasapi as an entity when in reality it is just more cycles on the CPU.

I can confirm the differences exist when I am building the different versions on my laptop using the laptop speakers (so no USB involved), I play a track as part of the profile guided optimisation. JK has also confirmed he can hear a difference when just using laptop speakers.

[DaveF]

dunno how it will sound on your "beast" of a pc as its a very busy board,
but i think youll be able to hear the difference between players

Since its a watercooled PC, Im guessing MQN will give me that liquid midrange that I've always wanted. Or perhaps transparent? ;-)

[nige2000]

dunno how it will sound on your "beast" of a pc as its a very busy board,
but i think youll be able to hear the difference between players

Since its a watercooled PC, Im guessing MQN will give me that liquid midrange that I've always wanted. Or perhaps transparent? ;-)

if it leaves you wanting to go to the the toilet, maybe time to go passive on another build after hearing how marvellous MQn is:)