[vdr] Re: bitstreamout-0.48pre5

["Dr. Werner Fink" <werner@suse.de>]

On Thu, Oct 30, 2003 at 02:56:47AM +0100, Sven Goethel wrote:
> > Hmmm ... what so you think about not usleep(ing) but simply
> > playing silence.
> 
> ok .. please point me to the silence call in spdif ..
> 
> and you are right .. usleep distorts audio out ..
> 

Simply by adding/setting a calcuated offset to setup.opt.delay.

> >
> > OK ... this could be handled by buffering (ring buffer _and_ hw
> > buffer of the sound card). But IMHO the timing of this audio stream
> > is broken (as all channels on this transponder) ... it seesm that
> > ARD has changed their encoder.  Currently I hear that the audio
> > on all channels on transponder 11837 is shuttering due to this bad
> > timing.  Only if you catch a small delay at start you're able
> > to smooth out the unstable audio stream by buffering it.
> 
> yep .. bad timings
> stuttering audio on normal playout either
> 
> as i said the data is taken from the ringbuffer,
> in the case of late audio the ms are skipped (mp2dec delay),
> then again the audio early for a few periods ..
> 
> the dPTS is 72ms const. but the dSTC variants depending on 
> the taken action (skip data or not), but the problem is that
> STC grow more than PTS so audio delays ..
> 
> >
> > You will not hear/see a difference without comparison (your test
> > above with the echo effect).
> 
> so .. for this case, as well on recordings it works.
> 
> just the action,skipping audio -> mp2dec delay, stutters audio,
> 
> but you can see - without skipping these audio ms, 
> the audio will gets later and later .. about 1-2ms,
> which is about the decoding time itself.
> 
> so .. here is a little brainstorming:
> 
> +++
> 
> .. could only be managed by holding the video itself buffered
> to have a chance to sync a/v completly by our self (-> transport ?).
> 	-> too complicated
> 
> +++
> 
> or this will prove, that the incremental delay of decoding mp2->pcm
> won't make it possible to have a a/v sync.
> 	-> hopefully not ;-)
> 
> +++
> 
> or the ringbuffer code usage is wrong at live-view (channels.c).
> well on replay mode, the mp2->pcm is really done at playside, by the
> player thread - which plays video as well.
> but on live, the rinbuffer taker - spdif pusher does all this work,
> which might be wrong ..
> 	-> i will test this
> 
> +++
> 
> hmm .. or else ;-)

First of all, the channel owner on transponder 11837 (ARD group)
has to be informed that their audio setup is broken and cause
shuttering audio.

For the 1-2ms decoding time: this should not be a problem
because you get MP2 audio in blocks (0.5ms), decode them (1-2ms),
put them into the hw buffer of the sound card (0.5ms) ... and the
block takes some _more_ ms ... that means we've enough time if we
switch from 32ms PCM buffer to a buffer size fitting the _minimal_
MP2 audio block size used by the libmad,  I guess its less than 32ms
if not the SPDIF_BURST_SIZE has to be increased and a new
cpp macro AC3_BURST_SIZE has to introduced with the old value of
SPDIF_BURST_SIZE.

And ... then we may see a timing problem between the normal time
used by the channel and the quart of the sound card, normally
those are NOT in sync.  This leads to underruns or overruns.  With
my setup I get underruns (the quart of the CMI8738 is about 100ppm
faster then the clock of Pro7).  To avoid underruns the bitstreamout
plugin repeats on the lower hw sound buffer boundary every fourth
frame upto the upper sound buffer boundary.  In the case of overruns
the plugin simply skips frames.  This works very well with AC3.

Maybe for plain PCM it is better to repeat or skip a few stereo
samples (one stereo sample are two unsigned shorts).  This should
be done before the data is stored into pcm stream scanner. The
best point for repeating or skipping is a part where left and
right channel has similar values and this value is used a longer
time (e.g. silence).


      Werner


-- 
Info:
To unsubscribe send a mail to ecartis@linuxtv.org with "unsubscribe vdr" as subject.