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

[joy]

ok, just commited new version. mmap supports now also u-signed-8bit
streams or whatever up to 24chn (interleaved). it was a mistake by me
calculating frames_len :(.
feel free to try (test) it.

On Thu, Jul 18, 2002 at 10:05:01AM +0800, Anders Johansson wrote:
> 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.
?
what do you mean with float?? i guess int to float conversion has to
be done earlier (in some decoder?). so far i get data only in plain
ints, i see no reason to do int -> float in ao_alsa. what would be the
improvements to do so?
i actually started an ao_jack, i did already a kind of 'sounding'
prototype :) but sound is horrible till now. since jackd recommends to 
have data in float i think i have to make a conversion here. also
buffering is a problem, cause jack has a kind of poll-mechanism and
mplayer uses push&write method i started to implement another
buffer. im stucking now on this (double)-buffer thing. its somehow
also against jacks-philosophy, but it's the only way to get jack
working with push&write-apps.

> 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. 
> 

yes, i already forget where i read it and i was also in doubt if it
could be true. 

> 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.

i don't know so much about OSS, sorry, and oss_plugin is arpi's domain
;). what i saw in ao_oss is that it trys to figure out the
max-available-buffersize and simply sets the max_buffersize then. -abs has no
effect, but maybe i'm wrong?
for low-latency-issues and cause alsa has a 'cleaner' architecture
i recommend to switch to alsa9.
VJ-option sounds interesting :).


-- 
regards

____-
joy

________/\---------%%%___________-----------
webcast every sunday 2000 cest at pingfm.org

pgp key at: x-hkp://wwwkeys.de.pgp.net