XMS problem with Aladdin demo
Hello.
Quoted 3 lines · Ryan Underwood
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:)
Quoted 8 lines · Stas Sergeev
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
Quoted 8 lines
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.
Quoted 9 lines
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?
Quoted 7 lines
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.
Quoted 7 lines
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
Quoted 8 lines
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.
Quoted 5 lines
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.
Quoted 5 lines
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?
Signature · 1 line
Ryan Underwood, <[email protected]>