Hi Stas, On Thu, Jul 10, 2003 at 09:20:50PM +0400, Stas Sergeev wrote: > > Ryan Underwood wrote: > >The idea was to be able to file bugs against a particular > > application under a particular DOSEMU version > I think that can be helpfull. But as the > bottleneck of a dosemu development process is > unfortunately elsewhere, I wouldn't assign the > prio to that your project higher than to your > adlib server:)
No problem! > >It should function similarly to the WINE application compatibility > >database. > Just wondering, is/was that possible to reuse > their (or other) code rather than writing your > own? Possibly. I felt like hacking something though and started it, but if anyone has suggestions for a pre-existing software that will do the trick, that is fine too. I didn't want to use something huge like bugzilla because there are too many irrelevant/redundant features, and it's not really good for a "compatibility database" as far as I can see. > >whether or not it works with any of the other emulators (FreeBSD doscmd, > >DosBox, Bochs, etc) > Actually testing against NT or 2000 dos box is > the most important. Bochs and doscmd are out of > comparision. doscmd actually is quite similar to dosemu, it uses a v86 window to do its work, but doesn't support lots of nice dosemu features like DPMI. > PS: I think there will be problems with your > adlib server as a separate process to mix the > sound with dosemu's SB digital output in real-time. > The adlib server must do a frequent small transferrs > together with taking care about keeping the OSS's > buffers partially filled to avoid underruns. > At the same time dosemu's DMA will write a > large blocks and very infrequently. When the > block from DMA arrives, there is already a data > from an adlib server in a real card's DMA buffers, > and there is no possibility to mix so lately > (unless the hardware permits). > So I beleive the DMA and Adlib sounds will always > interrupt each other, unless they are coordinated > and using an internal mixing (not per your design). > Is 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? Yes, the dmix, or a soundcard that supports hardware streams mixing, will be required if the user does not have a real OPL* chip. The other option is to do the mixing internal to dosemu. But I think any soundcard that is modern enough to not have a OPL* cell on it should support multiple opens. If you think the mixing should be done inside the application, I will need to re-design the library. I turned it into plain old libsynth already, because it can support all sorts of programmable synth using either emulation cores or forwarding to hardware (CMS chips, C64 SID, etc). 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. 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. The problem with this is that I don't know if pthreads are scheduled by the kernel on every platform. It also requires the program to have different behavior whether there is real or emulated hardware. (If you have real hardware, there is no buffer to be mixed...) It didn't seem like as flexible a solution. By the way, has anyone looked at using QEMU in dosemu? -- Ryan Underwood, <nemesis at icequake.net>, icq=10317253 - 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
