Re: XMS problem with Aladdin demo

Re: XMS problem with Aladdin demo

[Stas Sergeev]

Hello.

Julius Schwartzenberg wrote:
> very long delays in the sound. Changing $_oss_max_frags = (0x20) to 
> (0x5) seems to fix this. I have this on both my workstation and my 
> laptop. Is this because of a crappy driver/audiochip?
No, thats the crappy sound code of
dosemu this time.

> Is there any 
> reason the default isn't set lower?
I don't know, I think it was to avoid
the underruns, but 0x20 is probably
too much.
Anyway, the sound code needs a complete
rewrite. And this time one really have
to *think* before rewriting it. Currently
there is no manpower to do that.

Re: XMS problem with Aladdin demo

[Ryan Underwood]

On Thu, Mar 03, 2005 at 10:58:58PM +0300, Stas Sergeev wrote:
> 
> >Is there any 
> >reason the default isn't set lower?
> I don't know, I think it was to avoid
> the underruns, but 0x20 is probably
> too much.
> Anyway, the sound code needs a complete
> rewrite. And this time one really have
> to *think* before rewriting it. Currently
> there is no manpower to do that.

What are the requirements of a new sound system, from your experience
with the current one?

-- 
Ryan Underwood, <nemesis@icequake.net>

Re: XMS problem with Aladdin demo

[Stas Sergeev]

Hello.

Ryan Underwood wrote:
> What are the requirements of a new
> sound system, from your experience
> with the current one?
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.
Now that SDL is usually linked in to
dosemu, we can do the mixing/resampling
ourselves as well, and send the output
to SDL too. But SDL doesn't even
provide the ability to query the output
buffer status (the last time I looked),
which is not very good. Though using
SDL for sound looks attractive.
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. For that matter it will probably
be necessary to put the SB and DMA into
a separate thread. But then we also need
a mechanism to make sure our timing is
not out of sync with the underlying device,
and so we have to query the state of the
output buffer and adjust our speed according
to its state. It is probably not easy
to provide an accurate info about the
state of the buffers for the output
software that does the stream mixing,
like SDL, so AFAIK SDL doesn't provide
that info at all.
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.
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.
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.
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:)

Re: XMS problem with Aladdin demo

[Ryan Underwood]

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>

Re: XMS problem with Aladdin demo

[Stas Sergeev]

Hello.

Julius Schwartzenberg wrote:
> The (working) version on my laptop seems to be from 26-12-2004.
Oh, that's strange.

> Is there anything special I need to do to disable Dosemu's XMS support 
> (using the default configuration)?
How one is supposed to disable/enable
something without changing the config? :)
You'll have to alter it by setting
$_xms=(off). Don't forget to also update
your ems.sys and see what diagnostic it
prints on startup. Then update your
config.sys to load himem.sys before ems.sys.

Re: XMS problem with Aladdin demo

[Julius Schwartzenberg]

Stas Sergeev schreef:
> Hello.
> 
> Julius Schwartzenberg wrote:
> 
>> The (working) version on my laptop seems to be from 26-12-2004.
> 
> Oh, that's strange.
> 
>> Is there anything special I need to do to disable Dosemu's XMS support 
>> (using the default configuration)?
> 
> How one is supposed to disable/enable
> something without changing the config? :)
> You'll have to alter it by setting
> $_xms=(off). Don't forget to also update
> your ems.sys and see what diagnostic it
> prints on startup. Then update your
> config.sys to load himem.sys before ems.sys.
> 
Ah, stupid of me :d
I had forgot to copy the new version of the config file to /etc/dosemu, 
so I hadn't seem the new comments.
I've now got it working with himem.sys on my main comp. (My laptop was 
still using the Dosemu builtin stuff.)
I've still got one question though. With the default config, there are 
very long delays in the sound. Changing $_oss_max_frags = (0x20) to 
(0x5) seems to fix this. I have this on both my workstation and my 
laptop. Is this because of a crappy driver/audiochip? Is there any 
reason the default isn't set lower?
Thanks again,
Julius

Re: XMS problem with Aladdin demo

[Stas Sergeev]

Hello.

Julius Schwartzenberg wrote:
> I've already got it working on my laptop in an older CVS version, but 
> on my main workstation it quits everytime with an XMS error.
When exactly it stopped to work?
I think it doesn't work also on 1.2.2,
so it is not something recent.

> Has much been changed to these sections in Dosemu lately?
Yes. But when and why that game stopped
working noone knows (noone cares either
I think, well, it you can say when it
started to fail, this may still be
somewhat interesting).

> What kind things I should try to get this game to work properly?
Disable dosemu's XMS support, use the
native himem.sys...

Re: XMS problem with Aladdin demo

[Julius Schwartzenberg]

Stas Sergeev schreef:
> Hello.
> 
> Julius Schwartzenberg wrote:
> 
>> I've already got it working on my laptop in an older CVS version, but 
>> on my main workstation it quits everytime with an XMS error.
> 
> When exactly it stopped to work?
> I think it doesn't work also on 1.2.2,
> so it is not something recent.
> 
>> Has much been changed to these sections in Dosemu lately?
> 
> Yes. But when and why that game stopped
> working noone knows (noone cares either
> I think, well, it you can say when it
> started to fail, this may still be
> somewhat interesting).
The (working) version on my laptop seems to be from 26-12-2004. The 
version on my main computer that doesn't seem to work is from 25-02-2005.

>> What kind things I should try to get this game to work properly?
> 
> Disable dosemu's XMS support, use the
> native himem.sys...
Is there anything special I need to do to disable Dosemu's XMS support 
(using the default configuration)?

Thanks,
Julius

XMS problem with Aladdin demo

[Julius Schwartzenberg]

Hi,
I'm trying to get the following game to work on my main computer with a 
pretty recent CVS version:
http://www.dosgamesarchive.com/download/game/79
I've already got it working on my laptop in an older CVS version, but on 
my main workstation it quits everytime with an XMS error.
Has much been changed to these sections in Dosemu lately?
I know the game is quite picky about this, so I was very happy to see it 
running on my laptop.
What kind things I should try to get this game to work properly?
Thanks in advance,
Julius