פורמט Windows Audio: תדר, עומק סיביות ועומס
בדף זה
תשובה קצרה: ב-endpoint של Realtek USB Audio שנחקר, הפורמט 48 kHz / 24-bit נותר הבחירה המעשית. מעבר ל-96 או 192 kHz לא הפחית את התקופה הזמינה של מנוע האודיו או את הערכת התור של XAudio2. היתרון של 16-bit ב-CPU והיתרון של השבתת אפקטים מערכתיים לא אומתו.
סטטוס: נמדד על מערכת אחת, לא שוחזר בהתקן אחר. אין להעביר את התוצאה אוטומטית ל-audio driver, DAC או Windows build אחרים. משמעות הסטטוסים מתוארת במתודולוגיית המחקרים.
מה נבדק
Section titled “ מה נבדק”המחקר ענה על ארבע שאלות:
- האם התקופה של shared-mode audio engine מתקצרת עם העלאת התדר?
- האם 16-bit מפחית עומס לעומת 24-bit ו-32-bit ב-48 kHz?
- האם השבתת אפקטי קול מערכתיים נותנת הפחתת עומס ניתנת לשחזור?
- כיצד שינוי endpoint rate קשור לעבודה הפנימית של XAudio2 עבור מקור 48 kHz?
המדידה לא בדקה איכות צליל, FPS, השהיית משחק או השהייה פיזית בין האות הדיגיטלי לרמקול.
תחום המחקר
Section titled “ תחום המחקר”| פרמטר | ערך |
|---|---|
| תאריך מדידה | 2026-08-20 |
| Windows | Windows 11 Pro 25H2, x64 |
| OS build | 26200.8655 |
| מעבד | AMD Ryzen 7 7800X3D, 8 ליבות / 16 תהליכונים |
| זיכרון עבודה | 32 GB |
| התקן | רמקולים, Realtek USB Audio |
| דרייבר | Realtek USB Audio 6.4.0.2422 מ-2025-08-07 |
| פורמט התקן מקורי | 48 kHz, 24-bit PCM, stereo |
| Shared mix format | 48 kHz, 32-bit float, stereo |
| אפקטים מקוריים | מופעלים |
| מקרי בדיקה | 17 מסלולים, מסלול אחד לכל מקרה |
| ניתוח מסלול | חמישה חלונות רצופים של 10 שניות |
המסלול המקורי תיעד את ענף Windows build 26200 ואת נתוני התקן האודיו. revision מלא, edition של Windows, דגם המעבד ונפח הזיכרון נקראו בנוסף מאותו מחשב ב-2026-08-24. בין המדידה לתיעוד החוזר של התצורה עברו ארבעה ימים.
מזהה endpoint ייחודי ותיעודי מערכת גולמיים אינם מפורסמים.
מתודולוגיה
Section titled “ מתודולוגיה”המקרים בוצעו בסדר אקראי. עבור כל אחד מהם שימשו 3 שניות חימום, לאחר מכן 52 שניות של תיעוד מערכת וחמישה חלונות ניתוח של 10 שניות.
נבדקו שני סוגי עומס:
- זרם WASAPI יציב ב-shared-mode להשוואת תדר, רזולוציה ואפקטים;
- עומס XAudio2 סינתטי עם 8, 32 או 64 voices פעילים ומקורות 44,1 או 48 kHz.
המדד העיקרי של Windows Audio — scheduler running time של התהליך audiodg.exe, מבוטא במילישניות עבודה לשנייה. בנפרד נקראו XAudio2 performance data, מספר glitches וסטטיסטיקת אובדן תיעוד.
חמשת החלונות של מסלול אחד מתואמים ומשמשים רק כפיזור תיאורי. הם אינם חמישה הרצות בלתי תלויות. העומס המערכתי הכולל ברקע השתנה, ולכן whole-machine CPU, DPC ו-ISR מוחלטים לא שימשו למסקנה הסופית.
תקופת מנוע האודיו
Section titled “ תקופת מנוע האודיו”| Endpoint rate | Frames | תקופה |
|---|---|---|
| 44,1 kHz | 441 | 10,0 מ״ש |
| 48 kHz | 480 | 10,0 מ״ש |
| 96 kHz | 960 | 10,0 מ״ש |
| 192 kHz | 1920 | 10,0 מ״ש |
ה-endpoint החזיר רק תקופה של 10 מ״ש. תקופות של 5 מ״ש ו-2,5 מ״ש לא נתמכו על ידי הדרייבר שלו. העלאת התדר הגדילה את מספר ה-frames לתקופה, אך לא קיצרה את משך התקופה.
זו תכונה של שילוב מסוים של התקן ודרייבר. Microsoft מציינת שגדלי buffer זמינים נקבעים על ידי audio driver, והאפליקציה יכולה לבקש וריאנטים נתמכים דרך IAudioClient3. לפרטים: Low Latency Audio.
תדר ו-audiodg
Section titled “ תדר ו-audiodg”בטבלה מוצגים חציון וטווח של חמישה חלונות בתוך מסלול אחד. היחידה мс/с מראה כמה מילישניות התהליך audiodg.exe פעל במשך שנייה אחת של תצפית.
| Endpoint rate | audiodg, חציון | טווח חלונות |
|---|---|---|
| 44,1 kHz | 4,34 מ״ש/ש | 4,24–4,86 מ״ש/ש |
| 48 kHz | 4,23 מ״ש/ש | 4,20–5,63 מ״ש/ש |
| 96 kHz | 4,77 מ״ש/ש | 4,72–5,70 מ״ש/ש |
| 192 kHz | 5,19 מ״ש/ש | 5,07–5,94 מ״ש/ש |
בסדרה הזו 96 ו-192 kHz לא הראו הפחתה בזמן audiodg.exe. אך לכל תדר היה מסלול אחד, והעומס ברקע השתנה. הטבלה אינה מוכיחה גודל CPU-הבדל אוניברסלי בין תדרים.
רזולוציה ב-48 kHz
Section titled “ רזולוציה ב-48 kHz”| Device format | audiodg, חציון | טווח חלונות |
|---|---|---|
| 16-bit | 4,07 מ״ש/ש | 4,03–4,35 מ״ש/ש |
| 24-bit | 4,23 מ״ש/ש | 4,20–5,63 מ״ש/ש |
| 32-bit | 4,20 מ״ש/ש | 4,16–4,64 מ״ש/ש |
הטווחים חופפים, ואין מספיק חזרות בלתי תלויות. לפי הסדרה הזו אין לקבוע שמעבר ל-16-bit נותן הפחתת עומס ניתנת לשחזור.
אפקטים מערכתיים
Section titled “ אפקטים מערכתיים”ב-48 kHz / 24-bit החציון של audiodg.exe היה 4,23 מ״ש/ש עם אפקטים מופעלים ו-4,39 מ״ש/ש עם אפקטים מושבתים. הערך הממוצע השתנה בכיוון ההפוך בגלל חלון אחד גבוה יותר במסלול המקורי.
יתרון מהימן של השבתת אפקטים לא הוכח. התוצאה אינה עילה להשבית אותם ללא בעיה קונקרטית עם Audio Processing Object או עם הדרייבר.
XAudio2 ואי-התאמת תדר
Section titled “ XAudio2 ואי-התאמת תדר”עבור מקור קבוע של 48 kHz ו-32 voices התקבלו XAudio2 performance data הבאים:
| Endpoint rate | Audio cycles/s | ביחס ל-48 kHz | הערכת תור |
|---|---|---|---|
| 44,1 kHz | 25 116 | 2,31× | 37,28 מ״ש |
| 48 kHz | 10 870 | 1,00× | 37,27 מ״ש |
| 96 kHz | 55 574 | 5,11× | 37,18 מ״ש |
| 192 kHz | 87 016 | 8,00× | 37,18 מ״ש |
Microsoft מגדירה את AudioCyclesSinceLastQuery כ-CPU cycles שה-XAudio2 הוציא על עיבוד אודיו מאז הבקשה הקודמת. CurrentLatencyInSamples הוא מרחק משוער בין הנתונים האחרונים שנמסרו לדרייבר לנתונים המושמעים. ראו XAUDIO2_PERFORMANCE_DATA ו-IXAudio2::GetPerformanceData.
העלאת endpoint rate במקרה הסינתטי הזה הגדילה את העבודה הפנימית של XAudio2, אך כמעט לא שינתה את הערכת התור שלו. עבור כל וריאנט התקבל performance summary אחד, ולכן המקדמים הם תיאור של הרצה זו, ולא תחזית אוניברסלית למשחקים.
יציבות המדידות
Section titled “יציבות המדידות”בכל 17 המסלולים נרשמו:
- 0 audio glitches;
- 0 ETW events שאבדו;
- 0 ETW buffers שאבדו.
מה אומת
Section titled “ מה אומת”- ב-endpoint שנחקר התקופה הזמינה של shared-mode נשארה 10 מ״ש ב-44,1, 48, 96 ו-192 kHz.
- העלאת התדר לא הפחיתה את התור הנמדד של XAudio2 במקרה הסינתטי.
- היתרון של 16-bit בזמן
audiodg.exeלא אומת. - היתרון של השבתת אפקטים מערכתיים לא אומת.
- 48 kHz / 24-bit תואם לפורמט המקורי של ההתקן ולא הראה הפסד מעשי לעומת הווריאנטים הסמוכים.
מה לא אומת
Section titled “ מה לא אומת”- התוצאה לא שוחזרה בהתקן אודיו אחר או ב-Windows build אחר.
- revision מלא של Windows והתצורה הכוללת של המחשב תועדו ארבעה ימים לאחר המדידה, ולא בתוך המסלול המקורי.
- השהיית DAC, ADC, acoustic או input-to-sound פיזית לא נמדדה.
- איכות צליל ושמיעוּת הבדלים לא הוערכו.
- ההשפעה על משחקים מסוימים, FPS ו-frametime לא נבדקה.
- התרומה של vendor APO בודד לא בודדה.
- אי אפשר להעביר את אפקט ה-CPU הכולל המדויק למעבדים בעלי ביצועים אחרים.
מגבלות
Section titled “מגבלות”ETL גולמיים אינם מפורסמים: הם מכילים מידע לא קשור על מצב תהליכים ומערכת. הטבלאות לעיל נבחרו ידנית ואינן מכילות endpoint ID ייחודי, usernames, נתיבים מקומיים או command lines.
המחקר והכלים שבהם נעשה שימוש שייכים למפתח של BoosterX, ולכן למפתח יש אינטרס ישיר בתוצאות. המתודולוגיה וגבולות התחולה מתוארים לעיל, ואת המסקנות אפשר לאמת לפי הנתונים הפתוחים והמקורות הציבוריים המפורטים.
מסקנה מעשית
Section titled “ מסקנה מעשית”עבור ההתקן שנחקר סביר להשאיר 48 kHz / 24-bit ולא להשבית אפקטים מערכתיים ללא בעיה מאובחנת קונקרטית. הבחירה ב-96 או 192 kHz לשם השהייה נמוכה יותר אינה נתמכת במחקר זה.
זו אינה הגדרה אוניברסלית לכל ה-DAC והדרייברים. התקן שמדווח על shared-mode period קטן יותר או משתמש בנתיב אודיו אחר דורש מדידה נפרדת.
שחזור מצב
Section titled “שחזור מצב”לאחר הסיום שוחזרו 48 kHz / 24-bit PCM והמצב המקורי של האפקטים המערכתיים. לא נותרו סשנים פעילים של תיעוד.
מקורות
Section titled “מקורות”- Windows Performance Recorder — תיעוד מערכתי של אירועים מבוסס ETW.
- Windows 11 release information — התאמת גרסה 25H2 לענף OS build 26200.
- Low Latency Audio — תקופת מנוע האודיו, תפקיד הדרייבר והיכולות של
IAudioClient3. - XAUDIO2_PERFORMANCE_DATA — ערכי cycles, queue latency ו-glitches.
- IXAudio2::GetPerformanceData — קבלת XAudio2 performance data.
המחקר בוצע: 2026-08-20. מקורות ציבוריים וניסוחים נבדקו: 2026-08-24.
היסטוריית שינויים
Section titled “היסטוריית שינויים”- 2026-09-20: המבנה הובא למבנה המחייב — “מגבלות” ו“שחזור מצב” הופרדו לפרקים נפרדים; מפרידים עשרוניים ויחידות זמן הובאו לסגנון הסדרה (פסיק, “מ״ש”); נוסף כתב ויתור על ניגוד עניינים.
- 2026-08-24: פרסום ראשון; פורסמו מדידות על מערכת אחת, גבולות העברת התוצאה ושחזור המצב.