Re: asynchronous change of kAudioStreamPropertyPhysicalFormat
Re: asynchronous change of kAudioStreamPropertyPhysicalFormat
- Subject: Re: asynchronous change of kAudioStreamPropertyPhysicalFormat
- From: Derk-Jan Hartman <email@hidden>
- Date: Thu, 22 Dec 2005 00:23:24 +0100
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
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.
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.
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