On Wed, Mar 09, 2005 at 10:31:17PM +0300, Stas Sergeev wrote: > > >>It just sums the values of the streams. > >>I don't know how good it mixes more than > >>2 streams. > >I know this is false because I have played > What exactly of the above, on your > opinion, is false, btw?
Not that quote, this one: > That's not directly related to our > problems, but dmix is capable to mix > only two streams of the same rate. I have played 5 streams of the same rate mixed through dmix. I may have misread that though - are you saying that dmix cannot resample the input streams? > >>way dmix is implemented, its use is very > >>limited. Well, not our problems at all. > >It might be a good question for the ALSA list. > It is not a question, this all is > even documented. I mean, tell ALSA developers why dmix is useless for this application and suggest how it can be improved. They are usually quite receptive to a suggestion if it would make the architecture better overall. > I don't think they (Linus mainly) offer > such a silly thing. His point it that the > synchronization on the sound device is > silly and must not be done (no sane > program should lock up and wait for the > device to free, as this may take from > seconds to years). Right, this is the main problem. Using O_EXCL makes a lot more sense in the case that you *do* want to hang, as opposed to making a hang to be the default behavior. > No, what I mean is that we have to try > to advance the emulated DMA with the > constant speed. That means we shouldn't > do the callbacks to it and request the > data from it to fill the buffer. Instead > we'll have to do the buffering on an SB > side (SB have the FIFO actually), and I think I see the problem here. So in a callback, we would only be able to play with the data in between the old DMA pointer and the new DMA pointer. > SB needs to have the information to be > able to adjust the speed of the emulated > DMA to match the speed of the real output. OK, I understand this. JACK does have a callback for when the sample rate changes, so it would get that information. > The good thing is that the current DMA > implementation will work, it is only > the SB layer that will require some > work. Of course the most frightening > part is to put the stuff into a separate > thread. Yes, but for SB this doesn't really make sense, does it? We are really just moving data around, not doing any real compute heavy emulation like the problem with OPL2. So running it sequentially doesn't seem to be a big deal. Now with mixing (e.g. with adlibemu output) and resampling inside dosemu, that might become a problem. > >Isn't it possible for a BSD port too? > It might be (it was done in the past), > but it may be feature-less and difficult > to maintain. Linux kernel have a lot of > dosemu-related patches in it, dated from > the beginning of the project to nowadays. > And I personally (which may be totally > wrong) don't see a lot of demand for that. > Linux is always the primary "market", > but perhaps the windows port will have > some market too. Not sure, but it worth > to try imo. Yeah, Windows would definitely be a useful goal in the near future. In fact, I think FreeBSD removed their v86 syscall now. > >dosbox and qemu and > >complaining about the speed > Is qemu still slow, even with its new > proprietary virtualization technology > (or whatever that kqemu is)? From what > I've heard (not too much), it may be > faster than dosemu. I've not tried it. > >By this you mean using a CPU emulator > For realmode only. Not a big deal. > We could even use simx86, but unfortunately > it broke. What about x86emu from X.Org? > >In this case we are losing the > >speed of native CPU, native IO, VESA > >console (vs vgaemu). I'm not sure > >how it would turn out. > On 64bit machines? It might be very fast. > Emulating realmode code is not a big > deal *at all*. And even the protected > mode user-space code is not much of a > slowdown when translation is used, I > beleive. The real problem is with the > ring0/system code, which we always can > avoid to execute. I don't know - so many people complaing about the speed of DosBox even on 2GHz machines. I don't know if it is with real-mode or p-mode code though. > >Well, we are running protected mode OS too, > >as long as there is a DPMI > >interface and we can find it. > :))) Guess where's the DPMI come from? > It was developed by MS as a quick hack > to be able to run the windows kernel in > protected mode without too much of a > redesign. Why didn't they just used VCPI? > Nothing except for the some announcements: > http://www.extremetech.com/article2/0,1558,1644513,00.asp > And for Intel: > http://www.intel.com/technology/computing/vptech/ Interesting, thanks for the links. -- Ryan Underwood, <[EMAIL PROTECTED]> - 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
