[MPlayer-dev-eng] About the future - libao2

[David Holm]

Arpi wrote:

>Hi,
>
>>>no. my plan:
>>>video codec -> libvo2 core -> libvo2 driver
>>>
>
>>I think that your idea of having a conversion layer before the output
>>layer is very good and that it should be extended to libao2 as well:
>>
>>audio codec -> libao2 core -> libvo2 driver
>>
>you mean libao2, right? :)
>
>>What to do with sync (I tried to read the source but gave up (didn't
>>know where to start))? I have a few suggestions though.
>>
>most (all :) libao2 drivers has some buffering (usually in hardware or dma
>buffers in kernel) which cause some delay. this delay is usually around 0.3
>sec for 44khz audio, but in some extreme cases (alsa driver with fixed 192k
>buffer, low audio samplerate, mono) it can be up to many seconds.
>mplayer's A-V sync code requires this value for correct timing.
>currently, it asks libao2 driver how many bytes are in the buffer, and
>divides by bytes/sec (sh_audio->o_bps) to get delay in secs.
>But, if you change playback rate of soundcard, it will calc false delay
>(bytes divided by input srate). yes, it can be fixed of course ;)
>
>btw, thinking about libao2 (triggered by this mail :)) i've found that i'm
>silly :)
>get-delay() should return seconds (in float or millisec), so mplayer
>shouldn't care about libao2 resampling and stuff.
>
>>With support I could start making the guidelines for how libao2 could
>>look? If anyone else is working on this already just tell me, I don't
>>want to start a fight :)
>>
>afaik, nobody is working (or thinking) about libao2.
>so, feel you free to help us designing and implementing it!
>
I'm thinking about libao2, I considering sending in a patch in a sort of 
apply-if-like manner to add some functionality I kinda miss... I've been 
unsure of what your thoughts on messing with code in mplayer that you 
originally didn't create though. (I will of course make it crystal clear 
in that post that the patch is of an "apply-if-like" manner intended for 
those with cvs access...

>
>
>the only thing i expect: keep current buffering method, i mean:
>- provide a method which returns how many bytes (or samples?) can be
>  played without blocking (required for singlethreaded design)
>  (currently it's get-space())
>- provide a method to query current delay (both your buffers (for resampling
>  or other effects) and soundcard's buffering)
>- use the general, extendable control() interface for driver-specific things.
>  it's like ioctl()'s.
>- thinking about: some codecs (mp3lib, ffmpeg?) can do some work about
>  effects, resampling (1:2, 1:4 for mp3), mono<->stereo.
>
This sounds great... If you start working on libao2 one feature I need 
is support for AFMT_MPEGLAYER1 AFMT_MPEGLAYERII, I'm unsure if AFMT_MPEG 
includes mp3's too (which won't work with my driver), ok Arpi, no more 
rtfm please, I've not gone deeply into the development of the ao device 
yet, I've been concentrating on libvo, I'll rtfm when I get to audio...

>
>
>A'rpi / Astral & ESP-team
>
>--
>mailto:arpi at thot.banki.hu
>http://esp-team.scene.hu
>_______________________________________________
>MPlayer-dev-eng mailing list
>MPlayer-dev-eng at mplayerhq.hu
>http://mplayerhq.hu/mailman/listinfo/mplayer-dev-eng
>