[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-msdos
Subject:    Re: XMS problem with Aladdin demo
From:       Ryan Underwood <nemesis-lists () icequake ! net>
Date:       2005-03-07 23:23:40
Message-ID: 20050307232340.GB28434 () dbz ! icequake ! net
[Download RAW message or body]


On Mon, Mar 07, 2005 at 04:44:43PM +0300, Stas Sergeev wrote:
> The main requirement is that it must
> not access the OS sound driver (OSS
> or ALSA) directly, like it does now.
> There must be mid-layers in-between,
> like at least resampling and mixing.
> This may be done by the use of some
> sound server, but most "low-end" sound
> servers do not support the variable
> sampling rate, i.e. you can't change
> the rate without re-connecting to the
> server. Other servers have the
> unacceptable latencies.
> There are now appearing those modern
> sound servers like JACK, which probably
> can satisfy our needs, but I haven't
> looked into that.

Yeah, JACK is both low-latency and allows the sample rate modification
on the fly.  Problem right now is that JACK only supports ALSA as a
backend because the other sound APIs have not enough features to support
it.  And SDL is too simplistic as you've mentioned.  What about
PortAudio?  It uses the callback based model like JACK but with many
more back-ends besides ALSA.

There is the problem still of cards which do not support hardware
mixing.  However, two things will change this in ALSA soon.  First, dmix
will be a default plughw device configuration, so users will not have
problems with this.  Also, ALSA semantics should be changed to return
-EBUSY instead of blocking when a sound device is opened who is busy -
there was a debate about this on the kernel mailing list recently.  A
problem I don't know enough about is what control over the audio stream
we get when dmix is in use.

Additional problem of using JACK is that it doesn't work with dmix, so
it would block the card on a device which only supports one stream.

> Another thing that have to be changed,
> is that the SB emulator have to control
> the rate itself, not like it does now -
> write to the device until the buffer
> is full. Some DOS progs controls the
> DMA registers during the sound output,
> and that's why we have to guarantee the
> smooth transfer and the accurate timing
> ourself.

Does this imply we must mmap the sound buffer?

> This all will also require a major
> changes in the SB and DMA emulators, as
> now they are too OSS-oriented. For example,
> to change the speed, currently the sound
> code waits for the OSS buffer to became
> empty, resets the sound card, sets the
> new parameters, and resumes the transfer.

Yes, this is completely stupid.

> It is obvious to see how difficult and
> ineffective it is, and it is really a
> big surprise that it works out right most
> of the time. Well, thats because I added
> a tons of heuristic about choosing an
> optimal buffer sizes, tuned it separately
> to a hundreds of games, etc. What a
> silly timewasting it was, but at the time
> of doing this, dosemu was not compatible
> with pthreads, and the "good enough"
> sound servers were not even on a horizon
> (or at least I wasn't able to find them).
> And I also followed the old code that
> was there since 1995, instead of just
> rewrite everything.

Well, this may have been sufficient at the time, since we had not even
idea that e.g. VESA, DPMI, WfW support would become so good.  Now the
SB support is the worst part about trying play any games with dosemu.

> Now it may be wise to finally rewrite
> everything from scratch, rather than
> hacking with the current code. The fact
> that it actually happens to work, must
> not confuse anyone.

This is why I asked you to post this, because your experience is
valuable here.

> It may not be difficult to implement,
> but only if the architecture is properly
> designed. Otherwise it will be just
> another time-wasting. That's why
> noone even dare to start the work:)

Well, it would help if we had more than two developers... I think dosemu
has a marketing problem at the moment comparing to dosbox and qemu :)
I think there is the illusion that it is only good for running business
programs.  Until 1.2, that was somewhat true.  Also, there are many
FreeDOS bugs that get blamed on dosemu (at least, I used to blame a lot
of FreeDOS bugs on dosemu...)

DOSEMU has so many features that nobody even realizes.  It is the only
real v86 monitor for Linux with native execution and native I/O on any
IA-32 processor.  It has no end of the useful features like networking,
vmodem, printing, native VGA graphics on the console, etc.  It is the
only PC emulator which is anywhere close to useful on my P120 laptop,
and it's so nice I can play games with almost no slowdown compared to a
real DOS, depending how nice they are with PIT and SB.  I can use
external hardware with no slowdown, even interrupt driven!

This problem of perception is why I would like to start a wiki like we
discussed once.  I think it would be nice if users would post their
experiences with random apps, and whatever dirty hacks they needed to
get something to work.  It would at the same time be a support area and
a marketing area, because other people would be able to see all the apps
that work no problem and realize that dosemu is actually useful.  Users
would be able to add entries, and admin would be able to edit and delete
entries.  I could put this on my server, but I don't think it would be
dependable.  Do you know if sourceforge provides any PHP or CGI support?

-- 
Ryan Underwood, <nemesis@icequake.net>
-
To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
[prev in list] [next in list] [prev in thread] [next in thread]