Re: SPDIF encoded output on G5
Re: SPDIF encoded output on G5
- Subject: Re: SPDIF encoded output on G5
- From: Derk-Jan Hartman <email@hidden>
- Date: Thu, 1 Dec 2005 00:38:24 +0100
On 30-nov-2005, at 22:58, Jeff Moore wrote:
On Nov 30, 2005, at 12:35 PM, Derk-Jan Hartman wrote:
There i am again.
I fixed an issue VLC had with hogging the device, but i'm still
not getting any digital audio out of the thing.
I tried setting Mixable to no, but that apparently is being done
automatically, and i'm not allowed to set it (HALlab says that as
well).
The one real difference I could see was the following in the ASBDs
G5
[48000][cac3][94][6144][1536][0][2][16]
Sonica
[48000][cac3][76][6144][1536][0][2][16]
So that is a diff in the formatflags, specifically the IsBigEndian
flag and the isPackedHigh flag.
As far as I can tell however that shouldn't matter correct?
Incorrect. You need to byte-swap as dictated by the flags.
Natively, an AC-3 bitstream has the same endian properties as MPEG
data streams. That is, it's big endian. When you take the native
stream and hack it up to be put on a SPDIF cable (which is what
kAudioFormat60958AC3 signifies), you are basically making the AC-3
packet behave like 16 bit, stereo, signed integer data (which is
why the standard format flags apply to the ASBD).
So, if the ASBD sets kAudioFormatFlagIsBigEndian, you don't need to
byte-swap. If kAudioFormatFlagIsBigEndian is clear, you have to
byte-swap the data as if it was 16 bit samples.
mm, ok.
This is extraordinary in my eyes. I have not seen a device so far
that has big endian set for SPDIF output in HAL or Alsa.
In this case does the SPDIF header have to be byteswapped as well ?
In IOProc I tried switching between different timestamps etc etc.
but it didn't seem to matter. The audio is being put in the
buffers, it simply seems like my receiver can't make heads or
tails from it anymore, yet DVD Player works just fine.
If you have the endian-ness of the data wrong, I imagine the
decoder doesn't know what to do with the data. It'll just look like
regular 16 bit, stereo, signed integer data to it (which sounds
like a pulse train).
Actually it's dead silent :D
In HALLab I tried comparing the settings of DVD Player with the
settings when VLC is running, and there is simply no difference.
I was looking at the ioproc and did see
[00000294] coreaudio audio output debug: AudioDevice: 257,
OutputBufferlist.#Buffers: 1,
[00000294] coreaudio audio output debug:
OutputBufferlist.#channels: 2: OutputBufferlist.datasize: 6144
The #channels, could that be an issue perhaps? Does it have any
relevance in the context of SPDIF ?
Speaking of channels. another idea I was having is that for
digital modes, I set all the options on the "masterchannel" of the
device/stream. However I don't think that could be an issue.
kAudioFormat60958AC3 specifically defines itself to act like 16
bit, stereo, signed integer data. So you will always see the number
of channels be 2.
I see.
The G5 is the only digital output that VLCs Digital audio output
doesn't seem to work with, and I can't seem to figure out why. Is
there anyone who has been able to use this feature successfully in
his application?
Aside from the DVD Player? It is a plain ordinary HAL client. All
the advice I've given you is drawn directly from my experience with
helping with the DVD Player.
At any rate, it sounds like you aren't obeying the semantics of the
format with respect to endian-ness.
Probably.
_______________________________________________
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