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/