[MPlayer-dev-eng] Libao2 patch

Anders Johansson ajh at atri.curtin.edu.au
Wed Nov 21 03:25:57 CET 2001


> Hi,
> 
> > Here it is. The new interface for libao2. I have changed all drivers
> > except for the dxr3 driver. I am pretty sure the oss, mpegpes, null,
> > pcm, plugin, sdl and sgi drivers are bug free. I am a bit unsure about
> > the alsa and sun drivers, perhaps they should be checked before the
> > patch is applied.
> 
> I've readed the patch, looks ok to me but please someone else also check it,
> as many things are changed (trivial changes but lot) and we can't test all
> of them so it should be double-checked.
> 
> only exception i've found:
> 
> -       ret = snd_pcm_status_get_delay(status) * ao_bps;
> +       ret = (float)snd_pcm_status_get_delay(status)/(float)ao_data.samplerate;
> 
> why do you divide it by ao_data.samplerate

because ao_bps = channels*bytes_per_sample in this driver. 

> other thing to care of:
> channels+1 channels channels-1 seems to be mixed somehow.
> i have bad feeling of it but maybe i'm wrong and the patch is correct
> everywhere.

This is the assumption I have been working with:
mono = 0
stereo = 1

To get number of channels add 1. I am not entirely sure about this but
it works in ao_oss so it should work everywhere. Also there is a hint
in the alsa5 driver (see line 70).

> also note, these changes are not simply noticable by testing drivers, as
> they affect long-term a-v sync code and can cause small (0.1-0.2s) delay
> which you maybe don't notice at all.
> so, source checking is the only way now :(
> 
> as you will see, the biggest and most important change that get-delay() now
> returns float (seconds) instead of int (bytes).
> it requires dividing values by bps (bytes per _second_). so bps should be
> calculated, as channels * samplerate * bytes_per_sample.
> 
> but value of channels sometimes is 0=mono 1=stereo, sometimes 1=mono
> 2=stereo or what.
> 
> 
> A'rpi / Astral & ESP-team
> 
//Anders



More information about the MPlayer-dev-eng mailing list