various dosemu comments and hacks (sound, delays)
Hello.
Quoted 1 line · Ryan Underwood
1) Ctrl-Alt-F fullscreen crashes dosemu with a X-Shm (Shared memory)
Searching the google reveals that many programs have that problem so I suppose it is not dosemu-related. It crashes right in a mode-switching routine of X (if you add an XSync calls).
Quoted 1 line
for the first time. Minor problem.
But rather annoying actually:(
Quoted 1 line
for (i = 0; i < bogo; i++);
Busy loops?? I guess we have a better ways to do delays (oh, probably a precision of that other methods is bad, but I guess the busy loops is a bad thing to do).
Quoted 1 line
3) The Adlib emulation is not working well on my machine.
What adlib engine are you using? The one currently inside dosemu is not intended to work at all.
Quoted 1 line
emulation, so DOSemu isn't constantly being blocked by the Adlib emulation code.
There is practically no adlib code in dosemu for the moment (only timers are implemented so that the progs can detect the adlib) so where does it go blocking?
Quoted 1 line
4) SBemu seems not quite working.
Really? :)
Quoted 2 lines
On my Aureal AU8830, when a new DMA
buffer is "loaded" and begins playing, I hear a click or pop, but nothing after that point.
Surely you could find the card with even buggier third-party drivers, but at least you could visit the project page and dig the patches section:)
http://sourceforge.net/tracker/index.php?func=detail&aid=680632&group_id=8109&atid=308109
Quoted 1 line
In order to get this far, however, I had to change the two opens of
/dev/dspfromO_RDWRtoO_WRONLY.
In general this is not a solution, it will break recording (yeah, unlikely is used under dosemu, but anyway).
Quoted 4 lines
The AU8830, like some other
cards, only allows one application at a time to open the device for reading. Subsequent attempts at opening for read causes driver to return-ENOMEM.
I don't think dosemu opens it more than once at a time.
Quoted 2 lines
he offending opens are in
linux_sb_get_version()andlinux_sb_enable_speaker()insrc/arch/linux/dosext/sound/linux_sound.c.
Note that linux_sb_get_version() closes /dev/dsp right after opening, so only the linux_sb_enable_speaker() really keeps it opened, so there must be no multiple openings in O_RDWR mode (at least not intended to be).
Quoted 1 line
5) I'm working on VCPI and "unreal-mode" support. Someday, it will happen. :)
Optimist:)
Quoted 1 line
Let me know if you have any comments!
You've got it:)
Hi,
Quoted 6 lines
Quoted 1 line
for (i = 0; i < bogo; i++);
Busy loops?? I guess we have a better ways to do delays (oh, probably a precision of that other methods is bad, but I guess the busy loops is a bad thing to do).
I know busy loops suck, but I wanted to illustrate that putting delays in those places (regardless of the nature of the delay) is something that can be used as a smooth speed throttle. :) If you can come up with a better delay, be my guest.
Quoted 4 lines
Quoted 1 line
3) The Adlib emulation is not working well on my machine.
What adlib engine are you using? The one currently inside dosemu is not intended to work at all.
The patch that is provided on your homepage. It creates some noise that sounds vaguely like the intended output, but it causes an extreme slowdown in execution speed since the emulation code is implemented as extra procedure inserted within the main program, as opposed to a thread or separate process.
Quoted 2 lines
detect the adlib) so where does it go blocking?
In this case, what I mean by "Blocking" is simply that the adlib code is executed in sequence and the rest of dosemu is halted until it is finished.
A separately scheduled process would seem to model the behavior of the real hardware more precisely; instead of the program stopping and waiting for the synthesizer chip to process the data and play the sound (which is what the current patch seems to do with respect to the emulated opl), the program running on real hardware simply writes data to the I/O ports and continues execution while allowing the synth to process the data as a separate entity.
Does that make sense?
Quoted 5 lines
Quoted 3 lines
On my Aureal AU8830, when a new DMA
buffer is "loaded" and begins playing, I hear a click or pop, but nothing after that point.Surely you could find the card with even buggier third-party drivers,
Actually, probably not. :)
Quoted 4 lines
but
at least you could visit the project page and dig the patches section:)
http://sourceforge.net/tracker/index.php?func=detail&aid=680632&group_id=8109&atid=308109
Hmm, Feb 03... Guess I'll check that one out. :)
(This patch wasn't there when I went loooking for fixes at first last month)
Quoted 5 lines
Quoted 2 lines
In order to get this far, however, I had to change the two opens of
/dev/dspfromO_RDWRtoO_WRONLY.In general this is not a solution, it will break recording (yeah, unlikely is used under dosemu, but anyway).
No problem, it can be tried to open O_RDWR first, and then O_WRONLY if the first returns fd=-1.
Quoted 7 lines
Quoted 5 lines
The AU8830, like some other
cards, only allows one application at a time to open the device for reading.
Subsequent attempts at opening for read causes driver to return-ENOMEM.I don't think dosemu opens it more than once at a time.
Yeah, but it's already opened by another application I am using (liveice).
Quoted 9 lines
Quoted 3 lines
he offending opens are in
linux_sb_get_version()andlinux_sb_enable_speaker()
insrc/arch/linux/dosext/sound/linux_sound.c.Note that
linux_sb_get_version()closes/dev/dspright after opening, so only thelinux_sb_enable_speaker()really keeps it opened, so there must be no multiple openings inO_RDWRmode (at least not intended to be).
No, the problem isn't multiple openings by dosemu itself, it's that if something is already recording on the system, dosemu sound _playback_ won't even work since the device open will fail.
Quoted 3 lines
Quoted 2 lines
5) I'm working on VCPI and "unreal-mode" support. Someday, it will happen. :)
Optimist:)
Yea, we'll see.
Thanks!
Signature · 1 line
Ryan Underwood, <nemesis at icequake.net>, icq=10317253
Hi,
Quoted 11 lines
Quoted 1 line
4) SBemu seems not quite working.
Really? :)
Quoted 3 lines
On my Aureal AU8830, when a new DMA
buffer is "loaded" and begins playing, I hear a click or pop, but nothing after that point.Surely you could find the card with even buggier third-party drivers, but at least you could visit the project page and dig the patches section:)
http://sourceforge.net/tracker/index.php?func=detail&aid=680632&group_id=8109&atid=308109
I patched this patch, and SBemu is working well on Aureal Vortex AU8830! :) Thanks for the heads up...
Signature · 1 line
Ryan Underwood, <nemesis at icequake.net>, icq=10317253