hi,
Has anybody tested/worked SDL with Accelerated X? What were the results?
In your views what are the pros and cons of Accelerated X server with SDL?
Sandra
Sandra wrote:
hi,
Has anybody tested/worked SDL with Accelerated X? What were the results?
In your views what are the pros and cons of Accelerated X server with SDL?Sandra
I’m using Accelerated X ( on a Radeon 9000 Pro ). In my oppion it’s much
faster and more stable than XFree, but there are some things that’s
annoying. For one it has no DGA support, it has a version of DRI ( not
the free one, but the same concept, which works well ). There’s also the
fact that it seems that SDL can’t change the resolution of the screen (
it should be possible though, since the ctrl+alt+[+/-] changes it ),
this could be a since I only got the “gold” version, which doesn’t have
the XVideo extension, the Platinum version has XVideo if I read the
specs correctly though. Accel-X is very stable and I’ve only been able
to crash it once - and I’m quite good at crashing software ;). It also
gives you better options on color correction and a nice setup program (
for both X and console ), so there’s no more editing config files for X.
It’s also very easy to install, all you have to do is install the rpm (
works even though I use gentoo ), and run Xsetup, and it’s working (
I’ve never had such luck after installing XFree ).
If your card is supported by XFree ( with DRI and DGA ) - and it’s
stable on your machine, I don’t think it’s worth the $100. The only
reason I bought it was that I needed the support for my Radeon 9000 pro.
I get about the same OpenGL performance as in windows ( windowed mode ),
but if I run fullscreen in windows it blows Accel-X away. I guess this
is because it hasn’t any DGA support.
/Magnus
Magnus Sj?strand wrote:
Sandra wrote:
hi,
Has anybody tested/worked SDL with Accelerated X? What were the results?
In your views what are the pros and cons of Accelerated X server with
SDL?Sandra
I’m using Accelerated X ( on a Radeon 9000 Pro ). In my oppion it’s much
faster and more stable than XFree, but there are some things that’s
annoying. For one it has no DGA support, it has a version of DRI ( not
the free one, but the same concept, which works well ). There’s also the
fact that it seems that SDL can’t change the resolution of the screen (
it should be possible though, since the ctrl+alt+[+/-] changes it ),
this could be a since I only got the “gold” version, which doesn’t have
the XVideo extension, the Platinum version has XVideo if I read the
specs correctly though. Accel-X is very stable and I’ve only been able
to crash it once - and I’m quite good at crashing software ;). It also
gives you better options on color correction and a nice setup program (
for both X and console ), so there’s no more editing config files for X.
It’s also very easy to install, all you have to do is install the rpm (
works even though I use gentoo ), and run Xsetup, and it’s working (
I’ve never had such luck after installing XFree ).If your card is supported by XFree ( with DRI and DGA ) - and it’s
stable on your machine, I don’t think it’s worth the $100. The only
reason I bought it was that I needed the support for my Radeon 9000 pro.
I get about the same OpenGL performance as in windows ( windowed mode ),
but if I run fullscreen in windows it blows Accel-X away. I guess this
is because it hasn’t any DGA support./Magnus
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
I found this on XiG ( www.xig.com ) about the Accelerated-X server, it
seems it supports something similiar to DGA, called XGA ( XiG Direct
Access Mode ). Then I should be able to grab the entire screen. I’ll see
what I can do, and if I succeed, I’ll send a patch ( if you want it ).
I’m not very good at X programming though ( just a warning ) 
/Magnus
Originally I used a buffer size of 4096. This resulted in evident delays when
playing WAV samples. With 1024 there was still a slight noticable delay. Now
Im using 512 and my delay problems have totally disapeared 
I was wondering
whether a size of 512 is recommended or not???
Cheers
Alan Beltran wrote:
Originally I used a buffer size of 4096. This resulted in evident delays when
playing WAV samples. With 1024 there was still a slight noticable delay. Now
Im using 512 and my delay problems have totally disapeared
whether a size of 512 is recommended or not???
Hi!
I think the answer is a sounding “depends”
I did almost the same as you but the best value for me was 1024. I don’t
know if there’s any kind of formula but for me, worked quite well.
[]s
Adilson.
Alan Beltran wrote:
Originally I used a buffer size of 4096. This resulted in evident
delays when playing WAV samples. With 1024 there was still a slight
noticable delay. Now Im using 512 and my delay problems have
totally disapeared
recommended or not???Hi!
I think the answer is a sounding “depends”
I did almost the same as you but the best value for me was 1024. I
don’t know if there’s any kind of formula but for me, worked quite
well.
Maybe i miss something obvious, but usually, if your samplerate is
44100hz mono, and you use a buffer of n samples, then the max delay
possible is:
(n / 44100)s
This is assuming, that you do not track the position of playback in the
buffer and write just ahead of that. But rather the approach of
starting to output new sound events to the beginning of the next
available buffer. In this case it can take between 0 and n / 44100
seconds till the current buffer is done and the next will be played
back.
Now, a buffer size of 512 bytes is pretty small. 512/44100 = 0,012 secs.
so about 12ms. not bad a latency.
The downside of small buffers is the increased overhead, which is needed
for updating and sending the buffers to the soundcard so fast. So, these
512bytes buffers could be too small for an older machine.
H.t.h.
Florian SchmidtOn Thu, 12 Dec 2002 13:36:42 -0200 Adilson Oliveira wrote:
–
@Florian_Schmidt
http://mistatapas.ath.cx
Actually, I believe the real problem with small buffers is that the
system must be able to trigger the callback more frequently and more
regularly.
For example, if you have a buffer size of 12ms, then you’re depending on
your mixer thread getting CPU every 12ms. Often, it’s not significantly
more expensive to do work in small chunks (eg. copying data from a
static PCM buffer in 12ms chunks instead of 48ms chunks). However, most
schedulers just can’t give you a timeslice that frequently on a regular
basis.
So, I think the problem with smaller buffers is generally the scheduler,
not overhead. Some schedulers are better than others (eg. in realtime
OS’s), and those systems can probably handle much smaller buffer sizes.On Thu, Dec 12, 2002 at 05:14:43PM +0100, Florian Schmidt wrote:
The downside of small buffers is the increased overhead, which is needed
for updating and sending the buffers to the soundcard so fast. So, these
512bytes buffers could be too small for an older machine.
–
Glenn Maynard
The downside of small buffers is the increased overhead, which is
needed for updating and sending the buffers to the soundcard so
fast. So, these 512bytes buffers could be too small for an older
machine.Actually, I believe the real problem with small buffers is that the
system must be able to trigger the callback more frequently and more
regularly.For example, if you have a buffer size of 12ms, then you’re depending
on your mixer thread getting CPU every 12ms. Often, it’s not
significantly more expensive to do work in small chunks (eg. copying
data from a static PCM buffer in 12ms chunks instead of 48ms chunks).
However, most schedulers just can’t give you a timeslice that
frequently on a regular basis.So, I think the problem with smaller buffers is generally the
scheduler, not overhead. Some schedulers are better than others (eg.
in realtime OS’s), and those systems can probably handle much smaller
buffer sizes.
Sounds good to me. :)On Thu, 12 Dec 2002 12:59:52 -0500 Glenn Maynard <g_sdl at zewt.org> wrote:
On Thu, Dec 12, 2002 at 05:14:43PM +0100, Florian Schmidt wrote:
Sandra wrote:
hi,
Has anybody tested/worked SDL with Accelerated X? What were the results?
In your views what are the pros and cons of Accelerated X server with SDL?Sandra
I’m using Accelerated X ( on a Radeon 9000 Pro ). In my oppion it’s much
faster and more stable than XFree, but there are some things that’s
annoying. For one it has no DGA support, it has a version of DRI ( not
the free one, but the same concept, which works well ). There’s also the
That would be XDA - a low level direct rendering library and
extension. There is no public API for it though, as it is still in
flux… Also, it primarily deals with 3D rendering only…
fact that it seems that SDL can’t change the resolution of the screen (
it should be possible though, since the ctrl+alt+[+/-] changes it ),
this could be a since I only got the “gold” version, which doesn’t have
Any version of Summit should be able to change the resolutions via
SDL… I added this support to SDL myself some time ago (1.2.4).
Resolution switching is accomplished via the XME extension. If you have
Summit installed (which will include the XME headers and libs), SDL should
find XME when you run ./configure to build it… I play a few games that
use SDL for res switching under Summit - ut2003, hg, sof, etc - no
problem.
the XVideo extension, the Platinum version has XVideo if I read the
specs correctly though. Accel-X is very stable and I’ve only been able
to crash it once - and I’m quite good at crashing software ;). It also
gives you better options on color correction and a nice setup program (
for both X and console ), so there’s no more editing config files for X.
It’s also very easy to install, all you have to do is install the rpm (
works even though I use gentoo ), and run Xsetup, and it’s working (
I’ve never had such luck after installing XFree ).If your card is supported by XFree ( with DRI and DGA ) - and it’s
stable on your machine, I don’t think it’s worth the $100. The only
reason I bought it was that I needed the support for my Radeon 9000 pro.
I get about the same OpenGL performance as in windows ( windowed mode ),
but if I run fullscreen in windows it blows Accel-X away. I guess this
Probably page flipping. This support is still in development for
Summit.
is because it hasn’t any DGA support.
Well, windows doesn't use DGA either ;-)On Thu, 12 Dec 2002, Magnus Sj?strand wrote:
Date: Thu, 12 Dec 2002 09:25:19 +0100
From: Magnus Sj?strand <magnus.sj at telia.com>
Reply-To: sdl at libsdl.org
To: sdl at libsdl.org
Subject: Re: [SDL] Accel X with SDL
–
Jon Trulson mailto:@Jon_Trulson
ID: 1A9A2B09, FP: C23F328A721264E7 B6188192EC733962
PGP keys at http://radscan.com/~jon/PGPKeys.txt
#include <std/disclaimer.h>
Bad Color Temperature, Too much Peach.