Re: Linux sound

[Mads Bondo Dydensborg <madsdyd@challenge.dk>]

On Wed, 16 Jun 1999, Pierre Phaneuf wrote:

> Yes, but most system still are with glibc 2.0.x... At least, going from
> glibc 2.0 to 2.1 is much easier than switching from libc5 to glibc2, so
> this should be a lot quicker to come...

Yes. Anyway, the only real problem I have had, is when shutting down the
application under glibc 2.0. And I have hacked my way around it, by
letting the process kill it self. (Now, there is an ugly hack :-)

> Yes, of course, it depends on the game. If you are writing a Minesweeper
> kind of game, just lay back, relax and forget about it... :-)

Actually it is a 2 player minesweep kind of game. (I am porting it though
- and adding sound in the proces :-)

> 
> But if you're writing a Quake kind of game, this is becoming very
> interesting details...

Yes.

> 
> Quadra isn't exactly as hard on the machine as Quake is, but it isn't
[..]
> 
> And we plan to use our library for future games which should push the
> envelope a lot more than that!

Good design is essential then.

> > > We have two of them, at 8192 bytes each. We run the sound device at full
> > > resolution, 44.1kHz, 16 bit samples, stereo, which goes for about 47
> > > milliseconds of sound. We have a 10 millisecond timebase, so on
> > > reasonable hardware, it makes sense. Mixing for too much ahead get you
> > > lagged...
> > 
> > Yes. I mix approx 3 * 22 ms ahead, but mostly I am only approx. 2 * 22 ms
> > ahead.
> 
> How many bits per sample and channels do you use?

I use 8 bit unsigned sound, 1 channel. (3 buffers, 512 bytes). 11025 Hz.
This is good enough for my purpose.

> 
> > > What's your experience with the SBlive? We have one nearby, but couldn't
> > > try the Linux version of our game with it...
> > 
> > When I tried to allocate 3 buffers of 512 bytes each, it would only give
> > me 1 buffer of 512 bytes. When I tried to play to this, the sound was
> > lagging way behind. I have written creative labs about this, but has yet
> > to hear from them.
> 
> I see... Have you tried asking only for two buffers?

No. (More below)

> 
> BTW, did you try Quadra on this SBlive? We'd be interested in knowing
> how the sound is on that card (if it is acting a bit weird)...

I havent tried, because the SBLive is actually not in my machine, but in
the machine owned by the person that asked me to port the game. He lives
in another part of the country and has no programming experience (he did
the graphics for the game) and limited linux experience.

So, I haven't actually experienced the lag myself, I have to trust what he
is telling me. At the moment however, he is very busy taking exams - and
his internet connection is very limited. So, it is rather limited how much
testing I can get to do with that particular SBLive.

> 
> And anyway, you also have to try Quadra just for the sheer value of it!
> ;-)

I will :-)

> > What difference should it make, if you set it to async? (I probably should
> > be able to figure this out myself, but it kinda confuses me.)
> 
> Well, when you write to a file descriptor that has enough buffers to do
> your write and that it has the O_NODELAY flag, it returns very quickly.
> If there is no free buffers, it acts normally. But I think this could be
> the behavior of /dev/dsp when no O_NODELAY flag is applied. :-)

>From my reading, I would guess that /dev/dsp acts like O_NODELAY in normal
operation.

Mads

-- 
Mads Bondo Dydensborg.                               madsdyd@challenge.dk
Estimates of online gamers in the United States alone run as high as 15 to
20 million people. 
                                      - Jon Katz, Slashdot, on youth culture.