• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
bug: NSSound vs AudioDeviceIOProcs
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug: NSSound vs AudioDeviceIOProcs


  • Subject: bug: NSSound vs AudioDeviceIOProcs
  • From: Michael Thornburgh <email@hidden>
  • Date: Sun, 25 Apr 2004 14:09:35 -0700

i just submitted this bug (radarweb #3633139), which i believe to be an NSSound bug, but thought that folks here would be interested in (especially apple HAL folks).

it appears that NSSound's AudioDeviceIOProc corrupts the (const!) inInputData AudioBufferList, rendering it unusable to any AudioDeviceIOProcs that follow NSSound's that IO cycle. this, of course, is only a problem if the default output device also has an input side, and you happen to want to record from that device. the nature of the corruption is inInputData->mBuffers[0].mData gets set to NULL, even though all the other fields of the AudioBufferList (like ...mDataByteSize) and the inInputTime timestamp remain valid.

if the default input and default output devices are the same physical (same IOAudioEngine) device, then the following code demonstrates this problem (it prints "dude, bad mData!" at every IO cycle):

---
#import <Cocoa/Cocoa.h>
#import <CoreAudio/CoreAudio.h>

#import <unistd.h>
#import <stdio.h>
#import <CoreAudio/CoreAudio.h>

OSStatus recordIOProc (
AudioDeviceID inDevice,
const AudioTimeStamp* inNow,
const AudioBufferList* inInputData,
const AudioTimeStamp* inInputTime,
AudioBufferList* outOutputData,
const AudioTimeStamp* inOutputTime,
void* inClientData
)
{
if ( inInputTime && inInputData )
{
if ( 0 == inInputData->mBuffers[0].mData )
printf ( "dude, bad mData!\n" );
}
return noErr;
}

main()
{
NSAutoreleasePool * pool = [NSAutoreleasePool new];
AudioDeviceID inDeviceID;
OSStatus theStatus;
UInt32 theSize;

theSize = sizeof(AudioDeviceID);
theStatus = AudioHardwareGetProperty ( kAudioHardwarePropertyDefaultInputDevice, &theSize, &inDeviceID );

[[NSSound soundNamed:@"Submarine"] play];

AudioDeviceAddIOProc ( inDeviceID, recordIOProc, NULL );
AudioDeviceStart ( inDeviceID, recordIOProc );


sleep(3);
[pool release];
return 0;
}
---

note that if the "[[NSSound soundNamed:@"Submarine"] play];" line is placed _after_ the AudioDeviceStart() call, then the problem doesn't happen, presumably because the HAL schedules NSSound's AudioDeviceIOProc after recordIOProc().

-mike
_______________________________________________
coreaudio-api mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/coreaudio-api
Do not post admin requests to the list. They will be ignored.


  • Prev by Date: Xcode 1.2 kills CoreAudio SDK 1.3.1
  • Next by Date: AudioConverterFillComplexBuffer for rate conversion?
  • Previous by thread: Xcode 1.2 kills CoreAudio SDK 1.3.1
  • Next by thread: AudioConverterFillComplexBuffer for rate conversion?
  • Index(es):
    • Date
    • Thread