[MPlayer-dev-eng] real mmap-support in ao_alsa

[Anders Johansson]

Hi,

> just finished real-mmap-support for alsa9-plugin. means sound will be
> written directly into memory-mapped-audio-buffer. it currently
> supports only signed-16-bit streams but it falls back to traditional
> write-mode if another format is requested, its the default-mode
> anyway.
> i think this mmaped-write is a more cleaner architecture cause it
> gives back the real value of written frames to mplayer where
> normal-write only loop's as long as all frames are written, and returns
> always len no matter if they are written or not.

Good work! see if you can get float to work as well.

> i know that audio-processing doesn't cost so much cpu/io on modern
> machines and i can't measure real differences between mmaped-mode and
> traditional io-write but maybe it helps users on really slow hardware
> who need all tweaks on cpu and io to get a vid running. i read also
> somewhere that sound-quality should be better, could be theoretically
> cause its one step shorter to the line-out, but assuming what is all
> 'humming' around in a normal pc it could never be like hifi-quality,
> and it doesn't make any difference if sound-stream is written directly
> into memory or not. i don't have a super hightech-hifi-setup so i
> can't verify this anyway.

Mate, you would need to be a wizard to hear any difference, cause it
is incorrect. The number of software buffer steps only has an impact on
delay and speed (it's not like the cpu scrambles the data while it's
copying). Trust me, we are building our own analog I/O boards where I
work, and we have never been able to detect any signal degradation
because of too many buffers, and I am using a $30000 dynamic signal
analyzer to verify it... What you have heard is true for analog signal
processing however, i.e after the signal have left the D/A converter. 

> i would also reintroduce the obsolet -abs opt for alsa9 cause i think
> it's usefull for some cases to have bigger/less buffer- and
> fragmentsizes. for example if users run on slow hardware they can
> increase buffer- and fragmentsize but on fast hardware they can lower
> it, while gaining better latency. i prepared 4 most reasonable and
> used modes for this:
> 
>   mode	   fragmentsize		buffersize
>   1		512		8192
>   2		1024		8192
>   3		512		16384
>   4		1024		16384 (consumer mode ;)
> 
> where mode 1 is default for mmap-write and mode 4 for 'normal'-write.
> im thinking also of a mode 5 where the maximum buffersize is set
> automatically but im not sure about this, cause 16384 frames
> buffersize is more than enough for 99% of cases and its also the
> dead-end for most soundcards supported by alsa i think.
> any suggestions about this?
> if it is accepted it would be cool if there would be some hint about
> this in the documentation at least about the mmap-feature.

I would appreciate such a switch, make it generic cause It would be an
interesting feature for OSS as well. I want to be able to mix the data
stream with other types of input in a future karaoke mode, and that
requires short latency. It is also interesting for a possible VJ
option.

Cheers,
//Anders