[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
Michael Bukin <M.A.Bukin@xxxxxxxxxx> writes:
> About 2 weekends, without adding new features. I will have more spare
> time now and will try to finish X-windows version ASAP (but without code
> for setting custom window as screen).
Please don't feel in any hurry: I'm not trying to push people into finishing
things, or anything so organised as that :-)
I'd particularly like to have at least some basic level of X support in the
final 4.0 version, but that doesn't mean any rush in writing it: just that
if you say it will take six months, maybe I'd wait that long before calling
it a finished version, while for other less important things I'd be more
likely to go ahead and release it even if they weren't quite finished.
> Buffer size means samples per buffer, when playback rate is set to 44kHz,
> one buffer should play in samples/(samples_per_sec) = 4096/44000 = ~0.1
> sec.
That does sound plausible. 0.1 sec is far too long for something like DIGMID
or a mod player to work well, but any smaller values might start skipping on
less powerful machines. I think there is some latency coming from other
places, though, because on my machine it was defaulting to 22k, which should
give 0.2 sec delays, but in practice I was getting more like 1 or 1.5 secs
(I didn't time exactly).
Ok, I think a general average would be a good way to decide on the default:
if anyone has working OSS audio under Linux, would you mind having a fiddle
and see how low you can get the fragment size? Set the sample rate to
44k 16 bit stereo if your card can do it, or 22k otherwise. Email me
privately (not to the list, please) telling your soundcard type, processor
speed, and what is the smallest fragment that you can get before the sound
starts to skip and break up. If we get enough of that sample data, it will
hopefully be obvious what is the best default value to use.
> The problem is, we need to know parameters for playback (stereo/mono, 16/8
> bits, playback rate) before calculating preferred buffer size, but buffer
> size must be set first. It might be possible to open device for the first
> time, set playback parameters and obtain values selected by device driver.
> Then close device, open it again and now request buffer with correct size,
> and set parameters again.
I like that idea...
--
Shawn Hargreaves - shawn@xxxxxxxxxx - http://www.talula.demon.co.uk/
"A binary is barely software: it's more like hardware on a floppy disk."