On Fri, Jul 4, 2008 at 12:04 PM, Mikael Hakman <email@hidden> wrote:
[...]

Is making a copy of the inInputBuffer going to copy the AudioBuffer
array called inInputBuffer->mBuffers[0] or is it going to copy an
address?
Should I memcpy mBuffers[0] with:

[...]

sizeof(AudioBuffer)) ?

[...] [...]

[...]

Is making a copy of the inInputBuffer going to copy the AudioBuffer
array called inInputBuffer->mBuffers[0] or is it going to copy an
address?
Should I memcpy mBuffers[0] with:

[...]

sizeof(AudioBuffer)) ?

[...]

I was trying to use memcpy initially but for some reason I couldn't [...]

[...]

If I understand your code correctly then in your AudioInputProc, the 
statement: 

 (*savedAudioBufferList) = (*inInputData);  
copies contents of inInputData structure to savedAudioBufferList structure, 
both of which are of AudioBufferList type. [...]

Way back in May of 2005 I first asked about using  
AudioFormatGetProperty to populate an AudioStreamBasicDescription  
based on the kAudioFormatQUALCOMM format. 

 http://lists.apple.com/archives/coreaudio-api/2005/May/msg00168.html  
With some help from the list I was able to get by. [...]

I'd like to know when recording whether the microphone is tucked  
inside the speaker, as it is on a MacBook Pro -- at least the current  
models. Is there some way to identify that situation through Core  
Audio directly? If not, anyone happen to know how to get your hands on   [...]

We are not allowed to talk about the iPhone at all at this time as  
part of the license of the SDK. Once the SDK is final I assume you  
will be able to talk about it. 

 On Jul 3, 2008, at 5:24 AM, SridharRao M wrote:

[...]

Alex Kac - President and Founder 
Web Information Solutions, Inc. [...]

Hi -

We're trying to add automatic creation of an Aggregate Device to an
open-source audio software called SuperCollider. The audio engine has
two ways of running: either as a separate process, or launched within
the main application process.

Now, we have a patch for the Aggregate Device issue, and it works fine
in the first case (audio engine is separate). But in the second case
(audio engine "internal" to application) there seems to be a problem
on Intel Macs, where the IOProc callback for the audio device is never
called. It's the same code being called in each case, so maybe
something subtle is going on.

If using a "real" device, or a user-created aggregate, there is no
problem starting the audio callback.

I've seen in the archives of this list discussion of the occasional
bug in the programmatic interaction with Aggregate Device creation
etc. If you can suggest whether this is a bug or our own fault that
would be extremely helpful!

The patch to add Aggregate Device creation is here:
http://www.listarc.bham.ac.uk/lists/sc-dev/msg02579.html
which is a patch for the main source here:
http://supercollider.svn.sourceforge.net/viewvc/supercollider/trunk/

Thanks in advance for any suggestions -
DanThis email sent to email@hidden










 Prev by Date:
Re: Loading Debugger After playing audio file

 Previous by thread:
Re: Loading Debugger After playing audio file

 Index(es):

 Date 
 Thread 












    Home 
    Archives 
    FAQ 
    Terms/Conditions 
    Contact 
    RSS 
    Lists 
    About 






 Visit the Apple Store online or at retail locations. 
1-800-MY-APPLE 
 Contact Apple | Terms of Use | Privacy Policy 
 Copyright © 2007 Apple Inc. All rights reserved. 

On Thu, Jul 3, 2008 at 2:10 PM, SridharRao M <email@hidden> wrote: > quoted text
 The below is the debugger message   Loading program into debugger… 

 GNU gdb 6.3.50-20050815 (Apple version gdb-960) (Sun May 18 18:38:33 UTC 2008) 
 Copyright 2004 Free Software Foundation, Inc. [...]

Hi, 
   I am developing application for playing audio on iPhone.I am using AudioFileServices & AudioQueueServices to play the audio. 
 After Playing one audio file it's loading GDB .I am properly using audioqueuedispose  & audiofileclose after playing completed. [...]

I see this allot (especially in 10.5.3 and 10.5.4).  We can make this  
happen quickly by making a call to MacGetCurrentProcess (see  
Process.h), early in the boot phase.  Our software codec makes this  
call to figure out what process is trying to use it. [...]