Messages in this thread | | | From | Benno Senoner <> | Subject | Re: [alsa-devel] Re: NEW PRELIMINARY MMAP PROPOSAL - READ PLEASE - (Was: Re: | Date | Mon, 2 Aug 1999 10:30:23 +0200 (MET DST) |
| |
> > I'm not a programmer or developer, so any comments below are immediately > discounted. However, here's my 2 cents: > > > It seems to me, in conversations and observation, what an application > developer (READ game developer!) wants in a sound driver is: > > 1) Low latency. > > That is to say that a sound is played as soon as possible, or at least > in a consistantly predictable manner. Also, jitter and breaks are > unacceptable.
Agreed, but:
a) Quake probably use mmap() + select() to output sound, and therefore in terms of pratical latency, there are little benefits over the write() method , when the system is under high load (especially disk I/O) (I don't think that Quake uses the busywaiting mmap() hack)
Mingo's patches are looking very promising, it's just wonderful to see these sub-1ms scheduling jitters , even if there are still very sporadic 20ms peaks, I'm confident that this can be solved easily.
Consider that if you run a game at 50fps you can use a latency of 20ms and with mingo's modifications, we will get reliable 20ms latency even on an old box, but running Quake on an old 486 isn't too fun. :-)
mmap() lowlatency advandages will only be relevant on SMP boxes where you can use DSP-like busywait loops, but you don't need 1ms audio latency for games :-), 20ms is more than adequate, just because you don't want to head the explosion before she appears on the screen. :-)
> > 2) Consistency in programming interface across a wide array of hardware. > > Either he has to worry about doing his own mixing in his app, or he > doesn't. Either he can use mmap() to access the card hardware, or he > can't. But he want's to write it once and let it run across all > hardware. Note that this probably takes less precedence than #1, of > which a prime example is ID's use of mmap() for Quake (X). In this case, > he'll not worry about the lesser hardware and it's tough luck.
Agreed, write() has the nice advantage of software mixing, re-routing to other audio-apps or audio-outputs etc .. Yes, you can archieve these things with mmap() too, but then you will loose the advantages, since you need intermediate buffers for mixing or re-routing. > > > More notes below: > > Jaroslav Kysela wrote: > > > It allows detection of overruns and > > underruns as well as the support for all hardware. It is also possible > > If you support mmap(), supporting it for all hardware is a Very Good > Thing(tm) (#2). However will it still provide #1 in a reasonable manner?
Yes, I think just because most of the latency problems are scheduling-latency problems. If write() can do it , than an additional layer using mmap() can archieve the same goal, perhaps using a little more CPU on non mmap()-able soundcards, (maybe I could be wrong about the CPU usage).
> > > > Thought: OSS mmap emulation? It wouldn't be possible with all hardware > > (except very ugly ways), but we should retain it in the current state. > > > > Agreed, considering that Q3 requires mmap. Wouldn't want to get hatemail > from all those rabid Quakers out there.. :) What about the folks which use the commercial OSS on a pro-soundcard which doesn't support mmap(), which want to play Quake. They can't because mmap() is not supported on these cards, actually not even through an emulation layer. > > > Thought: If we don't allow to change fragment size and parameters (rate, > > format, voices), we could implement the nice and fast software mixing > > inside the kernel. > > Another Very Good Thing! (#2) If programmers don't have to worry about > mixing sounds themselves, they are MUCH happier.. I think, changing fragment sizes or samplerates is not a big obstacle to software mixing, it could only be a bit slower due to the resampling involved. > > > Unfortunately I thought that the ALSA PCM interface is stable, but it > > seems that much changes are to do, if we begin to implement this mmap PCM > > interface. Again: It seems that the final version of the ALSA won't be > > finished in the near future, because we are implementing new things and > > removing old ones. Bye bye 2.3 kernel? > > > THis is a very good point. Here's my suggestion: > > Let's call for a feature freeze of ALSA for the .4 version. Take what we > currently have, fix all the bugs and update all the code for cards > currently supported, and see about merging what we have into the 2.3 > kernel as primarily an OSS/Free replacement. After all, we have better > OSS emulation than much of OSS/Free does. All the ALSA specific code is > still there, but most people will only use the OSS emulation...for now. > The new mmap() proposal and most of the synth work can wait for .5 or > later.
Hmm, the "bye bye 2.3" worries me a quite a bit, I'd prefer an ALSA version with less features in 2.4 (and therefore in 2.3), over a more feature rich version in 2.6.
A feature freeze for kernel 2.4 would be a good thing(TM).
opinions ?
regards, Benno.
i
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |