sound support (Re: XMS problem with Aladdin demo)
Hello.
Quoted 1 line · Ryan Underwood
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.
Quoted 3 lines
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.
Quoted 2 lines
There is the problem still of cards
which do not support hardware mixing.
That must be the headache for the mixing layer, not ours.
Quoted 3 lines
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.
Quoted 2 lines
Also, ALSA semantics should be changed to return
-EBUSYinstead of blocking when a sound device is opened
Isn't it what's the O_NONBLOCK for?
Quoted 3 lines
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.
Quoted 2 lines
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.
Quoted 6 lines
Quoted 5 lines
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. 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.
Quoted 4 lines
Quoted 3 lines
code waits for the OSS buffer to became empty, resets the sound card, sets the new parameters, and resumes the transfer.
Yes, this is completely stupid.
thanks... :)
Quoted 2 lines
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.
Quoted 2 lines
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.
Quoted 2 lines
SB support is the worst part about trying
play any games with dosemu.
But I thought it pretty much works.
Quoted 1 line
Well, it would help if we had more than two developers...
There are also people who help in a specific areas, like windows support.
Quoted 2 lines
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.
Quoted 3 lines
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.
Quoted 2 lines
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.
Quoted 1 line
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.
Quoted 3 lines
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.
Quoted 2 lines
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.
Quoted 4 lines
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.
Stas Sergeev schreef:
Quoted 8 lines
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.
This patch seems pretty neat. Is there any chance that at least OPL3 support could be added in such a way to Dosemu?
I think people that do not have an OPL3 chip would want to have the emulation of it outside Dosemu anyway since there are also several other programs that could use an OPL3 chip. For people with OPL3 hardware, their hardware would automaticly used; for others the OPL3 would be emulated so that for Dosemu, FreeSCI, ScummVM, Linux Doom, etc. it would be the same as having a real OPL3 chip.
Thanks,
Julius
Quoted 2 lines · Julius Schwartzenberg
This patch seems pretty neat. Is there any chance that at least OPL3 support could be added in such a way to Dosemu?
Yes, in fact I had a tree where I was working on this but it died when my laptop hd crashed. It involves a thin layer libopl that uses hardware when it is available, and invokes the LGPL-licensed emulator from AdPlug when not available. libopl was intended to be used in all these other projects also which are currently using OPL emulator.
I have rewritten libopl, but it requires a patch to OSS/Free and ALSA's DMFM interface to work without superuser privilege. I have to reintegrate it with dosemu, then I'll send the whole patch. Unfortunately, OSS commercial people will be out of luck for this, since they will not change their API at request of users.
A change which was made recently is that dosemu became compatible with pthreads. Now I can make the libopl emulator mode threaded so it can run concurrently with dosemu. This should greatly improve the emulation quality from Stas's original patch, instead of having to wait for the sound system to be run from dosemu's main loops.
Quoted 6 lines
I think people that do not have an OPL3 chip would want to have the emulation of it outside Dosemu anyway since there are also several other programs that could use an OPL3 chip.
For people with OPL3 hardware, their hardware would automaticly used; for others the OPL3 would be emulated so that for Dosemu, FreeSCI, ScummVM, Linux Doom, etc. it would be the same as having a real OPL3 chip.
I thought about this for a long time already and have already begun with a SDL-based synthesizer daemon. For example, this could be connected to alsaseq in the same way that timidity's ALSA daemon mode, to play MIDI files where only OPL hardware exists. Furthermore, for those machines without OPL or hardware MIDI, OPL is far cheaper to emulate. However, for the short term (read: the time I have), libopl approach is good enough.
Signature · 1 line
Ryan Underwood, <[email protected]>
Quoted 6 lines · Ryan Underwood
A change which was made recently is that dosemu became compatible with pthreads. Now I can make the libopl emulator mode threaded so it can run concurrently with dosemu. This should greatly improve the emulation quality from Stas's original patch, instead of having to wait for the sound system to be run from dosemu's main loops.
Stas, along these lines I had a question. What would be the best way to do the mixing of the adlib thread with the main SB output with the current code?
Signature · 1 line
Ryan Underwood, <[email protected]>
Hello,
Quoted 5 lines
Quoted 4 lines
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.
Quoted 9 lines
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.
You are right.
However, a liitle bit more -compared to now-"marketing" would be very usefull. As such "marketing" I would see a list of applications which has been tested and works and also show these one which are problematic.
If I remember right, Ryan has a plan to realize such list.
It would bring new attention to the dosemu project.
Best regards
Bernhard Bialas
Quoted 4 lines · Stas Sergeev
Hello.
Quoted 1 line · Ryan Underwood
Problem right now is that JACK only supports ALSA as a
Quoted 8 lines
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.
Quoted 6 lines
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.
Quoted 9 lines
Quoted 3 lines
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.
Quoted 10 lines
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.
Quoted 3 lines
Quoted 2 lines
Also, ALSA semantics should be changed to return
-EBUSYinstead of blocking when a sound device is openedIsn't it what's the
O_NONBLOCKfor?
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.
Quoted 7 lines
Quoted 2 lines
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.
Quoted 8 lines
Quoted 6 lines
Quoted 5 lines
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.
Quoted 3 lines
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.
Quoted 4 lines
Quoted 2 lines
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.
Quoted 2 lines
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.
Quoted 3 lines
Quoted 2 lines
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.
Quoted 5 lines
Quoted 2 lines
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_64users.
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.
Quoted 3 lines
are is much appreciated.
x86_64port 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.
Quoted 7 lines
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?
Quoted 4 lines
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?
Quoted 3 lines
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.
Quoted 3 lines
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?
Quoted 7 lines
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.
Quoted 5 lines
Quoted 2 lines
Also, there are many
FreeDOS bugs that get blamed on dosemuFortunately 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.
Quoted 7 lines
Quoted 1 line
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.
Quoted 1 line
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.
Quoted 2 lines
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.
Quoted 7 lines
Quoted 3 lines
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.
Quoted 4 lines
Quoted 2 lines
This problem of perception is why I
would like to start a wiki like weYou 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?
Quoted 4 lines
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.
Signature · 1 line
Ryan Underwood, <[email protected]>
Quoted 3 lines · Ryan Underwood
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.
I looked at OpenGL some time ago, trying to figure out how dosbox uses it. dosbox only uses it for scaling and from what I gather it only really helps on NVidea cards but not ATI for instance.
If there's no scaling necessary, for instance if you run dosemu fullscreen in X and the resolution matches 1:1, OpenGL won't help at all.
In general, where OpenGL really helps is if you can send objects (textures) to VRAM and manipulate them there. The uploading of the textures is the slow part.
And this is what dosemu does all the time... suppose MITSHM is active and we're on a local box there are three buffers:
1. emulated video memory (e.g. 320x200 2bpp)
2. X pixmap (e.g 640x400, say at 32bpp)
3. real VRAM. Same format (mostly) as 2.
Now most of the X rendering business is to transform 1. to 2. Even if you'd use opengl you'd still need a 1 to 2 step, but one could skip the scaling -- bpp still needs to be transformed.
2. to 3. can be very fast using DMA sometimes even, it depends on a lot on the X server and the graphics card.
So personally I see OpenGL as quite a bit of work for very little gain ... and it doesn't help I use an ATI card myself.
Quoted 3 lines
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.
There have been mirrors of it... But in general it won't work. It's non-commercial use only, binary only, SF would never allow it.
A long time ago (James MacLean era) DOSEMU tried to work out something with the then owners of DRDOS but it really didn't work out (long story).
The only way to work around FreeDOS issues is to fix them. So this is is what I did for quite some time.
Quoted 4 lines
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.
You just need a developer interested in a BSD port. There hasn't been one for the last 8 years or so.
Quoted 3 lines
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.
All I can say at this point is that by this point dosemu (even 1.2.2) works well enough for me, as compared to what I wanted to contribute when I started participating (just after 1.0.0 was released). In a way that's good, in another way it's bad (for you! not me). Since it removes much of the motivation to work on it.
DOSEMU became more and more of a pet project, and I've slowly realized that I should let it go. Imagine what I can do with all the new time, say
- socialize with local people
- do more about sports, be a healthier person
- if I'm programming do so on projects more relevant to my job
- no more arguments with Stas! Yay! ;-)
Bart