Rulând Windows Server 2012 R2, am observat o caracteristică enervantă pe conexiunile RDP:
Windows continuă să distrugă Serviciul Audio audiodg.exe dacă este inactiv mai mult de 5 minute.
Problema cu aceasta este că orice ieșire audio nouă va suferi acum o întârziere de pornire de 5-10 secunde, trebuind să aștepte audiodg.exe pentru a spool din nou înainte ca ieșirea audio să poată porni.
Am văzut probleme de întârziere audio discutate cu conexiunile RDP de nenumărate ori pe toate versiunile Windows Server, dar încă nu am văzut pe nimeni menționând că aceasta ar putea fi cauza tuturor acestor probleme.
Timpul de spool-up al audodg.exe va întârzia întregul sunet de pe server. Nu contează de unde provine sunetul. Aplicațiile interactive cu feedback audio nu vor fi sincronizate, iar videoclipurile YouTube de pe Chrome se vor îngheța până când audiodg rulează din nou.
Pe serverul meu, audiodg consumă 100% CPU la pornire. Nu știu ce face, dar face ceva la CPU 100% timp de aproximativ 5-10 secunde înainte de a relua sunetul normal.
Odată ce este pornit și rulat, tot sunetul este instantaneu. Fără întârzieri sau întârzieri. Totul funcționează bine atâta timp cât continuă să funcționeze.
Singura modalitate pe care am găsit-o de a remedia această „funcție” enervantă a fost să creez o sarcină repetată care redă câteva secunde de sunet (tăcere) la fiecare 4 minute pentru a împiedica Windows să distrugă audiodg.
Pare o soluție prostească.
Îmi vin în minte câteva întrebări (în ordinea importanței, cred):
Cum aș putea preveni ca audiodg să fie ucis, în primul rând, fără a recurge la soluții hacker? Există undeva o setare de registry pentru asta? Am setat serviciul la „manual”, dar asta nu face nicio diferență. Automat/Manual..aceeași problemă indiferent.
De ce este pornirea audiodg atât de lentă? Cred că acesta poate fi, de asemenea, un fel de eroare sau caracteristică neintenționată.
Actualizați
Se pare că am găsit răspunsul la întrebarea 2 aici:
Procesul audiodg.exe scanează catroot și hogs IO
