Ryan Underwood wrote:
Yes, the dmixIs there a planned solution for that? Or is there something in ALSA that can help with the real-time mixing even under that hostile conditions? dmix?
Will this require an ALSA support plugin for dosemu, or it is somehow possible to use dmix via an OSS emulation layer?
any soundcard that is modern enough to not have a OPL* cell on it should support multiple opens.
I think there are many cheap PCI boards without either. Btw, AFAIK WinXP decided against using the HW mixing (I may be wrong), in which case it (HW mixing, not XP) will not survive for too long:)
If you think the mixing should be done inside the application
Actually I don't think so. But otherwise we have to write another output plugin (you can't do too much with OSS) and we may still need an internal resampling anyway, because the program may alter the sampling rate on the fly (without interrupting the transferr) and I don't know if any of the existing software can handle that properly. Internal resampling will also help the current OSS output a lot. So it is a matter of writing another output plugin and internal resampling. This is a good thing to do, but as noone has time...
I tried to keep the application interface very simple and do most of the device management internal to the library, so the application programmer has to do no more than create a synth device, check if it was successful, and then write data to the device.
So does it interact with ALSA, or you decided to do it a standalone?
[]I can create a threaded interface to the library instead that operates within the process context, and returns a buffer to be mixed by the programmer of the application.
It also
requires the program to have different behavior whether there is real or emulated hardware.
OK, that makes sense of course. It is good that your lib can use the real hardware and no point to drop that only because noone wants to write another sound plugin (and resampling!) for dosemu:)
It didn't seem like as flexible a solution.
Yes, it is just cheap (I think) and is more feasible under the current circumstances etc, but after all it is rather poor.
By the way, has anyone looked at using QEMU in dosemu?
Yes. Fabrice asked me to remove the coopthreads from dosemu to make it qemu-compatible. The replacement for coopthreads is already in CVS, but the complete removal of coopthreads will require also removing comcom.com, so the coopthreads is still there. OTOH I asked Fabrice to add some dos4gw support to qemu. He did that and dos4gw now runs, but not that I was able to really get some of the prot. mode apps running. Before qemu to support at least the minimal amount of DPMI apps, I think it is useless for dosemu (also even far not all the realmode apps are working). After all qemu is officially in an Alpha stage (the last time I checked), so it may be too early for the integration (but a good long-term ToDo if someone have enough time and motivation).
- 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
