headers
Jamie Wilkinson | 1 Feb 2004 15:20

memory allocation in snd_alsa.c

I wrote a libao output driver last night, and was looking at snd_alsa
for clues, but noticed that despite dma.buffer being pointed to buffer,
neither of them were actually getting allocated.  I then looked at
snd_arts.c, which it looks like snd_alsa.c was derived from, and that
actually does malloc some space for buffer.  There's also a free in
SNDDMA_Shutdown which will probably crash.

Does snd_alsa.c actually work?  I haven't tried it but it looks like the
first attempt to fill the buffer will crash.

Also, the buffer size is hardcoded to be dma.samples * 2 big, with the
#define snf_buf at the start.  The snd_linux.c and other OS specific
audio code use dma.samples * dma.samplebits / 8 for the size of the
buffer, as they can take 8 or 16 bit samples.  Just pointing that out in
case someone wanted to use 24 or 32 bit samples in the future.

--

-- 
finger jaq <at> gozer.quakeforge.net                 http://www.quakeforge.net/
Permalink | Reply | 1 comment |
headers
Brendan Burns | 2 Feb 2004 16:40
Picon

Re: memory allocation in snd_alsa.c

Hmm, snd_alsa works for me, but I've had crash reports too, that's 
probably the reason... I'll look into that tonight and fix it...

thanks!

--brendan

On Sunday, February 1, 2004, at 09:20 AM, Jamie Wilkinson wrote:

> I wrote a libao output driver last night, and was looking at snd_alsa
> for clues, but noticed that despite dma.buffer being pointed to buffer,
> neither of them were actually getting allocated.  I then looked at
> snd_arts.c, which it looks like snd_alsa.c was derived from, and that
> actually does malloc some space for buffer.  There's also a free in
> SNDDMA_Shutdown which will probably crash.
>
> Does snd_alsa.c actually work?  I haven't tried it but it looks like 
> the
> first attempt to fill the buffer will crash.
>
> Also, the buffer size is hardcoded to be dma.samples * 2 big, with the
> #define snf_buf at the start.  The snd_linux.c and other OS specific
> audio code use dma.samples * dma.samplebits / 8 for the size of the
> buffer, as they can take 8 or 16 bit samples.  Just pointing that out 
> in
> case someone wanted to use 24 or 32 bit samples in the future.
>
> -- 
> finger jaq <at> gozer.quakeforge.net                 
> http://www.quakeforge.net/
(Continue reading)

Permalink | Reply | 0 comments |
headers
Stuart Matheson | 16 Feb 2004 01:57
Picon
Picon
Favicon

ati fglrx not being used

Hi, I've compiled the quake2-0.15 source, an when I run:

> ./quake2 +set vid_ref glx +set gl_driver /usr/lib/libGL.so

The performance is terrible on my radeon 9600, and I notice that the gl
renderer reported by quake2 is 'GL Mesa Indirect' .
But I've installed the ati fglrx module and my glx setup works
otherwise,

> glxinfo | grep renderer
OpenGL renderer string: RADEON 9600 x86/MMX/3DNow!/SSE

I suppose I'm compiling something the wrong way.. I modified the
Makefile build options so that only BUILD_X11 and BUILD_GLX are set to
yes.

Any help making quake2 use my radeon would be great.

Stu
Permalink | Reply | 0 comments |
headers
Florent Parent | 16 Feb 2004 04:55
Favicon

Re: IPv6


Runs on FreeBSD and Linux (from the cvs sources). I also have it IPv6 
enabled running on NetBSD (but no sound) and WinXP (would this be a useful 
addition to the cvs repository?)

Check the README file on how to enable binding on a link-local multicast 
address (useful to discover local server).

Drop me a message if you find any problem.

Florent

--On Tuesday, January 27, 2004 18:07:17 +0000 Nelson Marques 
<nmarques <at> netvisao.pt> wrote:

> How's the IPv6 networking code ? Its for real, or just some comented
> options in the Makefile ?
>
> nelson
>
Permalink | Reply | 2 comments |

Gmane