Re: SPDIF encoded output on G5
Re: SPDIF encoded output on G5
- Subject: Re: SPDIF encoded output on G5
- From: Jeff Moore <email@hidden>
- Date: Wed, 30 Nov 2005 16:02:49 -0800
On Nov 30, 2005, at 3:38 PM, Derk-Jan Hartman wrote:
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.
You have now. In fact, you, yourself, just cited two
kAudioFormat60958AC3 ASBDs. The first one sets the big-endian flag
and the other one clears it. You have to respect this flag and
prepare your data accordingly.
In this case does the SPDIF header have to be byteswapped as well ?
Apps don't write the SPDIF header. That's written by the hardware. I
think you are referring to the packet wrapper that you add as part of
implementing kAudioFormat60958AC3. And yes, you byte swap that as
well. What I have done in my own code is to write all the data into
the output buffer and then just byte-swap the whole buffer if I have to.
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
Then you must have a very nice decoder. Mine plays the pulse train
when I mess something up.
--
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