Defrag Tools #153 - Media eXperience Analyzer part 5: Audio Glitch Analysis II

Sign in to queue

Description

In this episode of Defrag Tools, Chad Beeder and Jorge Novillo wrap up a series on Media eXperience Analyzer (MXA). We examine one more audio glitch scenario, and show how to use MXA to determine what caused the problem.

Media eXperience Analyzer (formerly WindowsXRay) is a tool used to visualize ETW traces, with a particular emphasis on media scenarios such as audio/video capture and playback.

For an introduction to MXA, and explanation of how to capture a trace, refer to Defrag Tools Episode #149.

Timeline:
[00:00] Introductions and overview
[01:20] Loading the trace into MXA
[01:50] Step 1: Start with the Audio Glitches dataset to see where we need to look in the trace
[02:52] Step 2: Look at the CPU Scheduler dataset to see what was going on at that time
[04:04] Filter on the audiodg.exe process to see the activity of the audio engine - notice a gap in the audio pump activity
[05:57] Look at the Call Stack when the thread started again after the delay. What was it waiting on? (Hard page fault)
[07:27] Ready Thread viewer tells you what was running when our thread was ready to run, but couldn't.
[08:28] Hard Page Faults dataset lets us see what file we were paging in during this time: the DLL for the Audio Processing Object was paged out.
[12:47] Email us at defragtools@microsoft.com

Embed

Download

The Discussion

  • User profile image
    Waldemar

    Very cool. Just writing a program where I will be able to use this.
    Thanks and keep up the good work.

  • User profile image
    androidi

    Good to see this but lets say you have some sort of glitch that occurs only 1 time a week and you are using the computer in a daily live PA or studio workflow. To help professional users there it should be made so that if the audio glitches, Windows notices this and you don't have to try google how to solve it but rather add some button to Action Center allows the user to collect the trace if it's bothering them... this trace collection should be setup to be very light weight so that everything happens in memory with regard to the collection and there's a circular buffer that throws the data away until a glitch occurs again - collect what happened between the last non-glitch audio playback  and after the audio resumed and store that in memory. ... so it just records the info relevant to every the glitch in a way that does not cause disk or network io.

     

  • User profile image
    Tom

    Jorge/Chad...at approximately 2min 25sec Jorge says that one problem may be that the new media provider is not enabled... then nothing further is mentioned. How does one check to make sure the provider is enabled?....In video 149, Jorge shows that the multimedia profile is provided by the MXA download.

  • User profile image
    Tom

    Chad...
    a little pushback regarding your answer to providing access to the "demo" driver tool (evntctrl.exe). In the past, Mark Russinovich and Aaron Margosis have not had problems releasing such tools as Notmyfault, virtmemtest, cpustress, testlimit.

    I guess I could understand MSFT not wanting the telemetry system full of false etw "glitches"; however, from what I have read, this was marked in notmyfault, etc so the telemetry could disregard those pieces of data.

    the tools are great but like all tools, they are not documented and therefore difficult to simply start using without having known test cases to learn from.

  • User profile image
    ChadBeeder

    @Tom: Unfortunately it's not too easy, we'd have to go through a fairly complicated process to release that tool, particularly since it's not just an application, it also includes a device driver.

    In theory, it should be pretty easy to make your own driver to do this, by starting with one of the existing WDK sample drivers (for example, the KMDF Toaster sample) and adding a call to stall execution for, say, 100ms every so often, while the driver is at DPC level. This should pretty effectively cause audio glitches. The trickiest part would be having some kind of control so that it's not just doing it all the time and bringing your system to its knees!

     

  • User profile image
    Tom

    theory does NOT = practice.

    since there is an insurmountable obstacle to release an executable, how about posting the non-compiled source files just like the sample you are referencing?

Add Your 2 Cents