• 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
Re: old mtcoreaudio code doesn't work now
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: old mtcoreaudio code doesn't work now


  • Subject: Re: old mtcoreaudio code doesn't work now
  • From: dudley ackerman <email@hidden>
  • Date: Mon, 7 Jan 2008 11:29:13 -0800


On Jan 6, 2008, at 4:08 PM, dudley ackerman wrote:
On Jan 6, 2008, at 12:41 PM, Michael Thornburgh wrote:
<snip>
the buffer sizes are probably also too small. they need to be big enough to hold *at least* one IOProc/IOTarget callback buffer's worth of samples, or you'll over- or under-flow the buffer during the input or output side's action. you want the buffers to be small to keep latency down, but IOProc dispatch jitter will cause over- or under- flow unless there's some slop. plus you have to be reading out samples fast enough to keep the input from overflowing, or feed samples in fast enough to keep the output from overflowing, if either end isn't real-time (like, in the record to or play back from a buffer or file or something case).


hmm. so you don't think the code that computes the buffer size is good?
ok - i cleaned that all up so only 1 converter is created on record and 1 on playback.
and i cleaned up the names, so buffers and converters for record are named 'in' and 'out' for playback.


given that you're recording to (and later playing from) a non-realtime buffer, i'd suggest making the MTConversionBuffers large-ish, like a second or so, to give plenty of time for the non-realtime consumer (record) or producer (playout) long enough to get their work done in the presence of realtime work also happening (the actual audio threads).

ok. now i am recording, but it is giving me too much data -- over 100k/ sec.

so, this is what i have for my recording converter:
Float64 sr = [self sampleRate]; // 8000
Float64 nsr = [inputDevice nominalSampleRate]; // 44100
Float64 inScale = sr/nsr; // 0.18140589569160998
unsigned sbs = [inputDevice deviceMaxVariableBufferSizeInFrames]; // 512
unsigned inBufferSize = ceil(inScale * sbs * SR_ERROR_ALLOWANCE); // 94
UInt32 dbz = [inputDevice deviceMaxVariableBufferSizeInFrames]; // 512
if (inBuffer) MTAudioBufferListDispose(inBuffer);
inBuffer = MTAudioBufferListNew(1, inBufferSize, NO);


[inConverter release];
inConverter = [[MTConversionBuffer alloc]
initWithSourceSampleRate: nsr
channels: [inputDevice channelsForDirection: kMTCoreAudioDeviceRecordDirection]
bufferFrames: inBufferSize
destinationSampleRate: sr
channels: 1
bufferFrames: ceil ( dbz * SR_ERROR_ALLOWANCE )
minimumBufferSeconds: 0
];


so, what would you suggest i change those values to?
_______________________________________________
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


References: 
 >Re: old mtcoreaudio code doesn't work now (From: dudley ackerman <email@hidden>)
 >Re: old mtcoreaudio code doesn't work now (From: Michael Thornburgh <email@hidden>)
 >Re: old mtcoreaudio code doesn't work now (From: dudley ackerman <email@hidden>)
 >Re: old mtcoreaudio code doesn't work now (From: Michael Thornburgh <email@hidden>)

  • Prev by Date: Re: threads
  • Next by Date: Re: Really puzzling ExtAudioFileRead crash...
  • Previous by thread: Re: old mtcoreaudio code doesn't work now
  • Next by thread: Re: old mtcoreaudio code doesn't work now
  • Index(es):
    • Date
    • Thread