Re: Datasources and digital audio output
Re: Datasources and digital audio output
- Subject: Re: Datasources and digital audio output
- From: Jeff Moore <email@hidden>
- Date: Wed, 16 Nov 2005 11:51:53 -0800
On Nov 16, 2005, at 11:25 AM, Derk-Jan Hartman wrote:
When you enable AC-3 output, you also have to hog the device so
that no other app can use it (if they did, they would corrupt the
output and defeat the decoder). Consequently, the decision to
fully support encoded output, by definition, implies that it is
done on a per-application basis and makes no sense on a system-
wide basis. If you support it, you have to have UI that allows
your user to tell your app to use or not use it so you can do the
right thing as far as being a proper HAL client in this area goes.
Clearly, i'm just saying that i would personally much rather like
to set the "output encoded audio if application and compter etc.
supports this" system wide, then that I have to do it for each and
every OSX application that has this capability by hand. In your
above comment you are looking at the application developer side of
this, while i'm saying that if a user want's to do encoded output
of his multichannel audio, he most likely wants this to happen in
all applications that support that, not only the applications that
he has this option marked in. However, i can also see how the "non-
mixable" character of encoded audio output might complicate this in
the context of multiple applications.
Still. ATM only very few applications might support digital encoded
output, but i see no reason why in the future not more applications
might make use of this capability. I'm especially thinking of the
MythTV, PVR, TiVO like crowd. I would not be surprised if they
shared my opinion of the encoded audio "setting".
You are totally missing my point. What you are asking for is, by
definition, impossible. It doesn't matter how many apps support AC-3
output. Even if every app ever written supported AC-3 output, you
couldn't relax the requirement that only one app use the hardware to
do it at a time.
The reason why is that you can't mix streams of AC-3 data (or any
other kind of encoded data for that matter) together. Further, you
can't mix and match on the same device apps that want to output AC-3
and apps that want to output linear PCM. Thus, it is impossible to
enable AC-3 output for the entire system and expect anything good to
happen.
Speaking of, when dealing with hog mode and encoded output, the
polite thing for an application to do is to save the device's
state prior to taking hog mode and changing the format and
restoring the state when you are done.
Yes, i know this. This is actually one of the problems with the old
VLC coreaudio module, it didn't release hog mode. (Because we
didn't know how at that time).
BTW should i first disable mixing and then set hog, or vice versa?
When you are doing anything that involves hog mode, you should always
take hog mode as the first thing you do and release it as the last
thing you do. You can think of it like a mutex.
Another thing that a polite app should do is only switch the format
to AC-3 when playback is actually engaged. When playback is stopped,
the polite app should switch the format back to what it was initially
and release hog mode.
--
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