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.
What about PortAudio? It uses the callback based model like JACK but with many more back-ends besides ALSA. From a quick glance to the PortAudio
docs (which are in a chaos, as far as I can tell), it is not an abstraction layer, but rather an I/O library that provides an access to the different sound systems, and that access is not unified. This is probably not the level we have to use directly. JACK can get use of it instead. Also, a callback-based model, I hate to say that, but looks like not the best choise for us:( That may be fine for Adlib, but for DMA sound this is a problem. As I said already, we have to do the smooth DMA transfers. Callback API is chunk-oriented by design, which is not good. We can accumulate the data on an SB side and feed it to the callback routine, but even then we won't have enough info to control the DMA speed. I.e. how do we know when the next callback is to happen, and is the current speed enough to supply the necessary amount of data when the 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.
There is the problem still of cards which do not support hardware mixing.
That must be the headache for the mixing layer, not ours.
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. 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.
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?
problem I don't know enough about is what control over the audio stream we get when dmix is in use.
Unless we use ALSA directly, not our problem at all.
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.
Does this imply we must mmap the sound buffer?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.
No, that means exactly the opposite. mmapping the buffer is a dead end. We will then have to do the mixing and resampling ourselves, and we'll not allow the other apps to use the card with us, unless there is a hw mixing I guess, and you can't mmap unless you use the ALSA/OSS directly, and even then you don't know what you have mmapped, as the DMA organisation can be different on the different cards. And when the things like plug/dmix are in use, I don't know what you'll mmap in fact. No, we aint gonna mmap the cards buffers. That was used by the direct-SB patch: http://www.geocities.com/SiliconValley/Circuit/5426/dosemu.html something we don't want to have.
Yes, this is completely stupid.code waits for the OSS buffer to became empty, resets the sound card, sets the new parameters, and resumes the transfer.
thanks... :)
Well, this may have been sufficient at the time, since we had not even
Yes, exactly. That was quite sufficint because it was a vast improvement over the existing code, but it turned out to be not future-proof. That's why the new startups are achieving most of the dosemu functionality within a *much* smaller time-frame - they are not bound to the ancient code and they do not have to re-evaluate all those ancient ideas behind that code etc.
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. Even the Windows VESA drivers that Japheth wrote for us, are still not adopted. DPMI state is now rather good indeed, but that took years of (very slow) work. WfW support is also not bad - that's because finally we have the Windows expert who made this possible. But there are still no Windows experts on a FreeDOS side, so FreeDOS is still not good for running windows, which is bad also for dosemu.
SB support is the worst part about trying play any games with dosemu.
But I thought it pretty much works.
Well, it would help if we had more than two developers...
There are also people who help in a specific areas, like windows support.
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. dosemu can be ported to Windows by using coLinux, its a low-hanging fruit actually, but noone of the dosemu developers seem to be using Windows... Help in that are is much appreciated. x86_64 port is probably more difficult, but can and must be done. 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:( 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:) As soon as dosemu is ported to windows (can be done immediately by any coLinux user), as soon as it ported to x86_64, and as soon as the x86_64's new virtualization technology is adopted (with which it will probably able to also run any OS), there will be no marketing problem at all.
I think there is the illusion that it is only good for running business programs. Until 1.2, that was somewhat true.
Until 1.2 the project was dead. This was almost official, http://www.dosemu.org/alberto --- since the development of dosemu stopped... --- 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.
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.
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. But what's the use to compete with vmware anyway:) And who knows when the legacy support will be completely dropped from the CPUs.
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.
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.
It would at the same time be a support area and a marketing area, because other people would be able to see all the apps that work no problem and realize that dosemu is actually useful.
Yes, marketing is important, but with such a limited development power the project have now, it may make no sense. I.e. I think the current "marketing state" is adequate with the power we have. Doing more of a promoting also raises the expectations. The inability to satisfy these expectation will only make the things worse.
- 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
