Re: Problems aith M-Audio Audioohile Firewire
Re: Problems aith M-Audio Audioohile Firewire
- Subject: Re: Problems aith M-Audio Audioohile Firewire
- From: Jeff Moore <email@hidden>
- Date: Tue, 23 Feb 2010 14:30:38 -0800
Be sure to check the mFormatFlags field of the ASBD. Non-mixable formats will have kAudioFormatFlagIsNonMixable set. You probably don't want to pick one of those if you want to play nice with others.
On Feb 23, 2010, at 2:25 PM, Paul Sanders wrote:
> Whoops! I meant AudioStreamSetProperty ( ... kAudioStreamPropertyPhysicalFormat ...), sorry about that.
>
> We don't (knowingly) hog the device. What would constitute a non-mixable format? The information we logged to the console (and collected from the customer's machine) looks like this:
>
> Setup audio device 284: requested 44100 kHz, 2 channels, input=0
> 1 streams reported
> Found 7 audio stream descriptions
> #0: Samplerate=96000, channels=6, bits_per_channel=24
> #1: Samplerate=88200, channels=6, bits_per_channel=24
> #2: Samplerate=48000, channels=6, bits_per_channel=24
> #3: Samplerate=44100, channels=6, bits_per_channel=24
> #4: Samplerate=96000, channels=2, bits_per_channel=16
> #5: Samplerate=48000, channels=2, bits_per_channel=16
> #6: Samplerate=44100, channels=2, bits_per_channel=16
> Chose #6 (44100 kHz / 2 channels / 16 bits per channel
>
> Maybe if we chose one of the 24 bits per channel options, that would be mixable. There's no good reason not to, actually, the way the code is structured.
>
> Thanks - Paul Sanders.
>
> ----- Original Message -----
> From: Jeff Moore
> To: CoreAudio API
> Sent: Tuesday, February 23, 2010 10:15 PM
> Subject: Re: Problems aith M-Audio Audioohile Firewire
>
> On Feb 23, 2010, at 1:15 PM, Paul Sanders wrote:
>
> Thanks Jeff. As you say, there's not a lot to go on. I may just let it ride, in fact. The customer affected can route through Sound Flower so that will provide a workaround for him and anyone else affected. We haven't heard of any other audio problems so I'm hoping that it's just this one, mutant device.
>
> Just for info, the strange behaviour reported is:
>
> 1. Calling (I think) AudioStreamSetProperty (... AudioStreamSetPropertyAudioStreamSetProperty ...) seems to upset it. Up to that point, MTCoreAudio plays correctly through the device. After that, nothing plays (i.e. there is no audio output).
>
> I think you have a copy/paste bug here =)
>
>
> 2. When the device is (again, I think) started (by us or by MTCoreAudio) , iTunes stops playing through it (and reverts to the internal speakers). When the device is stopped, iTunes resumes playing through the Audiophile.
>
> iTunes will do this when the default device changes. The implication here is that whatever you/MTCoreAudio are doing is causing the circumstances on the device to change enough that the device can no longer be the default device. This could be due to selecting a non-mixable format or hogging the device.
>
>
> But don't read too much into this. There's some guesswork going on here and I'm only writing it up in case any else recognises the symptoms and has also been scratching their head.
>
> Hopefully, this will help a little. Let us know if you get any new info on it.
>
> Good luck!
>
>
> Ciao!
>
> Paul Sanders
>
> ----- Original Message -----
> From: "Jeff Moore" <email@hidden>
> To: "CoreAudio API" <email@hidden>
> Sent: Tuesday, February 23, 2010 8:21 PM
> Subject: Re: Problems aith M-Audio Audioohile Firewire
>
>
> On Feb 23, 2010, at 12:09 PM, Paul Sanders wrote:
>
> > Can someone please tell me if there is any functional difference between the AudioObject API's and the older, now deprecated API's like AudioDeviceGetProperty?
>
> The AudioDevice property methods are implemented under the hood in terms of the AudioObject property methods. Mostly, the differences between the two styles of APIs are that the AudioObject APIs allow for more possibilities for addressing and add the qualifier argument.
>
> > We have some strange behaviour in the field with the M-Audio Audiophile firewire device and I'm wondering if the fact that we're still using the older API's might be responsible.
>
> I'm not saying that it can't happen, but I've never heard of a problem that could be traced to a difference in API usage.
>
>
> > I don't have a device here to test with, unfortunately, but MTCoreAudio's AudioMonitor app displays exactly the same problems as ours, so I don't think it's a bug in my own code. The machine in question is a PowerMac G5 running (I believe) Leopard, if that makes any difference.
>
> It's hard to diagnose a problem with what you've provided so far.
>
>
>
> --
>
> Jeff Moore
> Core Audio
> Apple
>
>
>
>
>
>
>
>
> _______________________________________________
> 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
--
Jeff Moore
Core Audio
Apple
_______________________________________________
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