Re: choppy audio recording
Re: choppy audio recording
- Subject: Re: choppy audio recording
- From: Jeff Moore <email@hidden>
- Date: Wed, 25 Nov 2009 15:24:24 -0800
On Nov 25, 2009, at 2:19 PM, Simmons, Aaron wrote:
> I set up an automated test of our program that records small sounds from the mic over and over again until I notice the problem occurring. It takes around 115 recordings before the problem starts to be noticeable. I've put a new file called ChoppyProgression.zip on my website (http://sites.google.com/site/paleozogt/home/choppy-audio). It contains a sampling of the recorded audio and shows how the problem slowly builds from barely noticeable to almost unintelligibly distorted.
FWIW, the distortions look to me like the gain has been cranked way up on small segments of the signal. I see nothing but square waves at max amplitude. Since the data is also being repeated, it's almost as if somebody is doing some kind of overlap-add on the data.
> Btw, the software *is* checking for kAudioDeviceProcessorOverload. However, it is never called (!).
The fact that you aren't seeing any overloads implies that the problem is not detectable through timing and that the glitches are already in the signal when it reaches the Mac. This reinforces the notion that this is a hardware issue.
> I also ran HalLab during this test. It printed things like:
> 752194.466099: 0x10F: 'volm' on channel 0
> 752194.522454: 0x10F: 'vold' on channel 0
> 850642.932921: 0x110: 'isub' on channel 0
> To be honest, I'm not sure what I'm looking for in HalLab. Though these notifications seem to happen all the time, for any headset (even non-problematic ones).
You probably want to take a look at this list's archives to find one of my posts that describes how to use the IO cycle telemetry window in HALLab.
In the mean time, here's a quick tutorial:
0) Run this command at a command line: "sudo touch /var/db/.com.apple.audio.telemetryenabled". If you forget to do this, HALLab will remind you when you first open the IO cycle telemetry window.
1) Launch HALLab.
2) Open a new IO cycle telemetry window. This is done with the menu item in the "New" menu in the "File" menu.
3) Launch the app you want to examine and locate it's pid. I use the ps command line tool for this: "ps auxc | grep <app name>".
4) Type the target app's pid into the "Process ID" field in the Telemetry window. Be sure to hit return after doing this. If you've done everything right so far, the target app's name will be displayed.
5) Using the "Device" pop-up menu, pick the device the target app is going to be using.
6) Turn telemetry capturing on by picking a rate from the "Capture Rate" pop-up. I typically pick 1 or 2 seconds as the capture rate.
7) Go to the target app and reproduce your problem.
If you've done everything right, after step 7 the telemetry window will start filling up with information about each IO cycle in the HAL. Problematic cycles will be highlighted in red.
That said, since you say your code isn't seeing any overloads, it is unlikely that the telemetry data will show any problems.
> I'm somewhat stumped here. Is there no way to programmatically determine that this distortion is happening?
The evidence seems to be pointing to your problem already being in the signal by the time it reaches the machine. Further, this problem doesn't seem to be reflected in the timing information the device provides the HAL. Since the HAL doesn't examine or touch the content of the signal, there's no way for it to flag a "bad" signal (even if it know what a "bad" signal was).
>
>
> Thanks,
> aaron
>
>
> -----Original Message-----
> From: Simmons, Aaron
> Sent: Wednesday, November 25, 2009 12:41
> To: 'email@hidden'
> Subject: RE: choppy audio recording
>
> Thanks for your response. I've posted a WAV version of the distorted audio in the same place (http://sites.google.com/site/paleozogt/home/choppy-audio).
>
> I agree that it's probably a hardware issue. If I use a different headset it won't happen. It's a C-Media USB headset, btw. There's been lots of reports of this in the field, and I finally got ahold of one of the 'bad' headsets. Interestingly it doesn't happen with *all* C-Media headsets.
>
> Incidentally, our app doesn't exhibit this behavior on Windows using the same 'bad' headset. But the API and drivers are so different, I'm not sure if this is a meaningful comparison. At any rate, somehow the problem is being dodged on Windows.
>
> I have tried to get it to happen with other apps (ie, Audacity) but haven't been able to get it to happen. It's not an on-demand thing, though, so it's unclear if it's not happening or if I'm just not patient enough.
>
> I will take a look at HALLab and whether we're using kAudioDeviceProcessorOverload. Thanks!
>
>
> aaron
>
> -----Original Message-----
> From: coreaudio-api-bounces+asimmons=email@hidden [mailto:coreaudio-api-bounces+asimmons=email@hidden] On Behalf Of Jeff Moore
> Sent: Wednesday, November 25, 2009 12:31
> To: CoreAudio API
> Subject: Re: choppy audio recording
>
> I listened at the recording. You can clearly hear that the recording is not just glitching, it is actually repeating itself in small chunks. It also seemed that the glitches were not the same duration or spaced evenly. But it's hard to tell with an MP3 encoded version. The MP3 encoding also really prevents me from analyzing the content of the glitch.
>
> At any rate, the sonic evidence would seem to point toward the hardware device as the source of the problem by virtue of the uneven timing of the glitches. But here are some things to look at:
>
> - Test your app with other hardware. While it seems like this is a hardware issue on the surface, it could be somewhere else in the food chain. Testing with other hardware would be a good way to confirm or deny this.
>
> - Test your hardware with other apps.
>
> - Make sure your app is listening to kAudioDeviceProcessorOverload for when the HAL says that things have gone off the rails.
>
> - Use the IO cycle telemetry window in HALLab (found in /Developer/Applications/Audio) to analyze what your app's IO cycle is up to. This is a good way to look at overloads and other problems and see what caused them. I've posted usage notes about this on this list previously.
>
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Coreaudio-api mailing list (email@hidden)
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
--
Jeff Moore
Core Audio
Apple
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden