• 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: John Draper <email@hidden>
  • Date: Sat, 12 Jan 2008 13:50:27 -0800

Michael Thornburgh wrote:
secondly, 8000 samples per second, with one channel, 4 bytes per sample (Float32), is 32,000 bytes/sec or 256,000 bits/second. how much data are you actually getting out?
Well, we really want 16 bit samples at 8k/Sec because the GSM Codec requires it to be in that format... Isn't it just a matter of setting up the flags correctly?

In my use of your earlier version, we've been able to just use the MTConversionBuffer structures, and somehow the output from the Mic was the proper format. However, Robert experienced some problems, then learned you deprecated the function, and the new function doesn't appear to give us what we want to satisfy the GSM Codec.

I think all we need to do, is setup the "flags" properly as suggested by some of the other list members, but we have failed in trying to locate the proper docs that show us how to setup these flags. We scanned the Code Audio Header files, but didn't learn much, and since there is lack of an example, we are purplexed, trying to find these hidden flags.

finally, although i have no idea what you're using inBuffer for, it's almost certainly too small to be of much use, being only 1 channel wide and 94 frames long.
Well - here is where we are so confused... our application is a very simple Audio Recorder of only Voice Quality. Once we have a buffer of 16 bit signed values thats filled to 1280 bytes (640 samples), we pass that to a GSM Codec, and out comes 130 bytes of compressed audio we just put into a buffer.

On the playback side, we uncompress the 130 byte GSM Frame (Actually two of them - because they have odd number of bytes), back into 16 bit audio samples for 8k/sec sample rate for playback and pass it to MTCoreAudio for playback.

Using your old framework running Tiger,  we had no problem.

Last year at WWDC, I was tasked to test the application on Leopard and X-Code 3. We found just one issue that Nick Moss helped us fix, because the data was not locked down under certain specific conditions, so we created and subclassed one of your objects and called in "SmartConditionLock". Way back them, I sent you Email with the changes for your inspection. I never did get any response back.

Now, when we FINALLY got our Intel Powerbook Pro's we discovered our application no longer works, and we got the impression it was Apple's doing. After a while, you responded to Bob's posting.

Bob has been one of my best programmers. Due to a hand and nerve damage, I'm not much of a programmer these days... Imagine loosing your abiity to type code... I CAN type, but not for very long... and after replying to my Email, I'm spent for at least 3 - 4 hours.

because of this problem, I was unable to complete my VIOP application I worked on back in 2005 and 2006, and got cut from the project only 95% before completion.

Anyway, I'm sure Robert can use some of your help, and I think He's working on an idea to do the conversions himself. But we are almost at the end of our investors patience, and either might wind up ditching MTCoreAudio alltogether, but we know this is going to severely complicate our development if we have to work without it. I'm letting Robert decide on when he's had enough.... So far, he's going to try just a few more things.

In the meantime, my friend who wants to inherit my G4 is going to have to wait, because it's the only machine I can use for narrating my book, then taking dictation using our Audio Voice application we call "Edicta".

The program has been a godsend for me... as my book project has advanced so far now.

A month go, I met Woz, showed him the application, and he loved it. I WANTED to send him a signed copy of the program when I get up to MacWorld next week, but (sigh) I cannot do that now. We also use it to take minutes for our meetings.

I've known the Woz a long time before he started Apple. We've been very good friends ever since...

Anyway, I hope the technical description I sent with this mail can give you a better perspective on what we want to do, and others on the list familiar with MTCoreAudio can give us some needed tips.

Regards
John

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

  • Prev by Date: Re: New to converter.
  • Next by Date: Re: old mtcoreaudio code doesn't work now
  • Previous by thread: Re: Virtual keyboard in an AUMonotimbralInstrumentBase: how to?
  • Next by thread: Deprecated function forward compatability
  • Index(es):
    • Date
    • Thread