SDL & eee PC

Hi there,

I’ve been struggling for a while trying to port a cross-plaform tracker
(using SDL on most platforms) to run smoothly on eee-PCs running
Xandros. I do believe the video API does affect the audio smoothness but
I have no way to test it. ALSA stutters a lot while ‘dsp’ is sort of ok,
excepts it drops a blank every minute or so. It’s kind of frustrating
coz when I look at top, the process only taks 7% of the CPU :frowning:

I was wondering if anybody would have been through the same issues or
experiences, and if someone knew a decent route (or example) to get a
SDL-based audio/gfx program to run properly on this machine.

Thanks in advance,
Marc

Hi there,

I’ve been struggling for a while trying to port a cross-plaform tracker
(using SDL on most platforms) to run smoothly on eee-PCs running
Xandros. I do believe the video API does affect the audio smoothness but
I have no way to test it. ALSA stutters a lot while ‘dsp’ is sort of ok,
excepts it drops a blank every minute or so. It’s kind of frustrating
coz when I look at top, the process only taks 7% of the CPU :frowning:

I was wondering if anybody would have been through the same issues or
experiences, and if someone knew a decent route (or example) to get a
SDL-based audio/gfx program to run properly on this machine.

Never tried “xandros”, but SDL linux sound has given me problems
that I wasn’t able to resolve. Here are my stream-of-consciousness
notes on it, maybe they’ll help. If you figure something out, do tell
(I don’t think I’d tried the dsp driver, so I’ll give it a shot). For me the
important variables seemed to be buffer size and driver, I don’t think
video has anything to do with it:

sound doesn’t work out of the box with SDL 1.2.11 on ubuntu (vers?)

under parallels ubuntu (1.2.11). SDL_OpenAudio is failing with
the message “buffer size must be a power of 2”. passing an “obtained” audio
spec doesn’t help, fn fails just the same. making the buffer size a power
of 2 doesn’t actually get you any output. however, setting SDL_AUDIODRIVER
to either “esd” or “alsa” does work and lifts the unknowable a priori power of 2
restriction.

“esd” can’t do silence, clicks and seems to overflow with lots
of sounds. “alsa” seems doesn’t have this problem. however killing the alsa
version with ctl-\ can cause a hellish racket (ctl-c no). Note: alsa asks
for fewer frames (esd doesn’t), hence the spooner* code is working.
why doesn’t the default driver work and which is it??

the non-functional default (on my ubuntu and ben’s kubuntu) could be oss?

*this refers to the bit of code that handles the situation in which the
audio callback asks for fewer, or more samples than are ready.On 4/16/08, sdl-request at lists.libsdl.org wrote:

From: “M-.-n”

Never tried “xandros”, but SDL linux sound has given me problems
that I wasn’t able to resolve. Here are my stream-of-consciousness
notes on it, maybe they’ll help. If you figure something out, do tell
(I don’t think I’d tried the dsp driver, so I’ll give it a shot). For me the
important variables seemed to be buffer size and driver, I don’t think
video has anything to do with it:

sound doesn’t work out of the box with SDL 1.2.11 on ubuntu (vers?)

under parallels ubuntu (1.2.11). SDL_OpenAudio is failing with
the message “buffer size must be a power of 2”. passing an “obtained” audio
spec doesn’t help, fn fails just the same. making the buffer size a power
of 2 doesn’t actually get you any output. however, setting SDL_AUDIODRIVER
to either “esd” or “alsa” does work and lifts the unknowable a priori power of 2
restriction.

the power of 2 restriction is from OSS specs.

“esd” can’t do silence, clicks and seems to overflow with lots
of sounds. “alsa” seems doesn’t have this problem. however killing the alsa
version with ctl-\ can cause a hellish racket (ctl-c no). Note: alsa asks
for fewer frames (esd doesn’t), hence the spooner* code is working.
why doesn’t the default driver work and which is it??

the non-functional default (on my ubuntu and ben’s kubuntu) could be oss?

is sdl doing any conversions or resampling? if so, I wonder if
the patch in bugzilla #477 will help.On Wed, Apr 16, 2008 at 11:22:44AM +0200, Rhythmic Fistman wrote:

*this refers to the bit of code that handles the situation in which the
audio callback asks for fewer, or more samples than are ready.


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


@Jacob_Meuser
SDF Public Access UNIX System - http://sdf.lonestar.org

under parallels ubuntu (1.2.11). SDL_OpenAudio is failing with
the message “buffer size must be a power of 2”. passing an “obtained” audio
spec doesn’t help, fn fails just the same. making the buffer size a power
of 2 doesn’t actually get you any output. however, setting SDL_AUDIODRIVER
to either “esd” or “alsa” does work and lifts the unknowable a priori power of 2
restriction.

the power of 2 restriction is from OSS specs.

That may be, but as of 1.2.11 there was no way to ask
the driver what buffer size IS acceptable.

“esd” can’t do silence, clicks and seems to overflow with lots
of sounds. “alsa” seems doesn’t have this problem. however killing the alsa
version with ctl-\ can cause a hellish racket (ctl-c no). Note: alsa asks
for fewer frames (esd doesn’t), hence the spooner* code is working.
why doesn’t the default driver work and which is it??

the non-functional default (on my ubuntu and ben’s kubuntu) could be oss?

is sdl doing any conversions or resampling?

How would I know? I was supplying 8bit mono at 44.1kHz, so that’ll likely
get converted to 16bit stereo. 8->16 conversion’s very hard to get right,
so I’ll try switching to 16bit output, however the kinds of noises I
heard didn’t
sound like your typical conversion bugs…

if so, I wonder if the patch in bugzilla #477 will help.

Could be, mono -> stereo IS upsampling, so thanks, I’ll try it out.

RF> From: Jacob Meuser

is sdl doing any conversions or resampling?

How would I know? I was supplying 8bit mono at 44.1kHz, so that’ll likely
get converted to 16bit stereo. 8->16 conversion’s very hard to get right,
so I’ll try switching to 16bit output, however the kinds of noises I
heard didn’t
sound like your typical conversion bugs…

if so, I wonder if the patch in bugzilla #477 will help.

Could be, mono -> stereo IS upsampling, so thanks, I’ll try it out.

8->16 conversions would be affected too. not upsampling, but like
upsampling, requires a larger buffer size for the same amount
of time.On Wed, Apr 16, 2008 at 04:38:15PM +0200, Rhythmic Fistman wrote:

From: Jacob Meuser <@Jacob_Meuser>


@Jacob_Meuser
SDF Public Access UNIX System - http://sdf.lonestar.org