| Couldn't find your references under bluetooth search of core audio list... maybe they are pushed off by now....
I found a reference that the Apple bluetooth audio driver is reporting:
----- Sounds like the BlueTooth driver is not reporting the proper value. Even though there isn't a specific bluetooth item in the enumeration, I would have expected a bluetooth device to report kIOAudioDeviceTransportTypeWireless rather than kIOAudioDeviceTransportTypeOther. ----
By inference it looks like this miss-reporting is failing to initiate the device correctly which may be the cause of the symptom that I experienced where altering other audio settings causes the input to be buffered correctly the next time out.
This symptom was previously reported (see below:)
----- have noticed that my bluetooth headset will not start its IO cycles the first time after being turned on. i haven't bugreported it yet because i haven't tried to narrow the problem down enough to be 100% confident it's not my fault, but i'm *pretty* sure it's not my fault. :)
what i find is that after turning it on, the first program to try to start IO on it will fail, and then after that (as long as i don't turn it off again), i can start and stop audio. i just tried it out with System Preferences -> Sound -> Input and got the same behavior. i've only tried this on my G5 -- i'll try this out later today on another computer, and bugreport if it happens there too. or if others can corroborate this. unless someone knows it's already been bugreported. :)
-mike -----
So the question now, I guess, is: do I write a new driver which corrects this issue or count on Apple fixing the problem?
On Jun 20, 2006, at 8:08 PM, Chilton Webb wrote: Hi,
On Tuesday, June 20, 2006, at 09:26PM, colela < email@hidden> wrote: I have a bluetooth microphone that I want to use with garageband....
The mic pairs OK and even looks like it is recording OK in garageband (nice waveform shows up as I record, etc.)
The problem you're having is that bluetooth mics only work at 8 bit.
So what happens is that the data comes in, and either fills a buffer before continuing (in which case it sounds normal), or it sounds like the chipmunks if it's not buffering first.
I'm not sure how far back the coreaudio archives go, but I encountered this while working on a clients' hardware, and I had to find a way around this in the software interface to the device. I believe I set up a system where it was basically copying the sound to fill the void.
-Chilton
|