Someone sent the following screen shot to one of our internal troubleshooting aliases. They wanted to know what the "Name Not Available" slider meant.
The audio system on Vista keeps track of the apps that are playing sounds (it has to, to be able to display the information on what apps are playing sounds :)). It keeps this information around for a period of time after the application has made the sound to enable the scenario where your computer makes a weird sound and you want to find out which application made the noise.
The system only keeps track of the PID for each application, it's the responsibility of the volume mixer to convert the PID to a reasonable name (the audio service can't track this information because of session 0 isolation).
This works great, but there's one possible problem: If an application exits between the time when the application made a noise and the system times out the fact that it played the noise, then the volume mixer has no way of knowing what the name of the application that made the noise was. In that case, it uses the "Name Not Available" text to give the user some information.
If that's the case, then why list in the mixer? Why would I want to change the volume of an application that has exited?
Because while the mixer might not be able to figure out which app just made a noise, <i>you</i> might.
What is the need of listing App in mixer anyway if I myself can figure it out.
Is it possible to reduce the volume of the app even if it is already exited (for future use)? I guess no.
I have to agree with David here: the cases where being able to figure out that the application which recently exited made a sound (after Googling, discovering this post, and reading it) is actually *useful* must pale into insignificance when compared to the number of people who'll run across it throughout the lifetime of Vista, be exposed to the behaviour, and after a moment of head-scratching just decide it's yet /another/ weird Vista bug.
…or is being able to determine which app recently played a sound and then exited massively important to some focus group somewhere?
That's still not the reason to keep it in the mixer. What exactly is the purpose of it being there? Even if you knew what application made the sound what exactly will changing the volume after it exited do? It certainly won't be saved for the next time that application is launched, since neither the sound system nor the volume mixer know which application's volume you're adjusting. So, why exactly is it in the mixer?
And what will happen if that PID is reused? Will the sound system use the old application's volume for the new application that just happened to get the same PID?
I assume right now that volume settings are auto-remembered. If that's correct, how is the setting maintained, when the actual identity is unknown/fuzzy? If not, why is the slider for Name not disabled? I had previously assumed that it was for "weird", but still running, apps of some kind (like a binary with no top-level window).
sandeep: exactly. If the app starts up again, the final volume from the mixer will be used for the app.
And internally we keep the name of the executable, it's just that that information isn't available to sndvol (the reasons why are complicated).
CN: The volume settings are kept in the registry. And the identity is only fuzzy for the volume mixer, not for the audio subsystem.
Jerry: The pid re-use issue is one we've considered and may fix in a future version of Windows. The reality is that the risk associated with a re-used PID is relatively minor, the worst case is that we get an application mis-identified in sndvol. The cost associated with fixing it is that the audio subsystem needs to keep a handle opened to every process that's ever played audio and close it when the process exits. That in turn has its own set of issues associated with it.
It would be nice if we could find out what PID it was. This way, I could track it down to the .exe file and know for myself what app I would be changing if there were several of those...
1. "The system only keeps track of the PID for each application, it's the responsibility of the volume mixer to convert the PID to a reasonable name (the audio service can't track this information because of session 0 isolation)."
2. "If the app starts up again, the final volume from the mixer will be used for the app."
3. "And the identity is only fuzzy for the volume mixer, not for the audio subsystem."
Ok, now I'm more confused. #1 and #3 appear to directly contradict each other. #2 seems impossible if the audio subsystem only knows the PID of the app, since it will have a different PID when it is started again.
Now if the audio subsystem does know the app name (so it can save the volume label for next time), but only provides an API for the mixer to get the PID, then that would explain #2 and #3 (but begs the question of why there isn't an API for the mixer to get more detailed information, if it's already sitting there anyway). I can't reconcile this with #1, though.
yeah, that's why we can't have nice things.
cannot it be named at least "Recently played app"?
can't audio service keep app names in registry (yeah, that's not nice, but Vista have a lot of worser things)?
Do you save volumes by exe name? I'm afraid to think what happens if that unidentified app was actually iexplore.exe.
It seems there should be a better solution here. If the audio subsystem can persist the settings correctly for the next time the process starts even if you change the slider after it has closed, it must have more information than just the PID. It probably also has the exe name. If it can't persist the settings correctly I see no reason why the slider is even there.
If it has the exe name, why not make that available to the volume mixer and have it display that?
Failing all those things, having a "Why?" link to a help file that explains why the name is not available in simple terms below the "Name not available" text would've helped a lot too, and it would be consistent with Vista's UI which has help links all over the place (which users then completely ignore anyway :P ).
If have to agree with most people so far...
"after a moment of head-scratching just decide it's yet /another/ weird Vista bug"
This is excatly what I thought it was as i hadn't seen it on other installations, and so 'grouped' it with other similar issues like apps that don't get preview thumbnails when the app is open on (any) other monitor other that the primary.
Good to know there's a reason for this behaviour and even better to know it may be looked at in Win 7/8?
'Jerry: The pid re-use issue is one we've considered and may fix in a future version of Windows.'
I love how everything is going to be fixed in a future version of Windows :)