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