Hello.
Ryan Underwood wrote:
>>limited. Well, not our problems at all.I mean, tell ALSA developers why dmix is useless for this application and suggest how it can be improved.
No-no, there is nothing with that particular application (dosemu), as soon as we are going to use the sound server, not an ALSA directly. My comments on dmix are unrelated to dosemu. It is just that I had problems with it. I have the pc-speaker, it does 5-6bit output only. And dmix doesn't support 8bit streams, so I have to mix the 16bit streams and add the code to the driver to convert it back to 8bit. With that configuration even 2 streams are not practicle, i.e. I can't use dmix at all. Another problem I had is that it is not possible to connect dmix to any plugin other then hw. On a generic hardware its limitation may not be too noticeable (unless you mix a lot of streams so that the saturation makes the problems), but for the small things like the pc-speaker it was a disaster.
OK, I understand this. JACK does have a callback for when the sample rate changes, so it would get that information.
No, it is not that. It is that the rate of the output device and the rate of the dosemu DMA are driven by the different time sources, which means they may sometimes get out of sync (dosemu timing is not perfect anyway). So when the buffers are getting low, we have to find that out and speed up our transfer a bit. If we are doing writes ourselves, before every write we could query the buffer and see if it is low or not. But with the callback model it is assumed that we can provide the necessary amount of data at any time. Server may want to fill up its buffers at one point, and so it may call us up to provide the amount of data we don't have yet. Server is driving, not we. So with the callback model, implementing our own rate control is difficult.
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?
It does. Consider we are doing the 44100Hz output. With the scheduler frequency of 1Khz, we'll have to transfer roughly 44 bytes per the timeslice. This is already too much - the DOS prog will see the jumps of the DMA registers by the value of 44, while under the real hardware it can see the transfer of every single byte. But the dosemu clocks are set to 100Hz for SIGALRM, so with that rate we'll have to do the transfer of 440bytes per burst, which is not much better than what we have now. Increasing the rate of the SIGALRM is really ineffective and will cause the slowdown. And also the dosemu main thread can sleep, which will cause underruns. So moving the SB to another thread makes sense, as far as I can see.
I think FreeBSD removed their v86 syscall now.
How can they run the VESA XFree server then? With emulator?
What about x86emu from X.Org?
Might be something to take a look into, but I think it is not as fast as qemu.
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, when the simx86 was functional, dosemu powered by it, was still way faster than the dosbox is. I don't know what the problems the dosbox have with the performance, but there might be few:) Well, dosbox didn't have the dynamic translator back then, and the simx86 no longer exist, so the fair comparision is not possible, but for the real mode simx86 was really very usable, actually it was even fast, and that is on my ancient 700MHz CPU.
Why didn't they just used VCPI?to be able to run the windows kernel in protected mode without too much of a redesign.
They could use VCPI for their ring0 startup code (which is the DPMI server itself), though they opted to implement another quick hack called GEMMIS. Thats probably because the VCPI was too 386-oriented (paging), while they needed the stuff to work also on 286. For the ring3 code they needed another protocol, the one that will allow to run the old winkernel and the DOS programs concurrently. That became a DPMI. And to not rewrite the winkernel to be a DPMI client, they built the DOS extender into their DPMI server, but never documented that fact.
- 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
