Re: sound support

Re: sound support

[Stas Sergeev]

Hello.

Ryan Underwood wrote:
> Yeah, that is a big problem because
> everyone is using a callback model
> these days
I am not sure we can't try to use the
callback model, it may just be inefficient.
That also depends on how's the server
reacts on the partially satisfied
request (i.e. it asked for XXX bytes,
but we only give it a half of the size
or so). If the server have no problem
with that, we might still be able to
calculate how we have to speed the DMA
up or down.

>> 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? The "it just
sums the values...", or the "I don't
know how..." statement?
Or do you think just summing the values
will produce the good results for many
streams? Here's the quote:
---
The resolution for 32-bit mixing is only 24-bit. The low significant
byte is filled with zeros. The extra 8 bits are used for the saturation.
---
For the 16bit streams there might be
all the 16bits for saturation, but
with more than 2 streams the losses
are unavoidable, and consider that the
physical output is usually only 16bit,
not 32.

>> 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.

>> Isn't it what's the O_NONBLOCK for?
> Here is Takashis' reply to a Linus rant:
Wow, amazing! O_NONBLOCK is not for that,
now I see. I wasn't aware such a seemingly
obvious things of the standard can sound
so different when Linus explains it:)

> 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.
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). And
---
If you actually think this is a useful
feature, I would suggest trying to 
key it off O_EXCL or a new flag.
---
Actually reading that discussion was
both informative and fun. Yes, I find
it funny to see how easily Linus beats
his opponents even on the things that
initially look obviously not on his
side, and how easily he proves what
initially looks obviously wrong. That's
something;)

> Ok, so what you mean is that we must
> have precise, low latency control
> over what is written to the buffer.
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
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.
It is probably more difficult to implement
with callbacks, but it may be possible.
The DOS program must see the DMA to
advance smoothly, but we can still do
some buffering on an SB side.
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.

> 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.

> 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.

>> 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
For realmode only. Not a big deal.
We could even use simx86, but unfortunately
it broke.

> 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.

>> qemu-user development, and qemu-user no
>> longer runs dosemu (while it used to do
> Have you mailed him with that problem?
Yes, long ago. He said he isn't going to
invest any more time in the qemu-user
development.

> 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. Then there was a DPMI committee,
but I don't think any other OS have ever
used that API.

> The LDT emulation was the only other
> problem, wasn't it?
For Win31? Sure. (plus tons of the
DPMI and extender improvements)

> Do you have information on this?  I didn't
> know there was any special
> virtualization capability of x86-64.
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/

Re: sound support

[Ryan Underwood]

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, <nemesis@icequake.net>

Re: sound support

[Stas Sergeev]

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.

>> to be able to run the windows kernel in
>> protected mode without too much of a
>> redesign.
> Why didn't they just used VCPI?
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.