Re: User-land driver for channel mapping
Re: User-land driver for channel mapping
- Subject: Re: User-land driver for channel mapping
- From: Dave Addey <email@hidden>
- Date: Tue, 08 Apr 2008 23:00:09 +0100
- Thread-topic: User-land driver for channel mapping
Hi Jeff,
Thanks for the replies - much appreciated.
> At the risk of stating the obvious: why are you using QuickTime for
> this in the first place? You'd have much better results and a much
> easier time of it if you'd just use the Core Audio API directly.
I completely agree! There's only one reason we're still using QuickTime for
playback: protected AAC files. QuickTime is the only way we can get
playback of these files, and it's a critical feature for our users. Believe
me, life would be so much easier if we didn't have to support these files.
I added some more detail around our reasons in my reply to Bill's earlier
email. It's convoluted at best, I'll admit.
> Why would you buffer anything at all? Why wouldn't you just use the
> buffers and time stamps provided by the underlying device?
Ah - that's so obvious I didn't even think of it.
> As near as I can tell, what you want a fake device that says that it
> is a stereo device but under the hood sends it's data to two stereo
> pairs on the same underlying real device.
Absolutely spot on.
> So beyond the need to expose stereo formats to the outside world, the
> rest of your device's properties are going to be basically directly
> the result from the underlying device. Indeed, even your IO pathway is
> going to be driven directly by the underlying device. This will
> include the time stamps. For example, your device's implementation of
> GetCurrentTime() is just going to turn around and call
> GetCurrentTime() on the underlying device.
That makes life so much easier - thanks!
I guess the only other thing I'll need to do is to copy the stereo input
into multiple output buffers. How / where would I best do this in the
"return results from the underlying device" model?
> If you follow my advice on this, you won't have to worry about what
> the rate scalar is. You'll just be returning what you got back from
> the underlying device.
Excellent.
>> There is currently no way for QuickTime to play one stereo movie to
>> two different pairs of outputs on a multi-channel audio device
>> whilst applying separate volume levels to the different channels.
>> (Radar feature request #4145662.)
>
> The reason I think that this statement is false is that I can achieve
> this effect entirely within QTPlayer. I don't have to write a single
> line of code. Here's what I did:
>
> [...]
>
> I'm pretty sure that you can accomplish all these steps
> programmatically as well.
You're absolutely right, and in retrospect my claim was missing some
important information. Apologies.
The approach you describe is, in fact, how we used to manage playback to
multi-channel devices. We used the track volumes to set different volumes
for the two different output pairs.
The bit I forgot to mention is that we now make use of QT's pitch-fixing
option - kQTAudioPropertyID_RateChangesPreservePitch - introduced in QT 7.2.
I think this uses an AUTimePitch behind the scenes. Unfortunately, the
higher-quality render settings (kRenderQuality_Medium and higher), which we
need, can only be used when the movie's output mix is mono or stereo.
Having two stereo tracks in one movie results in a four-channel mix, and
QuickTime silently opts out of the higher render qualities.
Using two timebased-slaved movies, rather than a single two-track movie,
provides a workaround and enables us to use the higher render qualities, as
both movies then have a stereo mix each. But this then runs into bug
#5615865 on Leopard.
So, after much experimentation, our options seemed to be:
Drop support for protected AAC files, and do everything ourselves in
CoreAudio. However, this would mean losing a very popular feature.
Drop support for pitch lock, and return to the two-track approach you
described. But pitch lock is also a very popular feature.
Without bug #5615865, we could continue to use slaved movies on Leopard.
Our only alternative at present is to not officially support Leopard.
So either we drop protected AAC support, or pitch lock, or Leopard, none of
which particularly appeal. This led to the "virtual device" approach, which
whilst definitely pathological, gives us a route to explore.
Apologies that it's all so convoluted - and thanks again for the advice!
Dave.
_______________________________________________
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