sbgk wrote:internethandle wrote:sbgk wrote:came across a tweak which I think makes a quite an amazing difference, can hear much further into the music.
tried it on win 10 and it involves giving the windows audio service it's own process instead of sharing it.
You get the service name from the services tab in task manager under Name, on mine it is Audiosrv
open a cmd window in admin
type the command below (note space after = sign)
sc config Audiosrv type= own
press return and reboot, when you look at Audiosrv in the services tab of task manager you'll see it's got it's own pid.
There might be other services that share a pid, but that seems to be the main one for audio.
to reverse it type (though don't know why you'd want to)
sc config Audiosrv type= share
and reboot
No doubt windows x will be along to borrow it for fidelizer, try it now while it's still free.
Very interesting stuff, Gordon. Very similar (but much less crude/volatile) to the Registry deletion/edit method I posted in JC's old dead tweak thread, first seen on this page:
http://www.tirnahifi.org/forum/viewtopi ... 6&start=80
With that method (in Win 7), I could also get AudioSrv and AudioEndpointBuilder their own dedicated Svchost instances, but only via manually editing the values located in the appropriate Svchost keys (this was confirmable by using Process Explorer or similar after editing and rebooting). Win 7, at least, was extremely forgiving of editing the Svchost keys in the registry - if you go far enough in JC's thread, you'll see we discovered you could delete the Wow6432Node Svchost's keys entirely to no adverse effect (or any effect, seemingly?) at all. This wasn't the case with the x86 version, where editing out services would stop things from working, but it was still plenty forgiving. As is JC's way, he would edit the registry values/keys and listen after each edit, and it seemed to drive him bonkers enough that he more or less gave up on it as a tweak. I just deleted all I could and called it a day, didn't have the patience.
Anyway, this is a much more clean and simple way of doing what I was attempting to accomplish. I'm consistently surprised but what command line capabilities I'm unaware of (as in, I thought I knew all there was pertinent to know sc.exe, but alas).
could it be used for any other processes ?
I'm uncertain, but I've got the information I need to test it, at least:
I was a bit too dim to figure it out on my own, but the Microsoft Technet article that Octagon provided on the previous page explicating Svchost revealed that the sc.exe command you posted changes the "Type" D-Word value in HKLM\System\CurrentControlSet\Services\(Service Name) from 0x20 (shared process/PID) to 0x10 (own process/PID). Not all Services located in HKLM\System\CurrentControlSet\Services contain the "Type" value, but for those that do, a rather dated Microsoft article explains their values as such:
Code: Select all
0x1 A Kernel device driver.
0x2 File system driver, which is also
a Kernel device driver.
0x4 A set of arguments for an adapter.
0x10 A Win32 program that can be started
by the Service Controller and that
obeys the service control protocol.
This type of Win32 service runs in
a process by itself.
0x20 A Win32 service that can share a process
with other Win32 services.
Anyway, now that I'm aware of which registry value is modified by the sc.exe command you posted, I can test the method pretty easily. Right now, for this Win10 Pro install I'm using, every service located in my HKLM\System\CurrentControlSet\Services key is disabled (ostensibly, at least - there are some that seemingly ignore the "Start" value - such as NDIS - and load anyway, or, in the case of CryptSvc, Windows repeatedly changes it back to 0x3 if changed to 0x4) via the "Start" D-Word value being set to 0x4 except the following, which are some other value other than 0x4, depending:
ACPI
acpiex
acpipagr
AFD
Appinfo
AudioEndpointBuilder
Audiosrv
BasicRender
BrokerInfrastructure
CMUACWO (needed for DAC driver)
CNG
CoreMessagingRegistrar
CryptSvc (Windows reverts to 3)
DcomLaunch
Dhcp
disk
e1dexpress
EhStorClass
FltMgr
fvevol
hwpolicy
iastorA (AHCI driver I'm using via Intel RST, would possibly be a different AHCI driver entry for others and prevent boot if that driver was disabled, e.g. "storahci" or, if using IDE, possibly "atapi")
i8042prt (needed for PS/2 mouse and Keyboard, which allows me to disable all USB ports and services except usbccgp and the Renesas ones below)
igfx (using onboard Intel Graphics)
intelpep
kbdclass
ksecdd
ksthunk
LSM
MMCSS (needed for WASAPI, obviously, which I'm using)
monitor
mouclass
mountmgr
Msfs
msisadrv
Npfs
nsi
nsiproxy
NTFS
partmgr
pci
pdc
Power
ProfSvc
rdyboost
RpcEptMapper
RpcSs
rusb3hub (PPA USB v2 card)
rusb3xhc (PPA USB v2 card)
Tcpip
tdx
UEFI
usbccgp
UserManager
volmgr
volsnap
Wdf01000
WFPLWFS
WindowsTrustedRT
Disabling any of the above will result in 1) Windows not booting, 2) no internet connection, or 3) no sound via my USB DAC.
To test what I could disable, if disabling a service resulted in a BSOD or other issue with W10 booting (or, in my case, if the mouse or keyboard did not work, since I was not willing to install a USB mouse or keyboard just to recover), I'd simply boot from my W10 install USB thumb drive, use its Command Line function, fire up regedit, Load the appropriate SYSTEM hive from c:\windows\system32\config, edit the offending "Start" value back to its non-0x4 default, unload the hive, and reboot.
It's unclear to me how exactly Svchost behaves, that being said. With the exception of deleting "CryptSvc" from the "NetworkService" key to prevent it from re-starting after Windows reverts it back to 0x3, I've yet to touch the HKLM\Software\Microsoft\Windows NT\CurrentVersion\Svchost key or its subkeys on this W10 build, but with W7 even if a service was diabled in registry via the Start" D-Word, editing the Svchost key and its subkeys seemed to make a sonic difference. And yet, if you hover over any Svchost.exe in a program like Process Explorer or Task Manager, it seems to only have loaded those processes that are enabled. The Svchost registry editing tweak was pioneered over at GraphixNStuff, which does not appear to be up any longer, and Wayback Machine is no help, unfortuntately, but the poster who pointed it out claimed a reduction in CPU usage by editing it, regardless of Service Startup type configuration. I don't remember what was the case with W7, so I'd have to test that.
Anyway, long story short: I'll get back to you. ;)