I'll preface this by saying that my development PC doesn't ever make noise, doesn't have speakers, and can't even play CDs or MP3s through headphones if I try to attach them. The IT people here apparently think audio is always recreational in nature and not allowable. This is a bit odd, and creates problems at times, but is also not that big of a surprise in light of the pervasive Barney Fifery that characterizes IT people.

The real WTF is "Windows Audio Endpoint Builder." I noticed today that my system's response time was even more pathetic than usual, and I discovered that this service was using 150+ megabytes of RAM. Apparently this is just a fixed cost of Windows 7 audio even if there is no audio and never will be! Also, this obnoxious little daemon seems to oscillate randomly between having approximately 25 threads and (briefly) having circa 65 threads.

I shudder to even imagine the design stupidity that led to this. I almost feel sorry for anyone retarded enough to program this way... but then I remember that the moron in question has a job at Microsoft and I'm reviled as "the worst programmer on this board," so the whole thing just pisses me off. We are truly living in Bizarro World (and people are too busy buggering/shooting/robbing each other to care.)

The final insult: I can't really end this thing. It runs under user SYSTEM (not me, apparently) and if I end it, the stupid piece of crap just comes back. Not incidentally, that returning behavior is one of Microsoft's pet antipatterns, as is the Windows service generally; are they have expecting me to listen to music without logging on?

Windows is such a piece of crap. It's no wonder I'm getting a prostitute-like rate for this crap.

It is an user mode driver that runs as it's own pseudo process.

henke37:

It is an user mode driver that runs as it's own pseudo process.

That's an interesting conglomeration of words but it does nothing to justify what I am being subjected to.

Is it using-using the memory or just allocating it?

blakeyrat:

Is it using-using the memory or just allocating it?

I don't know... I am looking at "Private Working Set" in Task Mismanager. I found the thread count almost as alarming as the RAM... if you're going to do nothing, can nothing not at least be monothreaded?

"Private Working Set" means the memory belongs to that process alone and can't be shared by other processes (i.e. not memory consumed by shared DLLs, for example). It says nothing about how active the memory is-- meaning it could have a "Private Working Set" that's 99.9% swapped-out at all times.

Thread overhead is negligible, so I wouldn't even bother looking at that.

So it's not enough info to say whether the service is efficient or not.

Developer: "This program doesn't actually do anything for many users. How do you want us to improve it?"

Boss: "Add a bunch more threads."

Developer: "But then they'll all sit around doing nothing."

Boss: "Multi-threaded is better, so just do it."

 If only it could be disabled in Serivces.msc =(

blakeyrat:

"Private Working Set" means the memory belongs to that process alone and can't be shared by other processes (i.e. not memory consumed by shared DLLs, for example). It says nothing about how active the memory is-- meaning it could have a "Private Working Set" that's 99.9% swapped-out at all times.

Thread overhead is negligible, so I wouldn't even bother looking at that.

So it's not enough info to say whether the service is efficient or not.

You're still having trouble with the whole computer thing, I see. Or, more realistically, you're incapable of responding to certain people's posts objectively. If you really believe what you posted there, you might want to see if DeVry has a remedial program.
I don't care how "active" the memory is... it's stupid to allocate that much memory. Even Visual Studio usually keeps it under 100MB. In fact, every other process on my system is

Similarly, I don't care that you think the overhead with creating all those threads is negligible. All of those threads are presumably doing things. Or, if they're not, that's a bit questionable, too.

Lorne Kates:

 If only it could be disabled in Serivces.msc =(

Lorne Kates:

 If only it could be disabled in Serivces.msc =(

If only I knew or cared what that was. If only the world were smart enough to do that instead of just buying new "faster" computers, and forcing Indian children to leach the precious metals from their old ones. If only developers would think with their cerebella instead of their micro-phalli. If. Only.

bridget99:

Lorne Kates:

 If only it could be disabled in Serivces.msc =(

Lorne Kates:

 If only it could be disabled in Serivces.msc =(

If only I knew or cared what that was. If only the world were smart enough to do that instead of just buying new "faster" computers, and forcing Indian children to leach the precious metals from their old ones. If only developers would think with their cerebella instead of their micro-phalli. If. Only.

 

If only you were aware that buttons in browser, such as "Quote", don't need to be double clicked.

And not knowing what services.msc is? This is why you're the world's worst programmer. Not the only reason why, but certainly high on the list.

 

bridget99:

I don't care how "active" the memory is... it's stupid to allocate that much memory. Even Visual Studio usually keeps it under 100MB. In fact, every other process on my system is

Look, I know you're a troll, but my explaining this to you might help the other idiots on this forum who love programming but somehow know virtually nothing about computers and OSes, so I'll respond anyway.

Memory allocation is nothing in Windows. NOTHING. It's you telling the OS: "hey I may potentially sometime in the future maybe need this memory." The OS sets aside address space for you, but other than that it does NOTHING. It doesn't swap out live memory from another process. It doesn't chug the disk clearing space in the swap file. All it does is keep track of the address that memory will be at when (if!) it's ever actually used. All memory addresses and allocations (with extremely few exceptions I won't get into) are virtual. All of them.

(This is where the pedantic dickweed will pop up and tell me the allocation could potentially hit the commit limit. It could but it won't. It's a Service. Now shut up and go away.)

Therefore, if you're a Service and you tell the OS, "hey give me 100 MB" but you never actually dip into that 100 MB, you know what happens? NOTHING. There is no memory pressure. So looking at Task Manager and seeing, "oh this Service has allocated 100 MB! Why is it so inefficient?" It's not. (Well, it may be, but reading the amount of allocated memory won't tell you if it is or not.)

bridget99:

Similarly, I don't care that you think the overhead with creating all those threads is negligible.

It is though. Benchmark it.

bridget99:

All of those threads are presumably doing things. Or, if they're not, that's a bit questionable, too.

True. But if you shoved a sound card into the computer, like 99.99999% of computers already have, none of those threads would be running anyway. I gather that the whole point of the Service is to act as a "fake" sound card so applications expecting to open sound devices won't crash and fail in horrible ways. The vast, vast, vast, vast, vast majority of computers will never need this Service.

So maybe it's not as optimized as it should be. Fine! Who cares! Under normal circumstances, it never runs at all. So it's not worth optimizing.

Lorne Kates:

And not knowing what services.msc is? This is why you're the world's worst programmer. Not the only reason why, but certainly high on the list.

Don't be an ass. You can be a expert at using the Services control panel without ever knowing the file that drives it is called "services.msc". Why would you know that piece of implementation-detail trivia?

That's not to say that Bridget is a good programmer, but you're also being an idiot here.

The final insult: I can't really end this thing. It runs under user SYSTEM (not me, apparently) and if I end it, the stupid piece of crap just comes back. Not incidentally, that returning behavior is one of Microsoft's pet antipatterns, as is the Windows service generally

AFAIK, it's something common to every kernel : a system daemon / service will be relaunched almost immediatly after he die (well, the whole concept is that if the daemon is not here, then the kernel launch it). You must tell him to stop launching first. Which I don't have any idea how to do, or even if it's possible, under windows. Odds are only IT admins can do it, if we suppose they are somehow decent admins.

And in pure crappiness level, (linux) pulseaudio can compete I think. It's not the same thing of crap mind you, since it's more "incompatible with everything else" than "bloatware"

 

mod: fixed quote tags  –dh

Oh, stop your childish rant.. Is the process taking any CPU cycles? if its just memory, then it will be paged out, and won't affect your performance.

 

You may want to stop faking you know something about computers and how windows handles memory, and read this

http://www.withinwindows.com/2008/05/07/sonic-focus-speedily-fixes-leaky-windows-vista-audio-drivers/

http://blogs.msdn.com/b/larryosterman/archive/2005/09/21/472480.aspx

 

Audio End point builder actually loads Non Microsoft code, (that is the reason its not in regular svchost process). Or you may want to raise this to your IT team and have them investigate why the process is not working as designed.

 

Oh hey look did Bridget Troll accidentally reveal a second account name?

In addition to the comments posted above, the memory utilization (while not overly important unless the entire virtual address space is at risk of being exhausted) seems very high. I have looked at 11 machines here, with various audio (ranging from none to complete surround systems) and the HIGHEST I have found is 12MB (average is about 7MB)....

This particular service is interrelated with a number of other services, and I would suspect that someone has been altering the services configuration in such a way as to have caused a problem. [e.g. disabling power management has been reported as causing issues with this service]

blakeyrat:

Oh hey look did Bridget Troll accidentally reveal a second account name?

But it isn't used much (low post count, last was 11/9/2012) so I'm unsure if the reveal is helpful at all.  Low use makes it hard to determine from writing style, but if only used a little then it doesn't matter.

blakeyrat:

Lorne Kates:

And not knowing what services.msc is? This is why you're the world's worst programmer. Not the only reason why, but certainly high on the list.

Don't be an ass. You can be a expert at using the Services control panel without ever knowing the file that drives it is called "services.msc". Why would you know that piece of implementation-detail trivia?

That's not to say that Bridget is a good programmer, but you're also being an idiot here.

 

Because just about every single help thread and Microsoft KB article will tell you Start -> Run -> services.msc

And even if Trollet99 didn't know that, you would think that maybe, just maybe, between the filename, and the extension type, she could have perhaps just possibly gleaned that it's a Microsoft Control Snap-In that deals with Services.  It's not like this is a cryptic Unix abbreviated / obscured utility name.

Expecting an experienced Windows programmer to know a basic and oft-used and oft-referred to Windows utility is not being an idiot. You knew what services.msc was. I'm willing to be most if not all Windows programmers (and a good chunk of non-Windows programmers) on this very board, knows what windows.msc was. And if they didn't, I bet they could have figured it out. And if they couldn't, I bet they could have  done a quick search and then looked at the very first result. They wouldn't even have had to click on the first result, as the summary snipped is:

Once a service is installed, it can be managed by launching "Services" from the Windows Control Panel → Administrative Tools or typing "Services.msc" in the ...

In summary: don't be an idiot.

 

 

bridget99:

The real WTF is "Windows Audio Endpoint Builder." I noticed today that my system's response time was even more pathetic than usual, and I discovered that this service was using 150+ megabytes of RAM. Apparently this is just a fixed cost of Windows 7 audio even if there is no audio and never will be! Also, this obnoxious little daemon seems to oscillate randomly between having approximately 25 threads and (briefly) having circa 65 threads.

No, the real WTF is not reading what Audio Endpoint Builder does. Its a discovery service that enumerates the various audio endpoints available in your system and then manages mixing and output over the endpoints it could find. Whether something is physically plugged into a jack or not has little to do with that.

The reason you're seeing the increase in threads is because you are starting an application that wants to output audio and it spins up an endpoint graph for you. As this is a graph traversal algorithm that's taking place, it is probably being parallelized for efficiency. The starting pool of approx. 25 threads can probably be explained by something simple, like it using a per-process servicing thread or something. (Combine that with 'tab-per-process' browsers like Chrome, and voilà...)

The allocation of 150MB of RAM is, as Blakey has so brilliantly explained before, merely an expression of intent. To paraphrase:

Windows Audio Endpoint Builder:
"Hi, Windows kernel. My user would really love a smooth audio experience when needed, so instead of having to wait for memory allocation for buffers, I'd like to reserve some space with you up front. Say, about 150 MB of buffer space? You can miss that for now right, if it means my real-time operations for audio output are going to be smooth?"

Windows kernel:
"Sure. Let me file that request for you and I'll make sure other processes stay out of your way. Well, as much as I can anyway; no guarantees something really important won't come along."

Windows Audio Endpoint Builder:
"Hey, no problem man. Don't worry, about it. If some big-wig process needs to claim the space, I can still chill and page-fault for a bit if it turns out to be in-use when I need it.

Windows Audio Endpoint Builder (mumbling):
"Wouldn't go over well with my user though; hates audio hickups..."

The Windows Audio Endpoint builder interracts very closely with the drivers for various audio hardware.  I would check to see what devices are listed under device manager to see if any audio drivers have been loaded, and possibly get those drivers/devices removed or disabled.

There was an issue with the HDMI Audio driver for some versions of AMD's driver sets that caused excessive memory/cpu useage with the builder.

The problem usually isn't with the Windows Audio Endpoint service so much as a buggy or leaky audio device driver.  And, before you say "but my computer has no speakers ..." it is possible to have a device driver loaded without the actual hardware being present.

TheCPUWizard:

I have looked at 11 machines here, with various audio (ranging from none to complete surround systems) and the HIGHEST I have found is 12MB (average is about 7MB)....

Is that Working set or Virtual size? Virtual size on my machine is 42MB, and Working set is 10MB.

Ragnax:

bridget99:

The real WTF is "Windows Audio Endpoint Builder." I noticed today that my system's response time was even more pathetic than usual, and I discovered that this service was using 150+ megabytes of RAM. Apparently this is just a fixed cost of Windows 7 audio even if there is no audio and never will be! Also, this obnoxious little daemon seems to oscillate randomly between having approximately 25 threads and (briefly) having circa 65 threads.

No, the real WTF is not reading what Audio Endpoint Builder does. Its a discovery service that enumerates the various audio endpoints available in your system and then manages mixing and output over the endpoints it could find. Whether something is physically plugged into a jack or not has little to do with that.

The reason you're seeing the increase in threads is because you are starting an application that wants to output audio and it spins up an endpoint graph for you. As this is a graph traversal algorithm that's taking place, it is probably being parallelized for efficiency. The starting pool of approx. 25 threads can probably be explained by something simple, like it using a per-process servicing thread or something. (Combine that with 'tab-per-process' browsers like Chrome, and voilà...)

The allocation of 150MB of RAM is, as Blakey has so brilliantly explained before, merely an expression of intent. To paraphrase:

Windows Audio Endpoint Builder:
"Hi, Windows kernel. My user would really love a smooth audio experience when needed, so instead of having to wait for memory allocation for buffers, I'd like to reserve some space with you up front. Say, about 150 MB of buffer space? You can miss that for now right, if it means my real-time operations for audio output are going to be smooth?"

Windows kernel:
"Sure. Let me file that request for you and I'll make sure other processes stay out of your way. Well, as much as I can anyway; no guarantees something really important won't come along."

Windows Audio Endpoint Builder:
"Hey, no problem man. Don't worry, about it. If some big-wig process needs to claim the space, I can still chill and page-fault for a bit if it turns out to be in-use when I need it.

Windows Audio Endpoint Builder (mumbling):
"Wouldn't go over well with my user though; hates audio hickups..."

, I read this, and I feel like that Indian in the anti-littering ad. My computer is not a jukebox. I'm not sure who is trying to shove a foot in what door by trying to make it one, but to paint this as anything other than a grave misappropriation of my computing resources is really a pretty awful thing to do.

bridget99:

My computer is not a jukebox.

Your computer is indeed, among many other things, a jukebox.

bridget99:

but to paint this as anything other than a grave misappropriation of my computing resources is really a pretty awful thing to do.

You have to prove your computing resources are being misappropriated to a noticeable degree first. You haven't done that. You just saw some numbers in Task Manager which looked bigger than you think they ought to look. (Without, I may add, knowing how big they ought to look.)

blakeyrat:

bridget99:

I don't care how "active" the memory is... it's stupid to allocate that much memory. Even Visual Studio usually keeps it under 100MB. In fact, every other process on my system is

Look, I know you're a trol

Isn't that a lot like the pot calling the kettle black.

bridget99:

My computer is not a jukebox. I'm not sure who is trying to shove a foot in what door by trying to make it one, but to paint this as anything other than a grave misappropriation of my computing resources is really a pretty awful thing to do.

One simple fact to get through your thick skull:
An allocated block of memory is not necessarily memory that is in use.

There can be no misappropriation because nothing has been appropriated yet. Allocation of memory is just a way to tell the memory manager to avoid allocating that block of memory for other processes if it can, because the process that originally allocated it may want to start using it at some time.The memory doesn't actually end up 'locked' until the requesting process first touches it.

This is just a way to optimistically reserve memory to be set aside by the OS, hoping that by the time the memory is touched the first time it will still be available for use. If it is, then: good! That means the process won't have to spend time to request memory from the OS in what may be a performance-critical section of code. If it's not, then ... well; you're none worse off than you would've been had you not pre-allocated the memory. The process will have to wait for the OS to give it the memory then and there. This gives performance-critical code with real-time constraints (such as outputting audio or video at a consistent frame rate) a way to try and optimize their memory access without any adverse impact on other processes, provided they can predict an upper bound on their memory use. (With fixed-length buffers, that is not a problem.)

Also, it enables the memory manager to perform several optimizations to prevent fragmentation of the physical memory space and allows it to distribute memory amongst running processes efficiently. Everything you are complaining about is actually a good thing for the overall performance of your system.

 If I had to guess, I'd say your PC is in 'I have no mouth but I must scream' mode.

Even if you have all the audio options turned off, if an application tries to .Beep() something needs to respond to the API call, instead of BSOD'ing.

It is not the fault of anyone at Microsoft that your IT staff are Nazis.

 

blakeyrat:

True. But if you shoved a sound card into the computer, like 99.99999% of computers already have, none of those threads would be running anyway. I gather that the whole point of the Service is to act as a "fake" sound card so applications expecting to open sound devices won't crash and fail in horrible ways. The vast, vast, vast, vast, vast majority of computers will never need this Service.

So maybe it's not as optimized as it should be. Fine! Who cares! Under normal circumstances, it never runs at all. So it's not worth optimizing.

About 10 years ago, I had a strange bug while playing Warcraft 3. All story cinamatics would start the first scene and the first line of dialog (Subtitled), but then inexplicably hold and did not continue. I could press escape and skip the cinamatic, but I was deprived of the story. After working with the bug, I realized why: The computer had no audio. No speakers or headphones were plugged in, and the application was waiting for Windows to indicate when a line of audio was finished before it would continue the scene.

I was something like 15 at the time, so I can't confirm that was the exact reason, but sure enough, plugging in headphones fixed the issue for me. I assume it's a lack of testing on Blizzard's part (Can't really fault Windows for this one IMO).

So I agree with Blakey, it's probably that Windows 7 fixed this issue by having a virtual speaker 'play' the audio for applications to fix bugs that rely on audio in the system.

gu3st:

blakeyrat:

bridget99:

I don't care how "active" the memory is... it's stupid to allocate that much memory. Even Visual Studio usually keeps it under 100MB. In fact, every other process on my system is

Look, I know you're a trol

Isn't that a lot like the pot calling the kettle black.

More like a professional courtesy.

blakeyrat:

Is it using-using the memory or just allocating it?

 

 Not only that, is it even the thing that's using the memory?  In Windows 8 at least, it's part of a thread group--on my PC it's sharing a process with 8 other services including stuff like HID Access.  On Win7, same thing.  There's no way the audio endpoint builder is using anywhere near all of that memory and/or threads.

What exactly is the distinction between allocating memory and setting aside memory? Isn't that the same thing? All I know is that neither of those terms mean "do nothing".

A certain VoIP client I use likes to allocate half of my computer's memory and then do nothing with it. The memory still gets allocated. My system still slows to a halt as it tries to swap everything but the newest 1500MB allocation. And then it brings it back into RAM, because "hey, I was using that!"

Ben L.:

A certain VoIP client I use likes to allocate half of my computer's memory and then do nothing with it. The memory still gets allocated. My system still slows to a halt as it tries to swap everything but the newest 1500MB allocation. And then it brings it back into RAM, because "hey, I was using that!"

What OS are you running? ShitOS?

To make things interesting, there is no way to know that that single service is using all that memory, since in most configurations it is hosted alongside hidserv (for Human Interface Devices), HomegroupListener,Netman, which manages network connections,Superfetch, the Distributed Link-tracking Client, the Desktop Window Manager (if enabled), WLAN autoconfig, as well as all drivers hosted as part of the User-mode Driver framework.

Attributing all the process memory, CPU, and threads to one of these seems a bit foolish- not just because there are actually 8 different services (one of which itself hosts more), and not just because some of those other services are likely to get rather heavy use on a Server... but because you can't possibly know which of the in-process services are allocating the memory or using the CPU or creating threads.

FrostCat:

There's no way the audio endpoint builder is using anywhere near all of that memory and/or threads.

I was under the impression we're talking about audiodg.exe, which runs as a separate process.

Ben L.:

What exactly is the distinction between allocating memory and setting aside memory? Isn't that the same thing? All I know is that neither of those terms mean "do nothing".

In Windows they're different things.

Allocating memory only indicates to the memory manager that a process will require a certain block of contiguous RAM some time in the near future. The manager responds by giving back a handle through the process can acces its requested block of virtual memory. However, it does not yet mark the block of memory as in use. The memory manager will only mark the block as in use when the process first 'touches' the memory.

When programs leverage this technique correctly by pre-allocating as much as possible, then it gives the memory manager enough a priori knowledge of the memory use for those running programs to allow it make semi-informed decisions on how to lay out the mapping between physical and virtual memory. The memory manager can then strive to minimize page-faults and physical memory fragmentation. When the memory manager still ends up having to defragment memory, it could aim to first shuffle the untouched allocated blocks around. Those can be moved at significantly reduced cost as there cannot be data from the process in those blocks yet that woudl need copying to the new location. You avoid both the cost of copying the block's contents over to a new location and the cost of having to temporarily have both blocks of memory reserved while the copy operation takes place.

Ben L.:

A certain VoIP client I use likes to allocate half of my computer's memory and then do nothing with it. The memory still gets allocated. My system still slows to a halt as it tries to swap everything but the newest 1500MB allocation. And then it brings it back into RAM, because "hey, I was using that!"

Your VoIP client is allocating one huge chunk of memory. If it immediately accesses even one address in it, then you're SoL: Windows will reserve the whole block as in use. This makes sense, as the memory manager cannot make any assumptions on what you are going to do inside that block.

This is typical of applications that write their own versions of malloc; they grab a huge page of memory from the OS and internally 'malloc' into that one block. Basically they write their own memory manager. The only kind of application that would really benefit from this kind of thing are games. It gives the programmer a tiny bit more control over when the process has to wait for memory to be allocated and reserved by the OS, so that they can force this 'hit' to be placed on loading screens when the game is probably already trashing the hard drive. As games are usually played fullscreen they don't have to share user interaction with other running applications, so allocating a huge block and forcing the memory manager to page those background applications out of memory is not such a big deal.

Ragnax:

Your VoIP client is allocating one huge chunk of memory. If it immediately accesses even one address in it, then you're SoL: Windows will reserve the whole block as in use. This makes sense, as the memory manager cannot make any assumptions on what you are going to do inside that block.

Actually, AFAIK, it won't - all the memory is initially mapped to the same physical page, which is always zeroed out and read-only. You can read it as much as possible, and nothing will happen. Only when you try writing to the memory, this creates a page fault, and the memory manager actually gives you writable pages - but only those that you attempted to write to.

Ragnax:

The memory manager will only mark the block as in use when the process first 'touches' the memory.

Caveat: "touch" meaning "writes to". If you read it, the OS will just give you zeroes without bothering to shuffle memory around, because it knows even if it had bothered to page the memory in, the memory would be nothing but zeroes.

Ragnax:

If it immediately accesses even one address in it, then you're SoL: Windows will reserve the whole block as in use. This makes sense, as the memory manager cannot make any assumptions on what you are going to do inside that block.

It'll reserve it as in-use, but it'll still page it in on-demand. At least that's my understanding... if your VOIP program allocates 1.5 GB, and only writes to 3 pages, its "working set" will be 1.5 GB, but it's "paged-in set" (which I don't believe any Windows diagnostic tools tell you) will be 12k-ish.

Edit: what Ender said. Sorry for not reading thread before posting.

Thread summary: a combination of crappy drivers and/or crappy admins along with jumping the gun by mis-reading performance statistics causes bridget99 to blame the only party not at fault here; Microsoft.

blakeyrat:

Ben L.:

A certain VoIP client I use likes to allocate half of my computer's memory and then do nothing with it. The memory still gets allocated. My system still slows to a halt as it tries to swap everything but the newest 1500MB allocation. And then it brings it back into RAM, because "hey, I was using that!"

What OS are you running? ShitOS?

What makes you assume it's not running as you described for Windows? It could be a shitty application instead of OS and actually touching that much memory before not using it. That would still require it to be paged in and out once.

ender:

FrostCat:

There's no way the audio endpoint builder is using anywhere near all of that memory and/or threads.

I was under the impression we're talking about audiodg.exe, which runs as a separate process.

OP specifically mentioned the word service and "audio endpoint builder" which is a service. But as has been said, that service is bundled into the same process as 8 others, and some of them are far more likely to be using the lion's share of RAM than the audio service.

ender:

Ragnax:

Your VoIP client is allocating one huge chunk of memory. If it immediately accesses even one address in it, then you're SoL: Windows will reserve the whole block as in use. This makes sense, as the memory manager cannot make any assumptions on what you are going to do inside that block.

Actually, AFAIK, it won't - all the memory is initially mapped to the same physical page, which is always zeroed out and read-only. You can read it as much as possible, and nothing will happen. Only when you try writing to the memory, this creates a page fault, and the memory manager actually gives you writable pages - but only those that you attempted to write to.

My bad. Yeah; I meant write access. Same with the use of the 'touch' term that Blakey expanded on already. When the terminology has become somewhat second nature, it becomes hard to detach yourself from your train-of-thought auto-pilot mode and really mention the full details when you're explaining a topic to others. :-)

bridget, if I were you, I'd be more worried about the "System Idle Process" that's eating most of your CPU time.

I have functioning audio and no such process allocating RAM.  I think you have an issue with some other software running on your computer.  Perhaps some malware, as you seem like the type.  You clearly lack a lot of understanding of how your computer works and you have a bunch of contempt for your admins.

pauly:

and you have a bunch of contempt for your admins.

You say that like it's a bad thing.

bridget99:

Even Visual Studio usually keeps it under 100MB

Currently my VS is at 1,056,188 KB (1.056 GB) of private bytes; or approx 1/4 of all the memory on this machine.  So it's not just your audio program that's a hog.

blakeyrat:

"Private Working Set" means the memory belongs to that process alone and can't be shared by other processes (i.e. not memory consumed by shared DLLs, for example). It says nothing about how active the memory is-- meaning it could have a "Private Working Set" that's 99.9% swapped-out at all times.

As is so often the case with you Blakey, not talking shit takes a poor second place behind arrogantly arguing with anyone you can at any time for any reason, regardless of the facts.

http://msdn.microsoft.com/en-gb/library/windows/desktop/cc441804%28v=vs.85%29.aspx:

The working set of a process is the set of pages in the virtual address space of the process that are currently resident in physical memory.

So your suggestion that the working set can be swapped-out is total crap, by definition.

 

DaveK:

blakeyrat:

"Private Working Set" means the memory belongs to that process alone and can't be shared by other processes (i.e. not memory consumed by shared DLLs, for example). It says nothing about how active the memory is-- meaning it could have a "Private Working Set" that's 99.9% swapped-out at all times.

As is so often the case with you Blakey, not talking shit takes a poor second place behind arrogantly arguing with anyone you can at any time for any reason, regardless of the facts.

http://msdn.microsoft.com/en-gb/library/windows/desktop/cc441804%28v=vs.85%29.aspx:

The working set of a process is the set of pages in the virtual address space of the process that are currently resident in physical memory.

So your suggestion that the working set can be swapped-out is total crap, by definition.

 

Anyone arguing that (paraphrasing) "allocating a bunch of memory is OK because the OS can probably just take it back if it needs to, assuming the allocating process hasn't'touched' it yet" is full of it. My suggestion: try using that strategy on a whiteboard in a technical interview and see if you get hired.

bridget99:

Anyone arguing that (paraphrasing) "allocating a bunch of memory is OK because the OS can probably just take it back if it needs to, assuming the allocating process hasn't'touched' it yet" is full of it. My suggestion: try using that strategy on a whiteboard in a technical interview and see if you get hired.

What OS is your whiteboard running?

blakeyrat:

bridget99:

Anyone arguing that (paraphrasing) "allocating a bunch of memory is OK because the OS can probably just take it back if it needs to, assuming the allocating process hasn't'touched' it yet" is full of it. My suggestion: try using that strategy on a whiteboard in a technical interview and see if you get hired.

What OS is your whiteboard running?

The people conducting the interview will expect the candidate to come up with strategies, designs, etc. that are reasonable and efficient even without the intervention of a bunch of OS-specific mumbo-jumbo. If you just allocate a bunch of anything under the assumption that some specific OS version will clean up your mess, your interlocutors will rightfully categorize you as an idiot. People who depend on that kind of crap are better-suited for admin work than for development. I would describe such strategies as design-by-brochure.

bridget99:

Anyone arguing that (paraphrasing) "allocating a bunch of memory is OK because the OS can probably just take it back if it needs to, assuming the allocating process hasn't'touched' it yet" is full of it.

Yet it is exactly how Windows' memory model works. When a particular process requires more memory space and can't recycle some of the standby or modified pages associated with itself, a hard page fault occurs. When a hard page fault occurs, the memory manager needs to pull additional pages into the private working set of the faulting process. These will be sourced from (in order):

• the zeroed page list, which holds clean pages from uncommited RAM that are ready for use.
• the free page list, which holds free pages that may still hold stale data from other processes. When being repurposed for use by another process, these pages need to be zeroed out first.
• the standby page list, which holds inactive pages that are paged out of private working sets without having been changed. These can immediately be repurposed.
• the modified page list, which holds inactive pages that are paged out of private working sets after having been changed. These need to be flushed to a backing store (i.e. the page file or in case of memory mapped files; another file on a storage medium) before being repurposed.

In the extremely pessimistic case that no pages are available in any of these lists, the private working set of other processes has to be shrunk to reclaim enough RAM for the faulting process. This means pages that are heuristically determined to be inactive (the memory manager keeps counters for these things...) are pulled to the standby and modified page lists to then have their RAM be repurposed for the faulting process. The memory manager also knows which pages have not yet been modified and these can go directly to the standby pages list, bypassing any kind of flush to the backing store (which, incase of 'normal' process memory would have been the page file). Trying to reclaim these first is significantly faster, because there is no disk I/O taking place.

http://msdn.microsoft.com/en-gb/library/windows/desktop/cc441804%28v=vs.85%29.aspx:

The working set of a process is the set of pages in the virtual address space of the process that are currently resident in physical memory.

Significant addendum; memory-mapped files or other types of streams are also deemed to be 'resident in physical memory', even though they do not take up RAM. Device memory, such as output buffers for audio devices can also be a part of this. And what does audio endpoint builder do? Right! It builds up a graph of endpoints which are associated with streams or buffers to which audio data can be written for playback.