• AnyStream is having some DRM issues currently, Netflix is not available in HD for the time being.
    Situations like this will always happen with AnyStream: streaming providers are continuously improving their countermeasures while we try to catch up, it's an ongoing cat-and-mouse game. Please be patient and don't flood our support or forum with requests, we are working on it 24/7 to get it resolved. Thank you.

ReClock 1.8.8.1

Hi James, TYVM for the new build and I was hoping we could discuss a few points if you don't mind:

1) Were you able to reproduce this problem by any chance? http://forum.slysoft.com/showpost.php?p=362430&postcount=60

It's no big deal but it would appear to be very real.

2) Would you consider allowing Reclock to exchange informations with madVR? Many people are currently using Videoclock in JRiver because it does exchange infos with madVR, such as the fps rate which is mandatory when you want to process IVTC in madVR for instance. It's also relying on madVR for the refresh rate detection FWIR.

3) I very recently made the big jump to W7SP1(yay :D) and what sounds the best for me with a UAC1 compliant async DAC in foobar is forcing its MMCSS priority from "'Playback" to "Pro Audio" and using KS instead of native ASIO or WASAPI event/push. Would you consider forcing "Pro Audio" for Reclock if that's not already the case? Here's a link on that matter: http://msdn.microsoft.com/en-us/library/windows/desktop/ms684247(v=vs.85).aspx

4) I've tried the "Novista" registry key but I can't get any KS audio output, be it 16/24/24@32 or 32int. My DAC relies on the windows built-in drivers, does this registry key work for anyone?

5) Regarding the media adaptation speeds, would you consider adding "48fps" please? This would come in handy should you process inverse PALSpeedup on deinterlaced PAL material. I've got a bunch of R2 DVD's here and I need to watch them in 50@48fps.

6) I sometimes play music in foobar and play movies without sound simultaneously, Reclock in WASAPI keeps showing a "The audio device is in use by another application" even though sound is muted in my video player, would that be possible to disable it?

Hope you can help, thanks in advance!
 
Last edited:
Hi James, TYVM for the new build and I was hoping we could discuss a few points if you don't mind:

1) Were you able to reproduce this problem by any chance? http://forum.slysoft.com/showpost.php?p=362430&postcount=60
No.

2) Would you consider allowing Reclock to exchange informations with madVR? Many people are currently using Videoclock in JRiver because it does exchange infos with madVR, such as the fps rate which is mandatory when you want to process IVTC in madVR for instance. It's also relying on madVR for the refresh rate detection FWIR.
Maybe. I have to look into it.

3) I very recently made the big jump to W7SP1(yay :D) and what sounds the best for me with a UAC1 compliant async DAC in foobar is forcing its MMCSS priority from "'Playback" to "Pro Audio" and using KS instead of native ASIO or WASAPI event/push. Would you consider forcing "Pro Audio" for Reclock if that's not already the case? Here's a link on that matter: http://msdn.microsoft.com/en-us/library/windows/desktop/ms684247(v=vs.85).aspx
KS? Hell, no!

4) I've tried the "Novista" registry key but I can't get any KS audio output, be it 16/24/24@32 or 32int. My DAC relies on the windows built-in drivers, does this registry key work for anyone?
No idea.

5) Regarding the media adaptation speeds, would you consider adding "48fps" please? This would come in handy should you process inverse PALSpeedup on deinterlaced PAL material. I've got a bunch of R2 DVD's here and I need to watch them in 50@48fps.
Should work fine the way it is now.

6) I sometimes play music in foobar and play movies without sound simultaneously, Reclock in WASAPI keeps showing a "The audio device is in use by another application" even though sound is muted in my video player, would that be possible to disable it?
No. With Wasapi (excl.) there can only be one. Hence the name "exclusive".
 
Last edited:
Hi James, thanks a lot for the replies.

Maybe. I have to look into it.
OK fantastic news, you can find madshi's email address at http://madshi.net/about.htm , he will be more than willing to help and madVR is by far the currently leading VR so it would be really great if Reclock & madVR could exchange vital informations as IVTC is currently impossible for instance.

KS? Hell, no!
Sorry, I misexplained myself.....I was asking if you could please force the "Pro Audio" MMCS priority as this seems to improve the SQ in many ppl's experience(including mine). Apparently several Pro Audio device drivers developers also use this trick in order to force Windows to give the highest priority to the audio rendering thread.

This will equally help any kind of audio rendering and this might very well be a "free lunch" addition to Reclock :)

Should work fine the way it is now.
Well, there's no 48fps speed adaptation option in Reclock atm and my LCD TV doesn't support 48Hz, so I have to run it in 60Hz and enable mVR's frame blending so the 48fps adaptation can't be done automatically and I can't use any refresh rate multiple option in Reclock either.

No. With Wasapi (excl.) there can only be one. Hence the name "exclusive".
My point was that if audio is muted in the video player, maybe Reclock could stop trying to allocate the audio device? Or possibly not complain that it didn't work at least. If I set Reclock to use DS while playing ASIO in foobar, Reclock is unable to lock the audio device and yet doesn't complain either.
 
after deinstalling and manually deleting the ReClock registry key and a new install of 1.8.8.2 everything is now working.
thanks again.
 
after deinstalling and manually deleting the ReClock registry key and a new install of 1.8.8.2 everything is now working.
thanks again.

This is very weird, and a little scary... Glad, that it is working, but I still can't understand what happened.

There is one design flaw with the new "force frame rate feature" in 1.8.8.2: If you manually set a frame rate, and then set the framerate to "unknown", the DS estimator will not be called again, only the in-built estimator. This is because the DS estimator will only be called once, when the file is opened. This could probably have caused the problem you've seen, but stopping/starting playback should resolve this, as well as restarting the player.
 
Hi James, thanks a lot for the replies.


OK fantastic news, you can find madshi's email address at http://madshi.net/about.htm , he will be more than willing to help and madVR is by far the currently leading VR so it would be really great if Reclock & madVR could exchange vital informations as IVTC is currently impossible for instance.
As always... so many things to do, so little time...

Sorry, I misexplained myself.....I was asking if you could please force the "Pro Audio" MMCS priority as this seems to improve the SQ in many ppl's experience(including mine). Apparently several Pro Audio device drivers developers also use this trick in order to force Windows to give the highest priority to the audio rendering thread.

This will equally help any kind of audio rendering and this might very well be a "free lunch" addition to Reclock :)
I don't see the point, as ReClock's WASAPI thread already runs with realtime priority. It won't get any better than this.

Well, there's no 48fps speed adaptation option in Reclock atm and my LCD TV doesn't support 48Hz, so I have to run it in 60Hz and enable mVR's frame blending so the 48fps adaptation can't be done automatically and I can't use any refresh rate multiple option in Reclock either.
So the problem is, that ReClock detects a 60Hz refresh rate and refuses to sync 24/48fps material.

My point was that if audio is muted in the video player, maybe Reclock could stop trying to allocate the audio device? Or possibly not complain that it didn't work at least. If I set Reclock to use DS while playing ASIO in foobar, Reclock is unable to lock the audio device and yet doesn't complain either.
DS is shared, so ReClock won't complain. It doesn't even know that it can't use audio, Windows does the audio device allocation.
 
This is very weird, and a little scary... Glad, that it is working, but I still can't understand what happened.

There is one design flaw with the new "force frame rate feature" in 1.8.8.2: If you manually set a frame rate, and then set the framerate to "unknown", the DS estimator will not be called again, only the in-built estimator. This is because the DS estimator will only be called once, when the file is opened. This could probably have caused the problem you've seen, but stopping/starting playback should resolve this, as well as restarting the player.

I forgot to mention, that I'll try to improve that with the next version. :)
 
I don't see the point, as ReClock's WASAPI thread already runs with realtime priority. It won't get any better than this.
I fully agree and I'll save from this kind of audiophool link discussing MMCS priorities : http://www.phasure.com/index.php?topic=1398.0;all
I think the MMCS regedit is another fundamental component of the playback platform

A bit less audiophool here: http://www.hydrogenaudio.org/forums/index.php?showtopic=101368&mode=linear
Roland and Cakewalk are not idiots to apply this MMCSS function and provide a default value AVRT_PRIORITY_CRITICAL (2) inside their preference

Apparently Cakewalk Sonar runs MMCS at the highest priority and some device drivers from Roland also do, they know what they're doing.

His guidelines regarding foobar make quite a lot sense and would very much apply to Reclock as well I think:
1. apply AvSetMmThreadPriority() functions to all the audio playback related threads and let us to customize the parameter values in the foobar2000 preferences, whatever in decoding threads or output threads (if output in push mode), whatever in foobar2000 itself or foobar2000 output plugins, just like the MMCSSThreadPriority parameter with value options from -2 to 2 in AUD.ini of Cakewalk Sonar.

2. Let foobar2000 change its own process priority itself and let us to define the priority level from normal to realtime in foobar2000 preference, and also let us to define the priority level of the ASIOhost32.exe, ASIOhost64.exe, WASAPIhost32.exe and WASAPIhost64.exe from normal to realtime too.

3. If possible, change the full file buffering behavior to the same as AWE of cPlay which would never be paged up to paging space in hard disk by the OS, or add an AWE playback function separately, if possible.

4. add support up to SSE4.x in all the possibly using processor instructions operations like decoding or DSP, if the foobar2000 installed machine provided.

I realize that Reclock already runs its WASAPI thread in realtime priority and I run a ramdisk pagefile so 2 & 3 are covered, the only MIA is 1, it would be really cool if you could please make it happen :rock:

It would appear that forcing "Pro Audio" does a lot more than what forcing "realtime" priority does: http://msdn.microsoft.com/en-us/library/ms684247.aspx
The background priority. The range of values is 1-8.

It basically ensures that all the rest runs in low priority and subjectively speaking this seems to improve SQ(and I didn't pronounce the J..... word :D), at least many ppl say so, I would agree.

More discussions on MMCS can be found at:

http://www.windows-tech.info/14/280e3a99336b2fe0.php
The way MMCSS works is it gives you really-really-high-priority

http://msdn.microsoft.com/en-us/library/bb614507.aspx
Calls the AvSetMmThreadCharacteristics function to request that MMCSS increase the priority of the thread in which PlayExclusiveStream executes.

This sounds full of win 8)

So the problem is, that ReClock detects a 60Hz refresh rate and refuses to sync 24/48fps material.
Well, adding a "48fps" entry in the adaptation speeds list would save the day for interlaced PAL content in 60Hz as mVR's frame blending works quite well and many displays out there don't accept 48Hz.

DS is shared, so ReClock won't complain. It doesn't even know that it can't use audio, Windows does the audio device allocation.
Yes, I realize that but anyway no big deal ;)
 
You see, it will even throttle the network speed in order to provide multimedia apps with more CPU cycles: http://blogs.technet.com/b/markrussinovich/archive/2007/08/27/1833290.aspx
Tests of MMCSS during Vista development showed that, even with thread-priority boosting, heavy network traffic can cause enough long-running DPCs to prevent playback threads from keeping up with their media streaming requirements, resulting in glitching. MMCSS’ glitch-resistant mechanisms were therefore extended to include throttling of network activity.

http://technet.microsoft.com/en-us/magazine/2007.02.vistakernel.aspx
To provide a better playback experience, Windows Vista introduces MMCSS to manage the CPU priorities of multimedia threads.
..
The various task keys specify how much preference threads associated with different multimedia types get for CPU and graphics processor resources
..
While Windows has always supported prioritization of CPU usage, it hasn't included the concept of I/O priority.

madVR already forces 0.5ms NT resolution, so this would only help further to get A/V as realtime as Windows could handle :)
 
Fair enough, I guess it takes a very good reason for you to go through the trouble of diving into Ogo's messy code and even if forcing a high MMCS priority might very well improve SQ, Reclock must leave enough juice for the video rendering duh...so it would need to run in "Playback" priority and not quite "Pro Audio". I'll just fire up my usual startup process.exe batch that puts all non-vital background processes in low priority on single cores :)
 
Fair enough, I guess it takes a very good reason for you to go through the trouble of diving into Ogo's messy code and even if forcing a high MMCS priority might very well improve SQ, Reclock must leave enough juice for the video rendering duh...so it would need to run in "Playback" priority and not quite "Pro Audio". I'll just fire up my usual startup process.exe batch that puts all non-vital background processes in low priority on single cores :)

Maybe you don't understand. ReClock is an audio renderer, it runs (mostly) in the thread context of the caller (e.g., a player application). The only internal threading is done, so the resampler can use multiple cores (pure luxury), and the wasapi output. (And some stuff not worth mentioning). Both is not really time critical (as long as it is called "soon enough", which is pretty much guaranteed).
Nothing blah blah pro audio oh my god is it a cool name will make it work better, if the caller (the player software) sucks. If it doesn't suck, ReClock won't suck, too.
 
.and a small usability tweak request if possible: a new Hotkey (Shortcut Key) to toggle "Enable sound compressor" ON/OFF.
Seven years later I was searching for this and read your request. Alas, it's never been implemented. Closer I could get, through EventGhost, is having remote buttons for Compression on and off. You need to set values in the registry, that correspond to what Reclock does when you activate the function through its control panel.
 
Back
Top