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 01:51:45 +0100
On 22-dec-2005, at 0:54, Jeff Moore wrote:
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 did this, and now it works.
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.
well, some flags changed, and what I understand some low level
behavior did as well. I though that that might influence it.
Also, the way VLC reacts shouldn't account for such a long time
between the two "changes" HALLab sees when VLC sets the format.
I really think something else is going on at some level, but it's not
really interesting i guess.
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.
That's always the problem I guess for software developers :D You
don't have all the devices..
Perhaps I should contact MOTU directly. Do you have email-addresses
of their engineers or something which I could try? (off the list of
course)
Sending emails to support is generally a waste of time in my
experience. It was the same for M-Audio. Engineers eager to help,
Support not that much.
Hopefully in the coming year the devices, api and applications will
all "stable"-out a bit.
Thank you for your time again :D
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
_______________________________________________
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