• 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: Wed, 26 Dec 2007 10:03:01 -0800


On Dec 24, 2007, at 8:05 PM, Jaime Magiera wrote:


On Dec 23, 2007, at 10:11 PM, Robert Ackerman wrote:

i can't get it working right. i tried your suggestion with:


inConverter = [[MTConversionBuffer alloc]
initWithSourceSampleRate: [self sampleRate]
channels: 1
bufferFrames: inBufferSize
destinationSampleRate: [outputDevice nominalSampleRate]
channels: [outputDevice channelsForDirection: kMTCoreAudioDevicePlaybackDirection]
bufferFrames: [outputDevice deviceMaxVariableBufferSizeInFrames] * SR_ERROR_ALLOWANCE
minimumBufferSeconds: 1.0
];


outConverter = [[MTConversionBuffer alloc]
initWithSourceSampleRate: [inputDevice nominalSampleRate]
channels: [inputDevice channelsForDirection: kMTCoreAudioDeviceRecordDirection];
bufferFrames: outBufferSize
destinationSampleRate: [self sampleRate]
channels: 1
bufferFrames: ceil ( [outputDevice deviceMaxVariableBufferSizeInFrames] *SR_ERROR_ALLOWANCE )
minimumBufferSeconds: 1.0
];



and got a recording rate about 2 times too fast, with loud static on playback.


Hello,

Everyone is probably off enjoying festivities :) Mike suggested the initializer above. So, it seems like the right one. Could you post an example of the actual values that are getting plugged into those variables and perhaps an example of how you're using the converters? The symptoms you describe sound like the outConverter is expecting a sampling rate twice the amount of the inConvertor's output (assuming you're passing the data from one to the other).

... but these are just observations from the Peanut Gallery, I am a CoreAudio/MTCoreAudio novice.

hope that helps,

Jaime

i appreciate your reply and it is a good suggestion.
so comparing values to what i see in my working tiger version these are the issues i see:
> minimumBufferSeconds in recent version is taken as a multiplier to get a max value in numBufferFramesForSourceSampleRate which causes a totalBufferFrames of 44100 instead of 196.
so i changed minimumBufferSeconds to 0 as it was in older version of code.


>recent version of MTConversionBuffer.m, initWithCapacityFrames, uses a minimum of srcChans and dstChans which is 1; older code just used srcChans, which is 2 for the outConverter, so i put it back to srcChans.

this gave me almost same values as older version except older code has in MTConversionBuffer.m, 'initWithSourceDescription':
srcFrames = ((srcFrames * srcDecription.mBytesPerFrame) / srcChans) / sizeof(Float32);
and likewise for dstFrames.
well, i don't have a srcDescription or dstDescription in the new version at this point in the code, but i guess i could get that the same way the old version of the code did using MTConversionBuffer descriptionForDevice:


am i going about this correctly? i am fudging it all up to produce the same values as the older version of MTConversionBuffer. this isn't feeling good -- i am having doubts that it will produce good results.

perhaps i should be doing more of what the recent version of the code wants.
so i take a step back and say 'initWithSourceSampleRate:' takes a set of arguments that i pass in but get bad record: why? is there an issue of #bytes per frame or per packet? was tiger using 16 or 32 bit somethings but leopard is using 32 or 64 bit somethings?
it is hard to track down what is going wrong.
i think i will pull out the descriptions from inputDevice and the outputDevice and compare them what i see in older working code version.
i guess no one has code that uses MTConversionBuffer for simple recording and playback.


here are the values i see now:
inconverter:
srcChans(conversionChannels)=1
audioBufferFrameCount(totalBufferFrames)=196
conversionBufferListFrameCoun(effectiveDstFramest=102
outputBufferListFrameCount(dstFrames)=517
dstChans=2

outconverter:
conversionChannels=1 (srcChans=2)
audioBufferFrameCount(totalBufferFrames)=1530
conversionBufferListFrameCount(effectiveDstFrames=1436
outputBufferListFrameCount(dstFrames)=259
dstChans=1
conversionFactor=5.5125
srcRate=44100
dstRate=8000

_______________________________________________
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: 
 >old mtcoreaudio code doesn't work now (From: Robert Ackerman <email@hidden>)
 >Re: old mtcoreaudio code doesn't work now (From: Jaime Magiera <email@hidden>)
 >Re: old mtcoreaudio code doesn't work now (From: Robert Ackerman <email@hidden>)
 >Re: old mtcoreaudio code doesn't work now (From: Jaime Magiera <email@hidden>)
 >Re: old mtcoreaudio code doesn't work now (From: Robert 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: Robert Ackerman <email@hidden>)
 >Re: old mtcoreaudio code doesn't work now (From: Jaime Magiera <email@hidden>)

  • Prev by Date: Re: old mtcoreaudio code doesn't work now
  • Next by Date: Loading arrays into register
  • 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