Re: fmorgan

Re: fmorgan

[Stas Sergeev]

Hello.

Jan Willem Stumpel wrote:
>>> Talking Parrot: works somewhat; speed is too low, pitch is too
>>> low, there are gaps in the sound
>> URL where I can get that prog?
> Don't know.. here is what I have.
OK, this program uses a direct DAC
writes rather than a DMA output.
The problem is that the output frequency
is unknown in that case and can vary.
So this cannot be fixed.
The only thing you can do is to adjust
the DIRECT_WRITE_FREQ constant in
linux_sound.h to satisfy the needs of
a particular program (but you will not
get a perfection anyway as the frequency
is not necessary a constant in that mode).
DMA-less output is an extremely absolete
method and fortunately is rarely used with
a DMA-capable cards like SB.

Re: fmorgan

[Jan Willem Stumpel]

Stas Sergeev wrote:
> Hello.
>
> Jan Willem Stumpel wrote:
>
>>>> Talking Parrot: works somewhat; speed is too low, pitch
>>>> is too low, there are gaps in the sound

> The only thing you can do is to adjust the DIRECT_WRITE_FREQ
> constant in linux_sound.h

Worked perfectly, thanks, and M.C. to you!

Regards, Jan

Sound report

[Jan Willem Stumpel]

I applied Stas's opl1a.diff to 1.1.4.6 and I got sound out of SB
fmorgan! The sound is quite horrible (tweaking DIRECT_WRITE_FREQ
in linux_sound.h helps a bit) but this is the first time I have
heard any sound at all from this program in many years. I could
never get it to work in Windows (DOS mode) with my present sound
card. So, great.

I now also get Nazi music out of Wolfenstein 3d. But the sound is
very 'tinny', sounding almost as if it comes from a PC speaker,
and the pitch seems to be too high (must confess I have no musical
ear at all, maybe it just lacks bass sounds). Also, I can get
either music or shooting sounds, but not both.

With Duke 3d I ran the "setup" program, and selected "music card".
 Both "Soundblaster" and "Adlib" did not work. Starting Duke 3d
gives the message

   Sound Blaster not responding on selected port.

So I can get sound effects in Duke 3d, but still no music.

Using kernel 2.4.16 + alsa + Soundblaster PCI 128 (= Ensoniq
1371), 800 MHz Athlon.

Regards, Jan

Re: Sound report

[Stas Sergeev]

Hello.

Jan Willem Stumpel wrote:
> I applied Stas's opl1a.diff to 1.1.4.6 and I got sound out of SB
> fmorgan! The sound is quite horrible
There is a note on my page that the code
is in an alpha stage, so the problem reports
should not be sent. You've just violated
that:)

> (tweaking DIRECT_WRITE_FREQ
> in linux_sound.h helps a bit)
Strange that it makes any differences
at all in that case...

> but this is the first time I have
> heard any sound at all from this program in many years.
Unfortunately this will take many years
for that code to became a part of dosemu
(if at all).
There was a person who is willing to
volunteer for that work, in which case
this have some more chances to be ever
finished. I hope he will get to it soon:)

> Also, I can get
> either music or shooting sounds, but not both.
That means that your card or driver
doesn't support multiple sound channels
(hardware mixing). You have to try SB Live.

> Sound Blaster not responding on selected port.
Yep, the same problem.

> Using kernel 2.4.16 + alsa
I've heard somewhere that the Commercial OSS
drivers have a built-in mixing. If this is
true, use these and you'll get everything
you want (the quality of the sound will
still be miserable as the Adlib code is not
finished - requires threading).

Re: Sound report

[Paul Eggleton]

On Thursday, January 23, 2003 9:56 AM NZST, Stas Sergeev wrote:
> There was a person who is willing to
> volunteer for that work, in which case
> this have some more chances to be ever
> finished. I hope he will get to it soon:)


Don't worry, I haven't forgotten about it. :)

Cheers,
Paul

Re: Sound report

[Jan Willem Stumpel]

Stas Sergeev wrote:
> Hello.
>
> Jan Willem Stumpel wrote:
>
>> [music from Wolf3d works but] Also, I can get either music or
>> shooting sounds, but not both.
>
> That means that your card or driver doesn't support multiple
> sound channels (hardware mixing). You have to try SB Live.
>
>> Sound Blaster not responding on selected port.
>
> Yep, the same problem.

It cannot be a hardware problem only, because in Win98, Wolf3d
produces both shooting sounds *and* good-sounding music on my
card. And it cannot be simply something connected with your patch,
because also in Win98, SB fmorgan produces no sound at all. This
is all pretty confusing.

Regards, Jan

Re: Sound report

[Bart Oldeman]

On Fri, 24 Jan 2003, Jan Willem Stumpel wrote:

> Stas Sergeev wrote:
> > Jan Willem Stumpel wrote:
> >
> >> [music from Wolf3d works but] Also, I can get either music or
> >> shooting sounds, but not both.
> >
> > That means that your card or driver doesn't support multiple
> > sound channels (hardware mixing). You have to try SB Live.
> >
> >> Sound Blaster not responding on selected port.
> >
> > Yep, the same problem.
>
> It cannot be a hardware problem only, because in Win98, Wolf3d
> produces both shooting sounds *and* good-sounding music on my
> card. And it cannot be simply something connected with your patch,
> because also in Win98, SB fmorgan produces no sound at all. This
> is all pretty confusing.

You should not compare DOSEMU to win98, but rather to Windows NT/2K/XP's
handling of DOS programs (with or without VDMSound). Win98 is quite happy
about giving DOS programs direct hardware access and running them using
iopl(3) (in which case also turning off the interrupts really turns them
off, so that cli;hlt halts the machine).

Some direct access *can* be given to DOSEMU, but only if it runs as
(or suid) root. This often involves a bit of "black magic" and it gets
really complicated or impossible once DMA is involved. iopl(3) is a no-no
(I think).

Bart

Re: Sound report

[Stas Sergeev]

Hello.

Jan Willem Stumpel wrote:
>>> Sound Blaster not responding on selected port.
>> Yep, the same problem.
> It cannot be a hardware problem only
It is a hardware problem, which is a
lack of a hardware mixing. /dev/dsp gets
opened for adlib and then fails for
digital sound. Try SB Live and you'll
see its working.
When software mixing is added to dosemu,
the problem is no more.

Re: Sound report

[Jochen Reinwand]

Hi!

On Saturday 25 January 2003 01:23, Stas Sergeev wrote:
> Jan Willem Stumpel wrote:
> >>> Sound Blaster not responding on selected port.
> >>
> >> Yep, the same problem.
> >
> > It cannot be a hardware problem only
>
> It is a hardware problem, which is a
> lack of a hardware mixing. /dev/dsp gets
> opened for adlib and then fails for
> digital sound. Try SB Live and you'll
> see its working.
> 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. This way you can 
for example listen to music via xmms with the arts output plugin while using 
dosemu.

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... It wasn't possible to get it running.

Jochen

Re: Sound report

[Stas Sergeev]

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.