Hello.

pesarif wrote:
> I've just tested out your patch.
Thanks:)

> In general, it's perfect :) except that most programs still can't detect it
This is improved in the devel version of dosemu, but don't expect perfection
anyway. 

> and there's no music :(
Upgrade your soundcard with a midi daughterboard:)
BTW, how about SoftOSS?

> (btw, when you write the music code (please!),
What I know for sure is that I am not going to write an OPL code. I am
thinking about stealing it somewhere, or make it possible to use timidity
for an MPU401 midi on top of the /dev/dsp. But even this is not going
to happen soon (if you are not volunteering for help, of course:)

> Here are some of the more interesting results of testing (i.e. the results that you 
>probably want to know about):
> Nice, the top three are my favourite DOS games :)
Nice:)

> Warcraft 2 is misdetecting the sound emulator as "Ensoniq Soundscape" (which 
>incidently is my real sound card).
... and still works correctly?

> If I start Count Down and wait for the initial scream (yes, this is an interesting 
>game) to finish before pressing a key,
> the intro music and the sound is fine.  But if I interrupt the initial scream (i.e. 
>don't wait for it to finish before pressing a key), lots of sound
> (almost all the sound in the game) disappears and if there is any sound, it lasts 
>for a few seconds and then stops; with the into music, it skips
> entire segments and then stops :(  This game is commercial and is by Access 
>Software, which has been bought out by MS so I can't give it to you :(
> This behaviour occurs on the 2.4.7 kernel.
> If I use 2.4.3, Count Down _always_ stuffs up no matter what I do.
Wow, it looks like a problems with OSS drivers! I can't keep in secret
anymore the fact that I have done a lot of hacking on my pc-speaker
driver implementing such an unusual things like a non-blocking close
and sorting out a races before I managed to get it working correctly with
dosemu (while it used to work with all other apps long before that).
dosemu (my sound code) does a very weird things with a linux sound
driver, stressing it so high that if there are any hidden bugs or
semi-implemented features, they are going to be triggered and cause a
bad results.
Anyway, I would like to see a log of the sound events (-D9+S) to be sure
that it is not my fault:)

> Really Bad > --------
> 
> Clyde's Revenge       no sound        bombs out               locks up (dosemu 
>complains about vfree'ing something)
But vfree() is a kernel's internal function AFAIK and it have nothing to
do with dosemu! Apparently your driver is falling apart and can't satisfy 
the requirements of my sound code:( Only my pc-speaker can:)))
But show me the exact error message, please.
BTW, it would be *extremely* interesting if you try ALSA with OSS emulation
enabled to see how good is... ALSA:)

> Commander Keen 4      no sound        locks up                        no sound
I am still wondering what is going on with this keen. Could you please
upload it somewhere? Or, atleast, do a sound log?

> The latency is now very obvious in Liero, with an annoying 1/2 second
But is the 1/2 second delay is really so annoying???

> The clicking still happens in the game "Count Down".
Make a log. Maybe I will be able to diagnose a problem without having
a game itself.

> btw, I've found out when and why OMF2097 stutters. 
> (I'm using a Pentium II to give you an idea of how fast/slow my computer is)
I have the same with Athlon 700:(

> If I select "Sound Blaster (mono)" and then choose "Very High Quality"
> or "Ultra High Quality", it misses or repeats or a few beats.
> If I select "Sound Blaster (mono)" and then choose <= "High Quality", then it's fine.
> In an unpatched DOSemu 1.0.2.1, If  select "Sound Blaster Pro" and then
> choose "Ultra High Quality", there's not a problem.
And what about the latency with an unpatched dosemu?
BTW, I have the described above problem also with unpatched dosemu.

> So, I think your code is a little slow :(
This really seems like a performance problem. I am trying to do a smoother
transfers than the old code does, hence more overhead.
But, as I already said, I have this problem also with unpatched dosemu,
so... Maybe it is also due to a different kernel drivers: my driver is
extremely cpu-hungry.
BTW, when I decreased a sampling rate twice, OMF stops stuttering
and produced a perfect sound (not counting that it was twice as slow:)
so it is a performance problems for sure.
Anyway, setting OMF to High Quality solves the problem, so I am going
to leave it as it is.

> Segfaults have always been happening when a program tries to start
> with SB (even with unpatched dosemu 1.0.2.1).
But you missed the fact that it happens only with OMF and also it happens
if you disable sound in your dosemu.conf. So it is definitely not a bug in
my code and most likely a bug in OMF itself. It is trying to use SB even
if it is not present, but specified in OMF's setup. Not a good behaveor.

> ERROR: unexpected CPU exception 0x06 errorcode: 0x00000000
> while in vm86 (DOS)
This is important: "while in vm86 (DOS)". So OMF's problems. Setting it for
"no sound card" (which is true in this case: it is not emulated when /dev/dsp
was busy at dosemu's startup) helps.

> > I was playing it a little today, but it seems to be too easy: I found only a
> > couple of good punches and was able to win all battles within 20min at "veteran"
> > level. 
> What robot are you using? 
It was Katana, I guess.

> I tried to copy this tactic and I got defeated first round...
> May be you should play on a higher difficulty setting.
I tried "Champion" and also won all battles, but was defeated several times.
> only just beat the computer on Ultimate.
??? "Champion" is a hardest level I have in the game.
Never mind, it is off-topic anyway:)

> I have a bunch of other games that don't detect the sound card as you said:
> > Note: some features mostly related to a detection of soundblaster's presence are
> > disabled because it requires a changes to PIC, which are not yet merged to a
> > mainstream. But this is not very noticeable, I hope.
> Please merge these soon.  It is quite noticeable :(
They are already in (1.1.2.8). I think I will no more make a diffs
against 1.1.2.

> > BTW, recording might work now. I just can't test it, but all necessary code
> > is already in place.
> Recording?  Do you mean saving what comes out of DOSemu as a .WAV
> file or similar?
No, I mean recording from MIC or Line input.

> If so, how can I do this?
Hmm, writing to file is a very interesting idea. The only problem with it is
that now linux driver controls the transfer speed, and if I want to write to
a file, I will have to control the speed myself, which is untrivial...:(
But I'll think about it.

> I really like the patches and hope to see them in the next "offical" version
> of dosemu. 
OK. I think I'll start preparing them for the inclusion.

> Soon I can say goodbye to Win98 to play DOS games with sound :)
Don't count too much on this: Win98, AFAIK, allows a direct access to
the real sound hardware (without any emulation) so it is unbeatable in
this area...
-
To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to