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:)
- 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
