Mengapa audio terputus padahal penggunaan CPU rendah? — Memahaminya dari buffer dan tenggat

Saat mendengarkan musik, sesekali audio terputus dengan bunyi “tek”. Di Task Manager penggunaan CPU hanya sekitar 10%, tetapi audionya saja yang tidak stabil. Dalam situasi seperti ini, mengapa audio bisa terputus padahal CPU masih longgar?

Walaupun penggunaan CPU rendah, audio bisa terputus jika pengisian ulang data audio berikutnya tidak memenuhi tenggat. Sebabnya, data berikutnya harus sudah diserahkan selagi audio yang tersisa di buffer sedang diputar. Keterlambatan pengisian ulang akibat menunggu data atau lock, DPC/ISR pada CPU logis yang dibutuhkan, dan sebagainya dapat terjadi meskipun CPU secara keseluruhan tidak terpakai habis. Exclusive-Mode Streams, CPU Analysis

Namun, bunyi “tek” yang terdengar saja belum cukup untuk memastikan bahwa itu underrun. Sumber audio, aplikasi, efek audio, perangkat output, dan lain-lain juga dapat menimbulkan gejala serupa. Pertama, lakukan perbandingan dengan sumber audio yang sama: ubah kondisi satu per satu lalu kembalikan ke semula; jika masih belum bisa dipersempit, rekam rentang sebelum dan sesudah audio terputus. Fix distorted or crackling audio in Windows

Artikel ini membahas pertanyaan tersebut beserta pertanyaan lanjutannya: “Apakah cukup memperbesar buffer?” dan “Apa yang perlu dibandingkan dan direkam agar penyebabnya bisa dipersempit?”. Artikel ini tidak dimaksudkan untuk memastikan penyebab gangguan tertentu hanya dari penggunaan CPU atau dari bunyi yang terdengar.

Sasaran utamanya adalah output audio di Windows 11. Output bawaan, berkabel, USB, Bluetooth, dan sebagainya menjadi objek perbandingan; untuk perangkat lunak produksi musik (DAW), artikel ini juga membahas perbandingan ketika aplikasi atau driver menyediakan pengaturan buffer. Desain sistem perekaman secara keseluruhan dan diagnosis komunikasi nirkabel per perangkat tidak dibahas secara menyeluruh.

Dalam penjelasan, mode bersama dipakai sebagai contoh dasar. Jalur, ukuran buffer, dan siklus pemrosesan yang sebenarnya berbeda-beda menurut aplikasi, API, driver, dan perangkat, dan tidak ada layar pengaturan buffer yang sama untuk semua aplikasi. Low Latency Audio

Penggunaan CPU, sisa 10 milidetik, waktu pengisian ulang, dan angka lain yang ditampilkan di sini adalah asumsi untuk penjelasan. Ini bukan laporan pengukuran nyata atas reproduksi atau perbaikan pada PC tertentu. Langkah-langkah di bagian akhir adalah prosedur pemeriksaan yang dilakukan pembaca di lingkungannya sendiri.

Mekanismenya dapat dibaca berurutan mulai dari bagian berikut, “Buffer pemutaran audio”. Langkah untuk menyelidiki audio terputus ada di “Membandingkan kondisi reproduksi” dan “Merekam audio terputus dengan WPR”.

Pada diagram, garis utuh menunjukkan relasi yang selalu berlaku dan garis putus-putus menunjukkan relasi bersyarat (syaratnya ada pada penjelasan masing-masing relasi di halaman rincian). Daftar lengkap relasi (total 5, beserta bukti dan tingkat kepastian) serta definisi konsep utama dikumpulkan di halaman rincian peta pengetahuan (dalam bahasa Jepang). Data: JSON-LD / Turtle

Buffer pemutaran audio

Menyimpan file musik saja tidak membuat speaker berbunyi. Aplikasi menyiapkan data audio dan mengirimkannya ke perangkat output melalui Windows dan driver. Buffer pemutaran audio adalah area yang menampung sementara data yang akan diputar sesudahnya. Selagi perangkat memutar data saat ini, pihak pemasok menyiapkan data berikutnya dan mengisinya ulang. Rendering a Stream

flowchart TB
    accTitle: Menampung sedikit audio di depan sebelum diputar
    accDescr: Alur mengisi ulang data audio yang sudah disiapkan ke buffer dan menyiapkan data berikutnya selagi pemutaran di sisi perangkat berjalan.
    A["Siapkan audio berikutnya"] --> B["Isi ulang ke buffer"]
    B --> C["Putar audio yang tertampung"]
    C -.->|"Sebelum habis"| A

Gambar 1: Agar pemutaran berlanjut, pengisian ulang harus mampu mengejar pihak yang memakai audio.

Gambar 1 adalah diagram konseptual yang hanya menunjukkan hubungan antara pengisian ulang dan konsumsi. Diagram ini tidak menganggap beberapa buffer yang ada di jalur audio sebenarnya sebagai satu area fisik. Low Latency Audio

Peran buffer adalah menyerap selisih waktu yang singkat antara pihak yang menyiapkan audio dan pihak yang memakainya, sehingga pemutaran tersambung tanpa jeda. Namun, kapasitas buffer berbeda dengan jumlah data yang belum diputar yang saat ini ada di dalamnya. “Memiliki kapasitas 10 milidetik” tidak berarti selalu tersisa data sebanyak 10 milidetik. Rendering a Stream

Di sini, batasan waktu untuk menyerahkan data berikutnya yang diperlukan sebelum data yang sedang diputar habis terpakai disebut tenggat pengisian ulang. Pemrosesan audio adalah pemrosesan yang menuntut “sudah siap sebelum waktu bunyinya”. “Pada akhirnya berhasil dihitung” saja tidak cukup. Keadaan ketika pasokan tidak tepat waktu sehingga data yang akan diputar habis disebut underrun, dan ini berujung pada audio terputus atau bunyi klik. Meskipun data tiba terlambat, jeda yang sudah terdengar tidak dapat diisi kembali belakangan. Exclusive-Mode Streams

Jalur data audio

Dalam mode bersama yang biasa, audio engine Windows menerima data yang disiapkan aplikasi pemutar, mencampur beberapa suara atau menerapkan efek, lalu menyerahkannya ke driver dan perangkat output. Aplikasi pemutar terlibat dalam pembacaan sumber audio sekaligus pemasokan ke tujuan output, sedangkan driver dan perangkat output membawa data ke sisi perangkat lalu memutarnya. Low Latency Audio

flowchart TB
    accTitle: Jalur yang dilalui data audio dalam mode bersama
    accDescr: Audio engine melakukan pencampuran dan pemrosesan efek pada data yang disiapkan aplikasi pemutar lalu menyerahkannya ke driver, dan perangkat output memutarnya.
    A["Aplikasi pemutar: siapkan data"] --> E["Audio engine: campur, efek"]
    E --> D["Driver: bawa ke perangkat"]
    D --> O["Perangkat output: putar"]

Gambar 2: Contoh mode bersama. Pemrosesan dan buffer di tengah jalur berubah menurut API dan perangkat.

Sisi perangkat juga bisa memiliki pemrosesan dan buffer sendiri, sehingga latensi keseluruhan tidak ditentukan oleh buffer di sisi aplikasi saja. Penjelasan ini mengasumsikan jalur mode bersama dan tidak berarti bahwa semua API melewati pemrosesan yang sama. Low Latency Audio

Pengisian ulang saat tersisa 10 milidetik

Misalkan saat ini di buffer masih tersisa data yang belum diputar sebanyak 10 milidetik. Jika pengisian ulang berikutnya terjadi 8 milidetik kemudian, audio tersambung selagi sisanya masih ada; tetapi jika pengisian ulang baru bisa dilakukan 12 milidetik kemudian, dalam contoh yang disederhanakan ini data habis pada titik 10 milidetik.

flowchart TB
    accTitle: Sisa sama-sama 10 milidetik, hasilnya berbeda menurut waktu pengisian ulang
    accDescr: Dengan asumsi untuk penjelasan berupa sisa data pemutaran 10 milidetik, diagram menunjukkan bahwa pengisian ulang setelah 8 milidetik masih tepat waktu, sedangkan setelah 12 milidetik terjadi sesudah data habis terpakai.
    A["Sisa 10 milidetik"] --> B{"Pengisian ulang berikutnya"}
    B -->|"Setelah 8 milidetik"| C["Tersambung"]
    B -->|"Setelah 12 milidetik"| D["Habis pada 10 milidetik"]

Gambar 3: Contoh dengan waktu yang disederhanakan. Yang penting bukan hanya apakah pengisian ulang berhasil, tetapi juga kapan pengisian ulang berhasil.

Penggunaan CPU dan keterlambatan pengisian ulang

Yang ditunjukkan penggunaan CPU adalah tingkat kesibukan dalam rentang waktu tertentu. Hal yang dilihatnya berbeda dari apakah pemrosesan audio dapat dieksekusi tepat pada saat dibutuhkan. Walaupun CPU longgar di sebagian besar waktu dalam satu detik, jika ada satu rentang 12 milidetik ketika pengisian ulang tidak bisa dilakukan, satu keterlambatan itu saja dapat membuat audio terputus. Kelonggaran kemampuan pemrosesan yang tersisa sesudahnya tidak dapat mengembalikan waktu pemutaran yang sudah lewat. CPU Analysis

flowchart TB
    accTitle: Kelonggaran rata-rata dan satu kali keterlambatan pengisian ulang
    accDescr: Walaupun CPU longgar di sebagian besar waktu dalam satu detik, jika ada satu rentang 12 milidetik ketika pengisian ulang tidak bisa dilakukan, satu keterlambatan itu saja dapat membuat audio terputus.
    A["CPU longgar di sebagian besar 1 detik"] --> B["Sekali 12 milidetik gagal isi ulang"]
    B --> C["Sekali itu audio terputus"]

Gambar 4: Meskipun rata-ratanya longgar, waktu pemutaran yang sudah lewat tidak dapat dikembalikan.

Yang memangkas sisa waktu sebelum tenggat bukan hanya waktu komputasi. Termasuk juga waktu tunggu sampai pemrosesan dimulai dan waktu tunggu sampai data yang diperlukan tiba. Karena itu, pertanyaan penyelidikan pun diubah dari sekadar “berapa persen penggunaan CPU” menjadi “pada saat audio terputus, apa yang sedang ditunggu oleh audio berikutnya”.

Menunggu data dan lock

Misalkan pemrosesan yang menyiapkan data audio sedang menunggu pembacaan file selesai. Hal yang sama berlaku ketika menunggu lock yang dipegang pemrosesan lain di dalam aplikasi. Pemrosesan yang sedang menunggu itu sendiri hampir tidak memakai CPU, tetapi di sisi perangkat pemutaran terus berjalan dan audio yang tersisa terus berkurang. Results for the Streaming Media Performance Assessment, CPU Analysis

flowchart TB
    accTitle: Pemutaran tetap berjalan selama menunggu tanpa memakai CPU
    accDescr: Selama pemrosesan audio menunggu data atau lock, pemrosesan itu tidak memakai CPU, tetapi pemutaran tetap berjalan sehingga sisanya berkurang, dan jika pengisian ulang terlambat buffer bisa habis.
    A["Pemrosesan audio menunggu data"] --> B["Pemrosesan itu tidak memakai CPU"]
    B --> C["Sementara itu pemutaran berjalan"]
    C --> D["Isi ulang terlambat, stok habis"]

Gambar 5: Tidak memakai CPU dan pekerjaan yang diperlukan sudah selesai adalah dua hal yang berbeda.

DPC, ISR, dan thread audio

ISR adalah pemrosesan yang menangani interupsi dari perangkat. DPC adalah mekanisme yang menunda sisa pekerjaan ke belakang agar penanganan interupsi tetap singkat. DPC biasa dieksekusi lebih dulu daripada thread biasa pada CPU logis yang sama, dan selama DPC biasa atau ISR berjalan, CPU logis tersebut tidak dapat mengeksekusi thread biasa. Introduction to DPCs, CPU Analysis

Walaupun CPU secara keseluruhan longgar, jika pemrosesan ini berlangsung lama atau sering terjadi pada CPU yang dibutuhkan pemrosesan audio, pasokan bisa terlambat. Materi analisis performa audio dan video dari Microsoft juga menyebut DPC/ISR yang panjang dari driver jaringan, penyimpanan, grafis, dan sebagainya sebagai kandidat penyebab audio terputus. Memeriksa perangkat yang mengeluarkan suara saja belum tentu cukup. Results for the Streaming Media Performance Assessment

flowchart TB
    accTitle: Ketika respons terhadap perangkat menunda eksekusi audio
    accDescr: Jika DPC biasa atau ISR berlangsung lama pada CPU yang dibutuhkan pemrosesan audio, eksekusi thread tertunda dan dapat memengaruhi tenggat pengisian ulang.
    A["DPC, ISR di CPU yang sama"] -->|"Jika berlangsung lama"| B["Eksekusi audio harus menunggu"]
    B --> C["Isi ulang audio berikutnya terlambat"]
    C --> D["Sisa habis, audio terputus"]

Gambar 6: Pemrosesan selain untuk perangkat yang mengeluarkan suara juga dapat memengaruhi pengisian ulang audio secara tidak langsung.

Tidak ada garis batas umum seperti “jika DPC di bawah sekian mikrodetik, audio tidak akan terputus di PC mana pun”. Nilai peringatan dalam materi evaluasi performa adalah nilai pada kondisi evaluasi tersebut, dan tidak dijadikan standar keamanan dengan melepaskannya dari tenggat pengisian ulang dan kelonggaran buffer yang sebenarnya. Results for the Streaming Media Performance Assessment

Ukuran buffer dan latensi pemutaran

Pada kondisi yang sama, menambah audio yang ditampung di depan memudahkan penyerapan keterlambatan pengisian ulang yang sementara, tetapi audio yang baru dibuat harus menunggu di belakang audio yang sudah tertampung. Waktu tunggu itu mungkin masih dapat diterima jika sekadar mendengarkan musik, tetapi ketika memainkan keyboard musik atau ketika mengolah suara dari mikrofon lalu mendengarkannya sendiri, selisih antara tindakan dan bunyi akan terasa mengganggu. Exclusive-Mode Streams, Low Latency Audio

flowchart TB
    accTitle: Kelonggaran buffer dan respons yang tertunda
    accDescr: Menambah audio yang ditampung di depan memudahkan penyerapan keterlambatan pengisian ulang yang sementara, tetapi waktu tunggu sampai audio baru diputar juga bertambah.
    A["Tambah audio yang ditampung"] --> B["Lebih mudah menyerap keterlambatan"]
    B -->|"Sebagai gantinya"| C["Audio baru menunggu di belakang"]
    C --> D["Dari tindakan ke bunyi tertunda"]

Gambar 7: Memperbesar buffer adalah penyesuaian yang menciptakan kelonggaran dengan imbalan kecepatan respons.

Bukan “makin kecil makin berkinerja tinggi”, bukan pula “makin besar makin benar”. Pertahankan kecepatan respons yang diperlukan sambil menyisakan kelonggaran agar tidak terputus.

Penyesuaian dengan memperbesar buffer adalah cara menciptakan kelonggaran terhadap keterlambatan pasokan yang sementara. Jika pasokan rata-rata itu sendiri tidak mampu mengejar konsumsi, memperbesar buffer yang terbatas hanya memperpanjang waktu sampai buffer habis, dan juga tidak mengatasi terputusnya koneksi perangkat. Ini juga bukan anjuran bahwa semua masalah selesai dengan memakai mode eksklusif. Exclusive-Mode Streams

Audio 48kHz dengan 480 frame

Frame PCM adalah satuan yang menghimpun sampel semua kanal yang diputar pada titik waktu yang sama. Bukan berarti jumlah frame dikalikan dua untuk menghitung waktu karena audionya stereo. Durasi audio yang diwakili jumlah frame dihitung dengan “jumlah frame ÷ sample rate”; untuk 480 frame pada 48kHz hasilnya 480 ÷ 48000 detik, yaitu 10 milidetik. Jika jumlah frame ditambah dengan tetap pada 48kHz, durasi audio yang dapat ditampung juga makin panjang. Rendering a Stream

Waktu ini berbeda dari latensi total sejak tuts ditekan sampai bunyinya terdengar. Sebabnya, masih ada waktu untuk aplikasi, driver, perangkat, serta buffer dan pemrosesan lainnya. Nilai pengaturan di DAW juga dibaca setelah memastikan satuannya dan buffer yang menjadi sasarannya. Low Latency Audio

flowchart TB
    accTitle: Waktu yang dihitung dari jumlah frame dan latensi total
    accDescr: 10 milidetik hasil pembagian 480 frame dengan 48000 adalah waktu yang diwakili buffer; setelah ditambah pemrosesan aplikasi, driver, perangkat, dan lainnya, barulah menjadi latensi total dari tuts sampai bunyi.
    A["480 ÷ 48000"] --> B["10 milidetik yang diwakili buffer"]
    B -->|"Ditambah pemrosesan lain"| C["Latensi total dari tuts ke bunyi"]

Gambar 8: Waktu yang dihitung dari jumlah frame hanyalah sebagian dari latensi total.

Membandingkan kondisi reproduksi

Pertama, persempit kombinasi yang dapat mereproduksi masalah, dan lanjutkan ke perekaman terperinci hanya bila diperlukan. Berikut ini adalah prosedur untuk memastikan penyebab, bukan daftar tindakan untuk menjalankan semua perubahan pengaturan sekaligus.

Simpan pekerjaan Anda, selesaikan rapat atau perekaman yang sesungguhnya, lalu coba dengan volume yang tidak membebani telinga. Catat tujuan output semula, peningkatan audio, nilai buffer, dan sebagainya agar dapat dikembalikan. Lewati butir yang pengaturannya tidak disediakan, dan jangan mengubah registry atau sejenisnya hanya untuk memunculkan butir pengaturan.

1. Tentukan sumber audio pendek dan durasi pengamatan yang sama, lalu pastikan masalah tereproduksi pada kondisi semula.

   Catat versi Windows, nama dan versi aplikasi, perangkat output, cara koneksi, serta versi driver. Catat juga waktu, tindakan, dan berapa kali audio terputus. Jika masalah tidak tereproduksi pada kondisi semula, jangan menilainya sudah membaik; kembalilah memastikan kondisi yang mereproduksinya.

2. Pilih satu perbandingan dari tabel berikut, lalu putar dengan hanya mengubah kondisi tersebut.

   Kondisi yang dibandingkan	Yang diperiksa
   Sumber audio yang disimpan di komputer dan pemutaran lewat jaringan	Apakah hanya terjadi lewat jaringan. Jika isinya sama tetapi format atau jalur pemrosesannya berbeda, catat juga hal itu.
   Memutar sumber audio yang sama dengan aplikasi lain	Apakah terpusat pada aplikasi tertentu.
   Output Bluetooth dan sejenisnya dibandingkan output bawaan atau berkabel	Apakah terpusat pada jalur output tertentu.
   Peningkatan audio aktif dan nonaktif	Apakah berubah dalam kombinasi dengan pemrosesan efek.
   Buffer saat ini di DAW dan sejenisnya dibandingkan nilai satu tingkat lebih besar	Apakah berubah jika kelonggaran tampungan di depan ditambah. Apakah keterlambatan dari tindakan ke bunyi juga dapat diterima.

3. Jika membandingkan peningkatan audio, matikan pengaturannya untuk sementara pada output yang diuji.

   Di “Pengaturan” → “Sistem” → “Suara” pada Windows, pilih output yang diuji, dan jika tersedia di lingkungan Anda, matikan “Peningkatan audio”. Jika tampilan atau ada tidaknya butir tersebut berbeda, periksa panduan untuk versi dan perangkat itu. Fix distorted or crackling audio in Windows

4. Kembalikan pengaturan yang diubah ke semula, lalu coba sekali lagi dengan sumber audio dan durasi pengamatan yang sama.

   Jajarkan hasil “kondisi semula”, “kondisi dengan satu perubahan”, dan “kondisi yang dikembalikan”. Perubahan yang tidak berefek dikembalikan dulu ke keadaan semula sebelum beralih ke perbandingan lain. Jika kombinasi pengaturan terus diubah-ubah, Anda tidak akan tahu apa yang sebenarnya berpengaruh.

5. Jika mencoba mengganti driver, lakukan setelah memastikan sumber distribusi resmi dan cara pemulihannya.

   Gunakan Windows Update atau distribusi resmi dari produsen perangkat, dan catat versi serta pengaturan sebelum dan sesudah perubahan. Pastikan terlebih dahulu bahwa perubahan dapat dikembalikan, dan pada PC yang dikelola, berkonsultasilah dengan administrator. Jangan menganggap masalah selesai hanya karena audio sekali berhasil diputar tepat setelah pembaruan; periksa dengan kondisi reproduksi yang sama. Fix distorted or crackling audio in Windows

Hasil yang ingin diperoleh adalah catatan yang mengaitkan gejala dengan kondisi, misalnya “tereproduksi ketika memakai output ini dengan aplikasi ini”. Bahkan jika ditemukan pengaturan yang memperbaiki keadaan, pisahkan hal itu dari kepastian penyebab.

flowchart TB
    accTitle: Perbandingan dengan mengubah satu kondisi lalu mengembalikannya
    accDescr: Pastikan reproduksi dengan sumber audio yang sama, ubah satu kondisi seperti aplikasi atau output, dan catat juga hasil ketika kondisi dikembalikan ke semula.
    A["Putar dengan kombinasi semula"] --> B["Ubah satu kondisi lalu putar"]
    B --> C["Kembalikan lalu putar"]
    C --> D["Catat kondisi dan waktu putus"]

Gambar 9: Alih-alih sekali membaik, pastikan bahwa kondisi dan gejala berkorespondensi secara berulang.

Reproduksibilitas sebelum dan sesudah mengubah kondisi

“Gejala berhasil diredam”, “kondisi berhasil dipersempit”, dan “akar penyebab berhasil diidentifikasi” adalah capaian yang berbeda. Catat kesimpulan sesuai dengan cakupan yang berhasil diamati.

flowchart TB
    accTitle: Tiga hasil yang menunjukkan keterkaitan dengan kondisi
    accDescr: Jika masalah tereproduksi pada kondisi semula, membaik saat satu kondisi diubah, dan tereproduksi lagi saat dikembalikan, itu menjadi petunjuk keterkaitan dengan kondisi tersebut, tetapi dipisahkan dari kepastian penyebab.
    A["Tereproduksi pada kondisi semula"] --> B["Membaik saat satu diubah"]
    B --> C["Tereproduksi saat dikembalikan"]
    C --> D["Petunjuk keterkaitan kondisi itu"]

Gambar 10: Meskipun ketiganya terpenuhi, yang diketahui hanya sebatas petunjuk keterkaitan.

Penggunaan CPU yang rendah bukan bukti bahwa tenggat audio terpenuhi. Sebaliknya, adanya audio terputus saja juga tidak membuktikan bahwa keterlambatan pengisian ulang adalah akar penyebabnya. Bandingkan sumber audio, pemrosesan aplikasi, efek, jalur output, dan sebagainya, lalu nilai dalam cakupan yang diamati. Fix distorted or crackling audio in Windows

Saat menerapkan solusi sementara, catat pengaturan semula, isi perubahan, durasi pengamatan, apakah masalah muncul kembali, dan latensi yang dapat diterima. Jika akar penyebab belum dipastikan, catat juga hal itu.

Merekam audio terputus dengan WPR

Langkah ini dilakukan jika perbandingan kondisi saja tidak cukup untuk mempersempit masalah, atau jika ingin menyelidiki pemrosesan di sisi driver. WPR adalah alat untuk merekam, sedangkan WPA dipakai untuk menganalisis lini waktu yang sudah disimpan. Siapkan Windows Performance Toolkit, hak akses yang diperlukan untuk merekam, dan lokasi penyimpanan file ETL. Saat memasang alat dan merekam di PC yang dikelola, mintalah bantuan administrator. Nama tampilan dan profile yang tersedia diperiksa pada versi yang terpasang. Windows Performance Recorder

File ETL dapat memuat nama proses, path file, dan sebagainya. Sebelum merekam, pastikan aturan internal perusahaan dan pihak yang akan menerima file, dan jangan melampirkannya apa adanya di tempat publik. Jika ada sesi perekaman lain yang sedang berjalan, jangan menghentikannya sendiri; tanyakan kepada penanggung jawabnya. WPR How-to Topics

1. Buka “More Options” di WPR dan pilih profile perekaman yang sesuai dengan tujuan.

   Profile standar mencakup “Audio glitches” dan “CPU usage”. Pilih pengaturan yang memungkinkan penyelidikan diskontinuitas audio dan aktivitas CPU. Periksa profile yang tersedia, nama tampilan, dan isi yang dikumpulkan pada versi yang terpasang, dan jangan memakai pengaturan yang merekam semua jenis dalam waktu lama. Built-in Recording Profiles

2. Mulai perekaman sebelum mereproduksi audio terputus.

   Jika muncul konfirmasi untuk menghentikan perekaman yang sudah ada, jangan dilanjutkan; batalkan proses mulai dan tanyakan kepada penanggung jawabnya. Samakan kondisinya dengan saat tanpa perekaman, dan catat juga kemungkinan bahwa beban perekaman itu sendiri mengubah gejala. WPR How-to Topics

3. Putar dengan kondisi yang ditemukan saat perbandingan, lalu catat waktu audio terputus dan tindakan yang dilakukan.

   Sertakan juga sedikit rentang tanpa masalah sebelum dan sesudah gejala. Untuk rekaman yang tidak berhasil mereproduksi masalah, tuliskan fakta itu dengan jelas dan jangan memperlakukannya sebagai rekaman yang berhasil menangkap penyebab.

4. Setelah masalah tereproduksi, akhiri perekaman dengan “Save” dan simpan file ETL.

   Dengan “Cancel”, rekaman tidak disimpan. Catat lokasi penyimpanan, kondisi reproduksi, ada tidaknya rekaman, dan ada tidaknya peringatan event hilang. Pada rekaman yang memiliki bagian hilang, jangan menilai rentang yang tidak terlihat sebagai normal. WPR How-to Topics

Jika file ETL dan catatan tentang waktu, tindakan, dan kondisi saat audio terputus sudah lengkap, Anda siap mencocokkannya di WPA. Berhasil menyimpan rekaman saja belum menjamin event yang diperlukan sudah terekam. Periksa isinya di bagian berikutnya, “Eksekusi dan penantian di sekitar saat audio terputus”.

flowchart TB
    accTitle: Mengambil rekaman singkat yang mencakup audio terputus
    accDescr: Mulai perekaman dengan WPR, reproduksi gejala dan catat waktunya, lalu hentikan, simpan, dan periksa rekamannya di WPA.
    A["Mulai rekam dengan WPR"] --> B["Reproduksi putus dengan kondisi sama"]
    B --> C["Catat waktu dan tindakan, simpan"]
    C --> D["Perbesar rentang sekitar di WPA"]

Gambar 11: Melihat penggunaan CPU setelah gejala berakhir tidak cukup; diperlukan rekaman dari rentang ketika gejala terjadi.

Eksekusi dan penantian di sekitar saat audio terputus

Siapkan file ETL yang sudah disimpan dan catatan waktu reproduksi. Berikut ini adalah titik awal penyelidikan di WPA. Jika diperlukan analisis terperinci yang mencakup stack dan symbol, perhatikan penanganan rekaman dan mintalah bantuan administrator atau pengembang.

1. Buka ETL di WPA, lalu perbesar rentang sebelum dan sesudah audio terputus berdasarkan event audio yang berhasil direkam dan waktu reproduksi.

   Sisakan juga rentang tanpa gejala untuk perbandingan. Jangan hanya melihat peringkat nilai maksimum; bandingkan dengan menyamakan rentang waktunya.

2. Pada rentang yang sama, periksa “DPC/ISR” dan “CPU Usage (Precise)”.

   Jika data yang diperlukan tidak ada, periksa apakah profile yang dipakai dapat merekamnya, lalu kembali ke perekaman WPR. Tidak adanya rekaman berbeda dengan tidak adanya masalah. CPU Analysis, Built-in Recording Profiles

3. Bedakan apakah thread yang terkait dengan audio sebenarnya siap dieksekusi tetapi menunggu giliran, atau sedang menunggu data dan sejenisnya.

   Jika yang pertama, cocokkan apakah DPC/ISR dan sejenisnya berjalan lama pada CPU logis yang terkait. Jika yang kedua, telusuri apa yang mengakhiri penantian itu melalui event dan stack yang berhasil direkam. Karena thread yang sedang berjalan juga bisa disela oleh interupsi, jangan membatasi diri pada waktu Ready saja; tumpangkan juga rentang DPC/ISR.

4. Catat sekaligus kesesuaian waktu dengan audio terputus, CPU yang terkait, dan hasil ketika kondisi diubah.

   Jangan memastikan perangkat atau driver tertentu sebagai penyebab hanya dari nama modul DPC/ISR yang panjang. Ada kemungkinan Anda sedang melihat nilai besar pada waktu lain, atau bagian bersama yang dilalui banyak perangkat.

flowchart TB
    accTitle: Menyelidiki cara menunggu pada rentang audio terputus
    accDescr: Perbesar rentang sebelum dan sesudah audio terputus untuk melihat status thread audio. Jika siap dieksekusi tetapi menunggu giliran, cocokkan dengan DPC dan ISR pada CPU yang sama; jika menunggu data dan sejenisnya, telusuri pemrosesan yang mengakhiri penantian.
    A["Perbesar rentang sekitar putus"] --> B{"Status thread"}
    B -->|"Menunggu giliran"| C["DPC, ISR"]
    B -->|"Menunggu data"| D["Proses yang mengakhiri tunggu"]

Gambar 12: Jangan hanya memungut nilai maksimum; baca dengan menumpangkannya pada rentang ketika pemrosesan audio dibutuhkan.

Jika penyebab tidak dapat diidentifikasi, serahkan penyelidikan dalam status belum dipastikan. Sertakan versi OS, aplikasi, perangkat, dan driver, langkah reproduksi, hasil sebelum dan sesudah perubahan, waktu kejadian, profile pengumpulan, dan ada tidaknya peringatan event hilang. Bagikan ETL hanya kepada pihak yang menangani penyelidikan, sesuai aturan internal perusahaan.

Pembacaan lebih awal di aplikasi audio

Jika Anda membuat aplikasi audio sendiri, rancang agar pemrosesan yang mengisi buffer berikutnya selalu memenuhi tenggat setiap kali. WASAPI menyediakan cara untuk menerima, melalui event, saat buffer dapat diproses. Exclusive-Mode Streams

MMCSS adalah mekanisme yang mengalokasikan sumber daya CPU ke thread pemrosesan multimedia yang memiliki batasan waktu. MMCSS tidak memiliki fungsi untuk menyiapkan data dari disk lebih awal atau menghilangkan penantian lock. Bahkan saat memanfaatkan alokasi oleh MMCSS, desain untuk menyiapkan data dan mengurangi penantian tetap diperlukan secara terpisah. Multimedia Class Scheduler Service

flowchart TB
    accTitle: Cakupan yang ditangani MMCSS
    accDescr: MMCSS mengalokasikan sumber daya CPU ke thread pemrosesan yang memiliki batasan waktu, tetapi persiapan data dan pengurangan penantian lock dilakukan dengan desain terpisah.
    M["MMCSS: alokasikan sumber daya CPU"] -.->|"Perlu terpisah"| D["Persiapan data dan kurangi tunggu"]

Gambar 13: Alokasi sumber daya CPU dan desain agar data tepat waktu adalah dua pekerjaan yang berbeda.

Prinsip desainnya adalah memisahkan pemrosesan yang membaca dari file atau jaringan dari pemrosesan yang menyerahkan audio. Persiapan yang waktunya sulit diperkirakan dilakukan lebih awal, dan serah terima memakai buffer yang dialokasikan sebelumnya. Di sisi audio, susun agar tidak perlu menunggu respons UI, lock yang lama, atau penulisan log sinkron.

flowchart TB
    accTitle: Memisahkan persiapan yang sulit diperkirakan waktunya dari pasokan audio
    accDescr: Desain yang melakukan pembacaan dan sejenisnya pada pemrosesan awal, menyerahkan data yang sudah disiapkan ke pemrosesan audio melalui buffer, sehingga penantian lama tepat sebelum tenggat berkurang.
    A["Siapkan data di pemrosesan awal"] --> B["Area serah terima pra-alokasi"]
    B --> C["Pemrosesan audio serahkan bagiannya"]
    C --> D["Pasok ke tujuan output audio"]

Gambar 14: Keluarkan pekerjaan yang memakan waktu dari saat tepat sebelum serah terima audio.

Jika sisi persiapan berhenti lama, stok tetap akan habis meskipun sudah dipisahkan seperti ini. Bukan hanya waktu pemrosesan rata-rata, catat juga saat-saat munculnya pemrosesan atau penantian yang lama dan berapa kali pasokan gagal, dengan cara yang tidak mengganggu pemrosesan audio. Periksa ukuran buffer dan periode yang benar-benar dipilih melalui API atau driver, dan jangan mengasumsikan nilai yang ditentukan dipakai apa adanya. Rendering a Stream, Low Latency Audio

Contoh angka maupun contoh desain hanya untuk penjelasan, bukan nilai pengaturan yang direkomendasikan untuk perangkat tertentu, dan bukan jaminan bahwa audio tidak akan terputus di lingkungan mana pun.

Dampak prioritas real-time

Tindakan pengguna mengubah seluruh pemutar ke prioritas “Realtime” tidak dianjurkan untuk semua kasus. Ada risiko mengganggu pemrosesan penting lainnya, dan menaikkan prioritas thread biasa tidak serta-merta menghilangkan DPC/ISR maupun penantian data dan lock. Dalam pengembangan, gunakan mekanisme seperti MMCSS dan desain yang tidak membawa penantian lama ke dalam pasokan audio. Scheduling Priorities, CPU Analysis

flowchart TB
    accTitle: Penantian yang tetap ada meskipun diubah ke prioritas real-time
    accDescr: Meskipun pemutar disetel ke prioritas real-time, thread biasa tidak dapat mendahului DPC atau ISR pada CPU yang sama, penantian data dan lock tetap ada, dan ada risiko mengganggu pemrosesan penting lainnya.
    A["Pemutar ke prioritas real-time"] --> B["Tak bisa mendahului DPC, ISR"]
    B --> C["Penantian data, lock tetap ada"]
    C --> D["Risiko mengganggu proses lain"]

Gambar 15: Meskipun prioritas dinaikkan, penantian yang menunda pengisian ulang audio tetap ada.

Artikel terkait

• “Penjadwalan prosesor” dan pengaturan layanan latar belakang di Windows
• Memilah masalah disk 100% di Windows dengan aman
• Mengapa RDP terasa berat padahal koneksinya cepat?

Referensi

• Microsoft Learn, Rendering a Stream. Pemasokan ke buffer pemutaran, sisa data, ukuran buffer yang sebenarnya, dan definisi frame PCM.
• Microsoft Learn, Exclusive-Mode Streams. Waktu pemasokan buffer dan glitch audio, penyesuaian dengan latensi, serta pemasokan berbasis event. Ini bukan anjuran untuk memakai mode eksklusif itu sendiri di semua kasus.
• Microsoft Learn, Low Latency Audio. Jalur audio Windows, buffer, perangkat, pemrosesan efek dan latensi, serta trade-off latensi rendah.
• Microsoft Learn, CPU Analysis. CPU logis, status Ready/Waiting thread, hubungan antara DPC/ISR dan eksekusi thread, serta analisis CPU di WPA.
• Microsoft Learn, Introduction to DPCs. Mekanisme untuk mempersingkat penanganan interupsi dan mengalihkan sisa pekerjaan ke DPC.
• Microsoft Learn, Results for the Streaming Media Performance Assessment. DPC/ISR yang panjang atau sering, kekurangan pasokan data, dan glitch audio. Nilai peringatan evaluasi tidak digeneralisasi menjadi standar keamanan untuk semua perangkat.
• Microsoft Support, Fix distorted or crackling audio in Windows. Pemeriksaan peningkatan audio, format, driver, dan sebagainya.
• Microsoft Learn, Windows Performance Recorder. Perekaman ETW dan analisis dengan WPA, serta penggunaan Windows Performance Toolkit.
• Microsoft Learn, Built-in Recording Profiles. More Options di WPR dan profile standar seperti Audio glitches dan CPU usage.
• Microsoft Learn, WPR How-to Topics. Memulai perekaman dan menyimpan dengan Save, konflik dengan sesi yang sudah ada, serta perhatian terhadap informasi pribadi dan event yang hilang.
• Microsoft Learn, Multimedia Class Scheduler Service. Alokasi sumber daya CPU untuk pemrosesan multimedia yang memiliki batasan waktu.
• Microsoft Learn, Scheduling Priorities. Prioritas proses dan thread, serta perhatian terkait prioritas real-time.

Artikel terkait

Artikel terbaru dengan tag yang sama untuk mendalami topik-topik yang lebih dekat.

Topik terkait

Ini adalah halaman topik yang dekat dengan tema ini. Dari artikel, Anda dapat melanjutkan ke layanan terkait dan artikel lainnya.

Layanan yang terkait dengan topik ini

Artikel ini terhubung ke halaman layanan berikut. Silakan lihat dari pintu masuk yang dekat dengan situasi Anda.

Pertanyaan yang sering diajukan

Pertanyaan yang sering muncul dalam konsultasi tentang topik artikel ini.

Mengapa audio terputus padahal penggunaan CPU hanya sekitar 10%?

Audio memiliki tenggat untuk mengisi ulang data berikutnya sebelum data yang sedang diputar habis terpakai. Walaupun penggunaan CPU secara keseluruhan rendah, jika pada saat itu pemrosesan audio tidak dapat dieksekusi atau sedang menunggu data yang diperlukan, pengisian ulang bisa tidak tepat waktu. Tidak semua kasus audio terputus disebabkan oleh hal ini, sehingga perbandingan dengan mengganti perangkat output atau aplikasi juga diperlukan.

Apakah memperbesar buffer audio akan menghilangkan audio yang terputus?

Jika pengisian ulang terlambat sementara, buffer yang besar terkadang dapat menyerapnya. Namun, waktu tunggu sampai audio yang sudah ditampung diputar juga bertambah. Ini bukan pengaturan yang dapat mengatasi kekurangan kemampuan pemrosesan yang terus-menerus maupun terputusnya koneksi perangkat. Pada aplikasi atau driver yang memungkinkan perubahan, catat nilai awalnya lalu bandingkan satu tingkat demi satu tingkat.

480 frame pada 48kHz setara dengan berapa milidetik audio?

480 ÷ 48000 detik, jadi setara dengan 10 milidetik. Satu frame PCM adalah satuan yang menghimpun sampel semua kanal pada titik waktu yang sama. Nilai ini adalah durasi audio yang diwakili oleh jumlah frame tersebut, bukan latensi total termasuk perangkat dan aplikasi.

Apakah driver dengan waktu eksekusi DPC atau ISR yang panjang adalah biang keladi audio terputus?

Driver itu bisa menjadi kandidat, tetapi tidak dapat dipastikan hanya dari peringkat waktu eksekusi. Cocokkan rentang waktu saat audio terputus dengan penantian thread audio dan eksekusi DPC/ISR pada CPU yang sama. Jangan menyimpulkan adanya cacat pada perangkat atau driver tertentu hanya dari nama modul; periksa juga hasil ketika kondisi reproduksi diubah.

Apakah menyetel pemutar ke prioritas real-time akan memperbaiki keadaan?

Hal ini tidak dianjurkan untuk semua kasus. Menaikkan prioritas thread biasa tetap tidak membuatnya dapat mendahului DPC atau ISR biasa pada CPU yang sama, dan penantian data atau lock pun tidak hilang. Pengembang menggunakan mekanisme seperti MMCSS dan desain yang tidak membawa masuk penantian, sedangkan pengguna terlebih dahulu membandingkan kondisi reproduksi dan jalur output.

Profil penulis

Halaman perkenalan penulis artikel.

Go Komura

Perwakilan KomuraSoft LLC

Berfokus pada pengembangan perangkat lunak Windows, konsultasi teknis, dan investigasi bug, dengan keunggulan pada proyek yang masih memiliki aset yang sudah ada dan investigasi gangguan yang penyebabnya sulit terlihat.