Visual studio 2012 c++ and wasapi minimalist player

[sbgk]

any updates?

hi, yes, just having a bit of a battle with my mf vlink 192, have 16/44 and 24/96 working, so shall probably post an update at the weekend. HDMI must be more tolerant, have had to go back to original getbuffer sequence for usb to work ie no preloading, not sure it makes a difference. My original thought that the new vs2012 parallelisation, fast float transendentals and compiling for multicore would improve the sound were fruitless and they actually made the sound worse, but am still impressed with the vs2012 optimisations vs vs2010. thanks to morioyamamoto2002 for excellent help. cheers

[sbgk]

So you did not and are not interested in verifying your technically highly unlikely findings. Why was it expectable...

i use prolonged testing as my verification, I find people use the blind testing gambit as a way to prevent others making progress. My hearing changes hour by hour depending on how tired I am, time of day etc, by proposing blind testing you are assuming that ones hearing is constant. Suppose I discounted a setting because my hearing was off one day, according to you that is a more valid test than prolonged testing. If the aim is to reduce digital noise then it is quite easy to distinguish between it's presence or not. At least I am willing to post different versions of the player so people can test it for themselves.

[sbgk]

any updates?

made quicker progress than expected, uploaded mqn.exeusb, just rename it. https://rapidshare.com/#users|45980080|0ae609ce616a35c8de7ac5fda4b6194c|11541 Perhaps my learned friends could direct their energies to explaining why different players sound different rather than belittling my efforts without even trying the player, though I suppose this closed mindset is why I have had to write my own player.

[sbgk]

made quicker progress than expected, uploaded mqn.exeusb, just rename it. https://rapidshare.com/#users|45980080|0ae609ce616a35c8de7ac5fda4b6194c|11541 Perhaps my learned friends could direct their energies to explaining why different players sound different rather than belittling my efforts without even trying the player, though I suppose this closed mindset is why I have had to write my own player.

Have uploaded a non profile guided optimised version called mqn.exenopgo as someone said that compiling would have no affect, compare with mqn.exeusb which does have program guided optimisation applied. Also have uploaded a version that uses memcpy rather than A_memcpy called mqn.exenopgomemcpy, compare this with mqn.exenopgo. I find the difference larger than I expected and the memcpy version is almost unlistenable to compared with the subleties produced by the A_memcpy version (mqn.exenopgo or mqn.exeusb).

[John Dot]

Thanks, now it works

Truly great sound.

[sbgk]

Thanks, now it works

Truly great sound.

 

thanks

[sbgk]

Thanks, now it works Truly great sound.

realised there was quite a difference in sound between my hdmi version and usb version, I put this down to the preloading of the buffer in the hdmi version, had a look at the usb render loop and worked out how to preload for usb. Have uploaded a new file mqn.exeusbpreload that sounds a bit better than the original mqn.exeusb version https://rapidshare.com/#users|45980080|0ae609ce616a35c8de7ac5fda4b6194c|11541

[sbgk]

Seems to be somewhat similar to my own, but mine has the advantage of knowing size of the smallest possible copy unit. So instead of bytes the copy size is defined in samples and each different sample size has it's own optimized copy. These generic memcpy() implementations have number of problems: 1) they must be able to handle sizes that are not multiples of sample size 2) they must be able to handle copies to/from non cache line aligned addresses

I use memory page aligned buffer sizes ie 4096 for 44/48/88/96 and 8192 for >96k, there are no variables in the loop each format has it's own hard coded loop.

[Miska]

I use memory page aligned buffer sizes ie 4096 for 44/48/88/96 and 8192 for >96k, there are no variables in the loop each format has it's own hard coded loop.

 

Can the copy algorithm assume some specific alignment and copy unit size? Point is to get rid of any conditionals that could potentially cause mis-predicted branch and pipeline flush. Just assume any if() in the code to be slow and make your fast path have none.

 

Usually generic memcpy() cannot make assumptions of alignment of source or destination address nor the smallest copy unit size.

 

Nice thing with compilers such as gcc is that those can actually analyze the code and inline a version optimized for the particular case. For example if compiler can see that the copy is small it can inline an unroll the entire copy if that's optimal way.

[sbgk]

Have uploaded a further iteration of mqn.exe, found 3 optimisations which had been overlooked, instruments now sound more realistic and overall performance has increased.

 

mqn.exev1 is for hdmi and realtek driver on laptop

mqn.exev2 is for usb

 

https://rapidshare.com/#users|45980080|0ae609ce616a35c8de7ac5fda4b6194c|11541

 

Had this feedback from J Irling, who came to it from MPD, this was before the latest changes

 

 

SBGK Player [MQn]

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

I am one of the ones who have tried SBGK's MQn. I am very pleased with the

SQ on Win 7 64 completely 'out of the box' not optimised at all and so I am

sure there is more quality to be extracted.

 

I have come from CPlay, Foobar JRiver on Windows and mpdPup on Linux - the

latter being the best to my ears until MQn came along.

 

 

It only requires .NET 4 Framework installing if you don't have it already.

No Registry or other intrusive stuff to install. So what's against giving

it a whirl?

 

SBGK has certainly put an enormous effort into his focussed aim of

optimising the best Audiophile player code and I for one thought it well

worth giving it a go. I don't regret it and am very appreciative of his

efforts.

[sbgk]

If I posted the assembly code would that be of use ?

 

The reason I looked for a memcpy replacement was that I first developed the player just reading from a file to the device buffer, then I tried reading from a ram disk which sounded better, but when I tried memory playback the sound was more digital, which is typical of players that have a memory option eg foobar2000, jrmc, even JPlay. So that got me searching for a better solution, which involved virtualalloc, memory aligned buffers, setting page protection to 0x00 post load, and A_memcpy. Don't know why memcpy sounds as it does, as you said earlier maybe produces electrical noise.

[sbgk]

Have uploaded a further iteration of mqn.exe, found 3 optimisations which had been overlooked, instruments now sound more realistic and overall performance has increased. mqn.exev1 is for hdmi and realtek driver on laptop mqn.exev2 is for usb https://rapidshare.com/#users|45980080|0ae609ce616a35c8de7ac5fda4b6194c|11541 the latest versions are mqn.exev1, v2 and v3, they all have the latest optimisations, which were MFC - use standard windows libraries, remove iostream library include and switch off rtti. v1 is a preload version for hdmi or realtek driver eg playing on laptop speakers v2 is a preload version for usb, may not play on all devices. v3 is a normal load sequence and can play on hdmi, laptop, usb. I think the sound is slightly muddier than with v1/v2. the load sequence loop is event trigger, get next device buffer, load buffer, release buffer - for some devices the next buffer of sound data is released at a different point to others v1 is event, release, get, load - data sent to device at release v2 is event, load, release, get - data sent to device at event v3 is event, get, load, release - data sent to device at release so v2 should sound the best, that's if the device can handle the sequence.

[sbgk]

Have uploaded a further iteration of mqn.exe, found 3 optimisations which had been overlooked, instruments now sound more realistic and overall performance has increased.

 

mqn.exev1 is for hdmi and realtek driver on laptop

mqn.exev2 is for usb

 

https://rapidshare.com/#users|45980080|0ae609ce616a35c8de7ac5fda4b6194c|11541

 

the latest versions are mqn.exev1, v2 and v3, they all have the latest optimisations, which were MFC - use standard windows libraries, remove iostream library include and switch off rtti.

 

v1 is a preload version for hdmi or realtek driver eg playing on laptop speakers

v2 is a preload version for usb, may not play on all devices.

v3 is a normal load sequence and can play on hdmi, laptop, usb. I think the sound is slightly muddier than with v1/v2.

 

the load sequence loop is event trigger, get next device buffer, load buffer, release buffer - for some devices the next buffer of sound data is released at a different point to others

 

v1 is event, release, get, load - data sent to device at release

v2 is event, load, release, get - data sent to device at event

v3 is event, get, load, release - data sent to device at release so v2 should sound the best, that's if the device can handle the sequence.

[sbgk]

uploaded a mqn.exev2.1 (usb devices) which uses intel specific files. The result is a slightly improved sound, less lean sounding. The old v2.0 is still there for comparison.

 

https://rapidshare.com/#users|45980080|0ae609ce616a35c8de7ac5fda4b6194c|11541

 

I tried using reclock and shanpcaudio reclock enhancements, initially an improvement, but soon gave me a headache, prefer the natural sound of MQn.

 

Interestingly he is selling the his high end player for £180, anyone tried it ? There is a free version of lesser quality, both integrated with foobar2000.

 

ShanPCAudio_????

 

He has an article further down the page where he mentions the intel c++ redistributable files

[sbgk]

Thanks, now it works

Truly great sound.

 

1 version ago I made 3 optimisation changes, feedback received has pointed to one of these affecting the sound adversely, so have rebuilt the 3 versions with the best sounding option ie use MFC in a static library.

 

Have rationalised the download folder to just hold the latest versions and moved everything else to an archive folder.

 

The use of MFC setting is completely counter intuitive as MQn doesn't use MFC, my thinking is that there are some windows libraries that are used and they sound better when imported as part of the static MFC library than when shared windows libraries are used.

 

Hopefully, that is the last of the changes as it now sounds pretty sweet.

 

Thanks to John Dot for pointing out the sound had got leaner.

 

have also uploaded a readme file

 

https://rapidshare.com/#users|45980080|0ae609ce616a35c8de7ac5fda4b6194c|11541

[sbgk]

The one test I didn't do was current version which uses intel libraries vs current version built with VS2012 libraries, hard to decide which one is better, the intel ones seem to have better definition and the VS2012 sounds sweeter. Have posted mqn.exev2.2VS2012 for comparison against v2.2.

[sbgk]

Have uploaded instructions on how to integrate MQn with foobar2000 mqnfoobar.txt and mqnfoobar.bmp

[John Dot]

Can not manage MQn to start via Foobar.

Error: "paste" is not recognized as an internal or external command, operable program or batch file

and "System can't find file File1.txt"

[sbgk]

Can not manage MQn to start via Foobar.

Error: "paste" is not recognized as an internal or external command, operable program or batch file

and "System can't find file File1.txt"

 

did you see the bit in the instructions to change the directory in the

cd c:\musicplayer line in mqn.bat file to the directory where mqn.bat etc is located ? that might be the issue.

[taggart]

Hi, I've tried latest version which works good with internal soundcard. But does not work at all with my Audioquest Dragonfly. I assume that's due to the Dragonfly only accepts 24bit stream. Sbgk, do you have any idea to get it to work anyway?

[John Dot]

did you see the bit in the instructions to change the directory in the

cd c:\musicplayer line in mqn.bat file to the directory where mqn.bat etc is located ? that might be the issue.

 

Sure, tried it twice from scratch - same result. The issue might be related to Windows environment variables.

 

@taggart, I think MQn uses first device from the list, not the one set to default.

[sbgk]

Sure, tried it twice from scratch - same result. The issue might be related to Windows environment variables.

 

@taggart, I think MQn uses first device from the list, not the one set to default.

 

It uses the default

 

John dot, can you post the mqn.bat file listing and a directory listing of the directory where mqn.exe is, PM if you want.

 

@taggart does a 16/44.1 file play ?

 

the easiest thing to do would be to download something like playpcmwin, set it up for exclusive/event wasapi and using the advanced settings see what formats play on the dragonfly. post the results and can take it from there, again PM if you want.

[sbgk]

Found a magic setting, another veil has been removed from the sound. The instrument and voice articulation is now simply stunning, it's the first time I've been able to pick any instrument and follow it throughout the song/track.

 

You've had sirloin, now it's time for fillet with lobster, a feast for the ears

 

versions 1.3, 2.3 and 3.3 uploaded

 

https://rapidshare.com/#users|45980080|0ae609ce616a35c8de7ac5fda4b6194c|11541

[John Dot]

2.3 is the best for now, 3.3 is little bit too bassy/muddy and 1.1 doesn't work correctly on my system, I hear a lot of clicks like too small buffer.

[sbgk]

2.3 is the best for now, 3.3 is little bit too bassy/muddy and 1.1 doesn't work correctly on my system, I hear a lot of clicks like too small buffer.

 

yup, the different versions are designed to work with different dacs. The 3.3 version is supposed to work with the majority, but doesn't have the buffer preloading that 1.3 and 2.3 have.

 

Don't know where to go after this iteration, think I'll be listening to music for a while as this version is simply sensational.

 

Am going to release a decode capable mqn.bat file which uses sox and someone wants a 24 bit version, but that's it as far as SQ goes.