Re: App database, libsynth

[Ryan Underwood <nemesis-lists@icequake.net>]

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