On Tue, Mar 08, 2005 at 04:01:49PM +0300, Stas Sergeev wrote: > Hello. > > Ryan Underwood wrote: > >Problem right now is that JACK only supports ALSA as a > That depends on how much we beleive > into it. The faq says: > --- > a JACK backend to PortAudio > is under construction that would allow PortAudio apps to connect to JACK > ports. > --- > Can we trust that? No idea.
That's the wrong thing. That means PortAudio can output to JACK. That still has JACK needing ALSA to the backend - meaning the users without a 2.4+ALSA or a 2.6 kernel are out. Now, we could develop a new SB layer concurrent to the old one. The new one could use JACK or PortAudio or whatever. The old one would still always exist but be disabled by default when the new one is better. > callback happens? VDMSound uses the > on-fly DMA speed adjusting, which is > what we probably have to do as well, > and that doesn't work with the callback > model as far as I can tell. This is a > big problem. Yeah, that is a big problem because everyone is using a callback model these days - JACK, PortAudio, even ALSA has an optional callback model. > >First, dmix > >will be a default plughw device configuration, so users will not have > >problems with this. > That's not directly related to our > problems, but dmix is capable to mix > only two streams of the same rate. > 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 i.e. 5 streams mixed with dmix. However, I don't know what mixing rates it supports on input. I know it requires 48KHz output to the soundcard. That is a problem for older cards. > It doesn't support 8bit > streams. If you want to use it with the > streams of a different rate, you'll likely > to have to route them via "plug" first, > but then there is no way to mmap the > card's buffer, and there are latencies > too. And you can't connect dmix to something > else than the "hw". etc etc. Well, the > 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. > >Also, ALSA semantics should be changed to return > >-EBUSY instead of blocking when a sound device is opened > Isn't it what's the O_NONBLOCK for? Here is Takashis' reply to a Linus rant: http://sourceforge.net/mailarchive/message.php?msg_id=10012702 There is disagreement, but most kernel developers who responded thought that O_NONBLOCK to avoid hanging the app was silly. If the app wanted to wait for the sound device to become available, it makes more sense to loop until not errno==EBUSY. > >Additional problem of using JACK is that it doesn't work with dmix, so > >it would block the card on a device which only supports one stream. > Do you mean it opens the "hw" instead > of the "default" output? That may be > for reason - if JACK does any mixing > itself (does it?), it might be doing > it better than dmix. Just a wild guess. Yes. Progs which use 'hw' directly can't be supported by dmix, and even worse, prevent any other dmix-supporting progs from using it. > >>is full. Some DOS progs controls the > >>DMA registers during the sound output, > >>and that's why we have to guarantee the > >>smooth transfer and the accurate timing > >>ourself. > >Does this imply we must mmap the sound buffer? > No, that means exactly the opposite. > mmapping the buffer is a dead end. Ok, so what you mean is that we must have precise, low latency control over what is written to the buffer. I guess that also means the buffers should be as small as possible without causing problems. > and even then you don't know what > you have mmapped, as the DMA organisation > can be different on the different cards. Right. For example, quake3 has this problems. > >idea that e.g. VESA, DPMI, WfW support > >would become so good. > No-no, VGA/VESA emulation state internally > is not much better than the one of the sound. vgaemu may not be very fast, but the VESA support seems to work very well for me. BTW, would OpenGL support be better for vgaemu? It seems that on the SDL mailing list, OpenGL is suggested in all cases for 2D operations for performance reasons. > FreeDOS is still not good for running > windows, which is bad also for dosemu. It's true. I've been preparing a ready-to-run DR-DOS image based on the Caldera hdimages of 7.03, but I'm not sure if it is okay to redistribute it with the SCO problems. > >SB support is the worst part about trying > >play any games with dosemu. > But I thought it pretty much works. It does, but with pops and clicks depending on the soundcard. The problem might be related to my cards though. (Vortex, CS4232's SBPro) In any case, it's not too fast and sometimes acts strange. > >dosemu has a marketing problem at the > >moment comparing to dosbox and qemu :) > I don't think so. dosbox have the Windows, > Mac and BSD users, as well as the x86_64 > users. Isn't it possible for a BSD port too? Anyway, I see a lot of people trying to run DOS games under Linux with e.g. dosbox and qemu and complaining about the speed => Linux sucks, etc. This is the marketing problem I'm talking about. > are is much appreciated. x86_64 port is > probably more difficult, but can and must > be done. By this you mean using a CPU emulator, in which case it would also be useful on any other Linux arch too. 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. > The problem is that the qemu > author seem like have abandonned the > qemu-user development, and qemu-user no > longer runs dosemu (while it used to do > that very well in the past). I have > actually almost completed the qemu > integration when that happened:( Have you mailed him with that problem? > As for qemu itself - besides being portable, > it also runs any OS, not only the realmode > ones, so it doesn't need any additional > marketing promotions:) Well, we are running protected mode OS too, as long as there is a DPMI interface and we can find it. The LDT emulation was the only other problem, wasn't it? > As soon as dosemu is ported to windows > (can be done immediately by any coLinux > user), I think this is a great idea and didn't even realize it was possible without resorting to emulation. > and as soon as the x86_64's new virtualization > technology is adopted (with which it will > probably able to also run any OS), Do you have information on this? I didn't know there was any special virtualization capability of x86-64. Is it available in 32-bit mode on those chips? > That was the time when it was abandonned > by users, distributors and developers. > So all the marketing problems are well > deserved. Now some respect to the project > was re-gained, but to really move forward > it must be much more work than just a > marketing. Fortunately you have been around for the meantime. I try to fix bugs and add little features here and there but I have no capability to make architectural decisions. > >Also, there are many > >FreeDOS bugs that get blamed on dosemu > Fortunately dosemu can be used without > FreeDOS. FreeDOS is not even capable of > running Windows. Yes, see above comment re: DR-DOS. If this can be redistributed, then users can be expected to test the prog there before submitting a bug report. > >DOSEMU has so many features that nobody even realizes. > Surely - who cares about DOS these days? :) > The real things can be done if we get > use of the new Intel's or AMD's > virtualization technologies, but till > that time all the features you listed, > are only for DOS. Of course. But that happens to be the entire legacy of PC development that predates WINE. DOS is very important to close this gap. > But what's the use to compete with vmware anyway:) Have you bought VMWare? I haven't. It costs money. And we are very close to its functionality for free, for DOS/Win3.11 purposes. In fact, we are just short of Win4Lin's previous versions. That's a really good accomplishment for a project which was left for dead a few years ago. > And who knows when the legacy support will be completely dropped from > the CPUs. It already has, at least in 64-bit mode. Good thing most people won't bother with 64-bit mode on desktop machines for a while. They can't do that until nobody is running Win9X anymore anyway. > >I can use > >external hardware with no slowdown, > >even interrupt driven! > It would be nice if you re-test that > ability with the current CVS code and > make sure it was not broken by some > recent draconian changes. Sure. > >This problem of perception is why I > >would like to start a wiki like we > You are welcome to do so - documentation > is really a weakest part of dosemu now. Yes, I agree. But can it be placed on the sourceforge site? > Doing more of a promoting also raises > the expectations. The inability to > satisfy these expectation will only > make the things worse. But without users, we can't even know what works and what doesn't work, and what people are trying to do, i.e. where to place requirements for the next version. So there is an argument for both. -- 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
