Re: App database, libsynth

Ryan Underwood
2003-07-11T19:59:29Z

Hi Stas,

On Fri, Jul 11, 2003 at 11:02:07PM +0400, Stas Sergeev wrote:
> Hello.
>
> Ryan Underwood wrote:
> >>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
> Will this require an ALSA support plugin for
> dosemu, or it is somehow possible to use dmix
> via an OSS emulation layer?

The synth server's output would be completely separate from the
application using it, so the synth could use ALSA where dosemu could
still use the OSS emulation. Unfortunately OSS emulation blocks when
ALSA is in use, so one would have to use a wrapper like aoss to redirect
the dosemu OSS output to ALSA. ( see below (1) )

IMO, it would be a good idea to start to use ALSA in dosemu. I can't
volunteer to code it at the moment though, too much else going on :(

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

In that case, it is a good idea dmix is around. Unfortunately, software
mixing is CPU intensive and dosemu is already emulating lots of things
in the X version (svga, blaster, etc).

I would be curious to find out if XP really got rid of hardware streams
mixing or not.

You may be right that people are stuck with OSS drivers that only
support 1 stream and have no FM device. I don't see a way to deal with
this at the moment. Though you would be hard pressed to find a
soundcard that didn't have an ALSA driver these days. And, c-media PCI
cards have an opl3 onboard and cost something like $5. :)

>
> >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...

Yeah. Also what about sending pc-speaker output to the dsp?

> >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?

(1) Theoretically, it can output to either ALSA or OSS, though I use ALSA to
test it. I guess the best thing to do is to let the application
programmer set whether it outputs to ALSA or OSS at runtime.

> >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.
>

Ok, well I'll continue working on libsynth until I see a problem with
its design :) I have wolf3d (the icculus port) playing adlib music
through it, but it needs to be made a lot better.

The configurations I was thinking about being relevant to dosemu are:
- Single OPL2 (adlib)
- Dual OPL2 (SB Pro)
- OPL3 (SB Pro II, SB16)
- CMS chips (Game blaster)
- Tandy/PCJr TI sound chip

Of course you could program a C64-SID from a DOS program if you wanted
to... :) Just set it up at some port address in dosemu, create the
synth device, and program it like you had a C64. Maybe if you have a
HardSID card you could use that too.

BTW there is an ongoing project to implement a MT-32 emulator in dosbox.
Once that is complete I can implement the emulator core as an ALSA
sequencer client, which if dosemu had alsa support, it could connect to
that sequencer slot and use the MT-32. Or else maybe something could be
done with midid? Is midid a good idea to keep around for the long term?

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

Agreed, in fact something that might be a good idea to do is start
making a checklist of things that need to be done before dosemu will run
on another non-x86 linux platform.

If the x86 emulator becomes working, dosemu will be the most flexible
dos emulator around, either working in v86 mode, using a svga card,
sound blaster, etc on the real hardware, all the way to a complete
emulation of a DOS machine on completely foreign hardware. That way if
the user has a x86, they get very fast speed for the most part, and if
they don't have a x86, they can still have the same high level of
compatibility that dosemu has.

There is always the possibility to port to a non-linux platform but I
think it will take untying it from the x86 hardware to get more people
interested in dosemu long-term.

--