Re: App database, libsynth

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

Hi Stas,

On Sun, Jul 13, 2003 at 06:37:56AM +0400, Stas Sergeev wrote:
> Hello.
> 
> Ryan Underwood wrote:
> >>Yes. But I was wondering will they be able to use dmix
> >> both. Is it available via the OSS emulation layer at 
> >>all?
> >Unfortunately not without the wrapper.  The dmix is done
> > in userspace, so writing to /dev/dsp kernel device would
> > bypass it.  The aoss wrapper intercepts those writes and
> > puts them through alsalib instead, allowing dmix to be 
> >used.
> That practically means using dosemu's OSS output
> plugin will not be possible that way. It does all
> the possible things to make it not compatible
> with any redirectors. Leaving apart the nonblocking
> I/O, it also writes a partial fragments, demands
> the precise quering of a current buffer load and
> all the other weird things, so it is not compatible
> even with most of the third-party OSS drivers.
> But have you tried it with aoss? I have to port my
> pcsp driver to ALSA before I can do that.

Just tried aoss.  It didn't work too horribly on the ones I tried
(Duke3D, Hardball III).  The sound warbles and there are lots of
clicking, but overall it could be a lot worse.  Also some sound is
repeated, like there is a buffer underrun and the buffer gets wraped
around, or something like that.  Duke3D sounds pretty good which
surprised me a lot, considering it is hard on the sound card, and my
Vortex driver is still in pre-alpha for ALSA. :)

> >The PC speaker would seem to fit that model, so if you 
> >have some emulation code, I should be able to include it.
> Unfortunately I don't have anything like that.
> The program I was referring to, was written in
> Pascal.
> You can also have a look in my pcsp driver, but
> it does only the PCM->PDM conversion and not
> the vice-versa (no recording via speaker:),
> and also the code there is complicated by a
> software amplification tricks.

Just to make sure, the PC speaker needs no programming besides writing
to the two hardware ports, correct?

> >If the timidity/mt-32 emulator becomes an ALSA sequencer
> > client (which is the optimal situation so it can be used
> > in any ALSA application), how would dosemu/midid support
> > it?
> No modifications at all. See sound-usage.txt
> about how to use dosemu->ALSA->timidity. This
> is quite fundamental and doesn't require midid.
> But to keep the midid up-to-date, probably some
> small modification to the midid's timidity
> frontend will be required, as currently it
> assumes that only GM is supported. That is for
> the OSS users, as ALSA users doesn't need midid
> at all.

I see that now.  Very nice.  I wonder if there is an easier way to set
the MIDI up than making the user manually connect pipes with MIDI
devices.  Perhaps dosemu could use a launcher program of some sort?

> >Interesting.  What about making the ALSA sequencer a 
> >backend for midid?
> No, actually there is an overlap of a functionality.
> midid is also a kind of a sequencer. It receives the
> same data on input the alsa sequencer receives. It
> can't work after/before the ALSA sequencer because
> they are doing the similar job. Only the output is
> different: midid talks to timidity's server interface,
> while alsa talks to timidity's alsaseq interface.

Hmm, so what's the best way to use a OPL3-emulated sequencer from
dosemu?  If I make it an ALSA client, people using midid will not be
able to use it.  If I make it a server application that midid talks to,
it is less flexible for the people who could use it through ALSA
applications.

I could do both but that takes a lot of time. :)

> >So under longmode there will be no more vm86() and we 
> >will definitely need to use QEMU.
> Unless someone will finally implement it, which
> is unlikely but not impossible: after all also X vesa
> driver uses it, and so does wine, so there might be
> some motivation after all...

What does wine use it for?  I think XFree86 uses it for Int10 support
too.

> >So the "compatibility mode" is only good for running the 
> >32-bit applications while in longmode. Correct?
> No: 16 bit is also OK.

But not 16-bit realmode applications or 32-bit ring0 applications
either?

> >I think most people will be using longmode on AMD-64 
> >anyhow, so we should get the fast CPU emulation going as 
> >soon as possible.
> The speed is not a problem on that CPUs I
> guess. The problem is to make a relatively bug-free
> CPU emulator. Lets see if the qemu people can do
> that, otherwise qemu will add bugs to dosemu, while
> dosemu has plenty of its ows ones:)

:)

> >Side effect of the CPU emulation : can we do things with
> >it like run Win95 or other VCPI program underneath
> >DOSEMU?
> I think it will be possible. Right now qemu can
> run Linux kernel itself, so running
> linux->dosemu->qemu->win95 might also be possible.

Those VCPI-games should be taken care of like that too, Privateer,
Strike Commander et.al.

-- 
Ryan Underwood, <nemesis at icequake.net>, icq=10317253