> -----Original Message-----
> From: xine-devel-admin@...
> [mailto:xine-devel-admin@... Behalf Of Guenter
> Sent: 10 June 2001 03:32
> To: James Courtier-Dutton
> Cc: xine-devel@...
> Subject: Re: [xine-devel] AC3 Direct out for the SB Live in Xine.
> Hi James,
> On Sun, 10 Jun 2001, James Courtier-Dutton wrote:
> > Here is a version of the audio_oss_out.c for xine_lib which
> works for AC3
> > direct out on my SB Live Player 1024.
> hey, wow - finally! :)
> and this seems to be xine 0.5 code, very nice!
> I neither have a sb live nor a hardware ac3 decoder, but I'd like to
> comment on your code:
> the code looks very nice and as far as I can see, it doesn't break any
> existing features (will test it tomorrow), just the way I like it :-)
> > I have had to disable all the delay and frame drop audio code.
> I see you disabled package dropping, but inserting 0-samples is still in
> the code?!
The ao_fill_gap is disabled, (see the little if statement).
The 0-samples after each AC3 packet write (pad to 6144 bytes) seems to be a
requirement when used with the SB Live.
It inserts the correct amount of idle space between AC3 packets.
Remember that AC3 is a frame in a stream and the frames need to be rate
If you use any more or any less than 6144, you get audio artefacts.
This might just be so that it fits in with the current buffer size free
delay algorithm. I think the AC3 standard requires 0-samples in between real
The issue is an AC3 packet only takes 776 bytes (768 without header).
These 776 bytes get clocked out of the sound buffer in 0.008 seconds, but
produce 0.032 seconds of sound.
The buffer has to be filled with 0-samples in the gap between AC3 frames.
If a gap is not inserted, the external (mine anyway) AC3 decoder looses AC3
frames and new ones override them.
As AC3 is compresses audio, it actually allows for 24 audio channels (4 AC3
frames) in the same space 2 PCM channels would take up.
As we only use 6 of these channels (1 AC3 frame), the other 18 have to be
filled with something.
> I wonder why package dropping is such a problem, though - as long as you
> drop complete package the ac3 decoder IMHO shouldn't get upset. Otherwise
> you risk that audio playback becomes async to video.
The problem is that one AC3 frame lasts 0.032ms.
How is one going to do fine tuning to stop small async.
Could one take the approach that the audio plays at whatever speed it likes,
and the metronome keeps in time with it.
The video would then have to be the one that moves to sync with the
The problem then arises that the Computer based metronome might clock at a
slightly different speed than the sound card's 48kHz clock.
The only solution I can see to this is to get the metronome to use a
floating point correction which will then sync the metronome up to the sound
I personally think that the human ear is more sensitive to delays and jitter
than the human eye is, so I would go from the audio setting the clock, and
the video just trying to keep time with it.
It does not look to me that much video syncing is done currently. Does the
audio have to keep up with the video, or does the video keep up with the
audio currently ?
What do people think?