Re: asynchronous change of kAudioStreamPropertyPhysicalFormat
Re: asynchronous change of kAudioStreamPropertyPhysicalFormat
- Subject: Re: asynchronous change of kAudioStreamPropertyPhysicalFormat
- From: Jeff Moore <email@hidden>
- Date: Wed, 21 Dec 2005 15:54:08 -0800
On Dec 21, 2005, at 3:23 PM, Derk-Jan Hartman wrote:
On 22-dec-2005, at 0:07, Jeff Moore wrote:
It us possible that the device took two steps to change the
format. I don't know if such is the case (appears to be from what
you are describing), but a device is totally within it's rights to
do things that way. I would consider it an application issue if
the app is not paying attention to these sorts of things.
In fact, a proper HAL client should _always_ assume that any
device state can change at any time, particularly that state which
pertains to IO and be set up accordingly. I would organize the
code so that the hardware state and things that relied on it were
more event driven, like UI is so that operations that are
inherently asynchronous can be handled that way. An app organized
that way can handle situations like this in a much more robust way.
The problem is that VLC doesn't like to change format on the fly.
It needs to recreate it's audio output flow in that case. Rather a
brute step to take, which requires a re-negotiation of all the
resamplers, filters and converters and a re-initialization of the
output module. VLC was not designed with such a flexible OS API in
mind I fear :D
Oh dear!
I'll have to find a way around it I guess, with multiple locks and
timeouts.
I also don't understand why DVD player can change the whole format
in one step. Perhaps because it is using the 10.4 API or something...
Unfortunately I don't have that luxury either.
Our DVD Player uses the same API calls you do. There are no new APIs
in this area in Tiger. The difference is likely due to the DVD Player
being set up better than VLC is to handle format changes in a more
dynamic way.
I have one more question, according to a user the Motu 828 mkII
didn't like that i'm trying to set Hog mode. Should I allow for
such a fluke? or should I fail in that case (critical?)? playback
works with DVD player according to the user.
Hog mode is not something a particular device can override or have
any input into. Hog mode is entirely managed by the HAL. In fact, the
only thing the device knows about hog mode is how many clients are
doing IO at any given time. When some process owns hog mode, it just
always happens to be one. The funny thing is that the IOAudio family
will apply a number of optimizations to the signal flow when there is
only one client, regardless of whether or not that client owns hog mode.
At any rate, the MotU FireWire boxes don't support non-mixable
flavors of LPCM nor do they support AC-3, so I imagine that the
problem you are having is not with hog mode per se, but rather with
the non-mixable/AC-3 stuff. And yes, you should definitely be
prepared to deal with this case.
That said, if it is something to do with hog mode, I'd have to know a
bit more about the circumstances to provide a better answer since the
particular device involved shouldn't matter.
DJ
On Dec 21, 2005, at 2:46 PM, Derk-Jan Hartman wrote:
On 21-dec-2005, at 21:38, Jeff Moore wrote:
On Dec 21, 2005, at 11:35 AM, Derk-Jan Hartman wrote:
For VLC I change the kAudioStreamPropertyPhysicalFormat so i
can do cac3 output:
I retrieve the original format, so that I can back it up
Set the new format, enter a conditional lock.
The Streamlistener listens for the
kAudioStreamPropertyPhysicalFormat, and unlocks the condition.
Then the main method continues, and will query the "fresh/new"
kAudioStreamPropertyPhysicalFormat.
Usually it works, however sometimes the following occurs...
[00000319] auhal audio output debug: original stream format:
[44100][lpcm][30][4][1][4][2][16]
[00000319] auhal audio output debug: setting stream format:
[48000][cac3][94][6144][1536][0][2][16]
[00000319] auhal audio output debug: actual format in use:
[44100][lpcm][94][4][1][4][2][16]
So naturally this has me confused... I receive the "callback"
that the property changed, but apparently it's not changed yet
sometimes (a timeout did not occur, i checked). However, later
on, when the playback actually commenced (the IOProc is
running), the format HAS changed. What is going on here. anyone
have an idea?
If you look closely, the format _did_ change. At least the flags
field did. Specifically, kAudioFormatFlagIsNonMixable got set.
Correct
It would appear that the hardware accepted the non-mixable part
of what you set, but rejected the AC-3 part. It's tough to say
why, but you might want to compare the AC-3 ASBD you send to the
device with the AC-3 ASBD it is advertising that it supports. On
the surface, it doesn't seem like yours is incorrect but it may
not match up entirely with what the device is expecting.
Ha, but the fun part is that it IS in AC3 mode. and the IOProc is
at 48000 Hz instead of 44100 Hz. Because the 44100 I get on the
actual format causes VLC to resample down to 44100, and the
IOProc is completely confused because of that. I also checked
with HALLab, and during playback, the Device is in the requested
setup, even though the by me queried actual format directly after
setting still shows lpcm.
And I picked the ABSD from the
kAudioFormatPropertyPhysicalFormats that I query. I don't
construct it myself.
It almost seems like the setup is changed in "2" steps instead of
atomically or something. I again verified this against HALLab,
and I can sort of confirm this when i keep observing the Device
information, while my file opens. The Stream goes from lpcm ->
"blank dropdown box" -> AC3 for SPDIF, and the samplerate seems
to change from 44100 to 48000 even AFTER the stream format is
changed. (visual observation, not 100% sure).
DVD player doesn't have the same issue. it seems to change the
format in one step. I'm clueless as to what is the cause.
It seems to me like it might actually be a driverbug or something?
You can find more of the code here:
https://trac.videolan.org/vlc/file/trunk/modules/audio_output/
auhal.c
See OpenSPDIF() and RenderCallbackSPDIF()
This is on a Powermac G5 compiling for SDK 10.3.9
DJ
--
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:
40student.utwente.nl
This email sent to email@hidden
_______________________________________________
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