From: Stas Sergeev <stssppnn@yahoo.com>
To: linux-msdos@vger.kernel.org
Subject: Re: Sound report
Date: Mon, 27 Jan 2003 00:16:01 +0300 [thread overview]
Message-ID: <3E345011.6070605@yahoo.com> (raw)
Hello.
Jochen Reinwand wrote:
>> When software mixing is added to dosemu,
>> the problem is no more.
> Wouldn't it be simplier to add support for arts as output module? This
> should solve the problem in a very compatible way for most users.
Yes, but there are problems with this:
1. This will not solve that problem for
OSS, which is bad: dosemu must work with
OSS too.
2. Not all the sound servers can change
the sampling rate on a fly, so you will
have to close/open session when you want
to change the rate. I don't know about
arts in particular, maybe it have that
ability, but then we are incompatible
with everything else.
So indeed the internal mixing code is
required, and the mixing itself is not
on the first place: what we really need
is a resampling, which will allow dosemu
to change the sampling rate at any time
without a problems.
> This way you can
> for example listen to music via xmms with the arts output plugin while
> using dosemu.
When the internal mixing is added,
writing the output plugin for any
sound server would be a piece of cake:
only output a single stream at a single
rate. Without a mixing code it would be
a headache. Just look at linux_sound.c
to see what a headache it is. linux_sound.c
can be reduced 3-4 times if we have a
mixing code inside, and also a sound.c
can be cleaned up a bit.
> btw: I've tried to use artsdsp to redirect sound to an virtual dsp device
> simulated through arts. Seems like dosemu is very "unfriendly" to the
> dsp device...
Yes, that's why it fails even with some
OSS drivers, and will certainly fail
with any redirectors like esddsp or
artsdsp.
I have already patched the Aureal Vortex
driver to be dosemu-compatible as I was
provided with that card for testings, but
I know some other drivers are also failing.
Have we the internal mixing code, this
hell would be ended. But also threading
is required to solve everything for good.
Then all the DSP redirectors will suddenly
start working. Currently I think they
don't like a non-blocking I/O.
next reply other threads:[~2003-01-26 21:16 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-01-26 21:16 Stas Sergeev [this message]
-- strict thread matches above, loose matches on Subject: below --
2003-01-25 0:23 Sound report Stas Sergeev
2003-01-26 16:12 ` Jochen Reinwand
2003-01-22 20:56 Stas Sergeev
2003-01-23 7:12 ` Paul Eggleton
2003-01-24 19:54 ` Jan Willem Stumpel
2003-01-24 20:31 ` Bart Oldeman
2002-12-24 20:40 fmorgan Stas Sergeev
2003-01-22 20:27 ` Sound report Jan Willem Stumpel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3E345011.6070605@yahoo.com \
--to=stssppnn@yahoo.com \
--cc=linux-msdos@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox