From: Clemens Ladisch <clemens@ladisch.de>
To: Sam Lantinga <slouken@libsdl.org>
Cc: alsa-devel@alsa-project.org
Subject: Re: Long-standing SDL ALSA bug
Date: Tue, 13 Oct 2009 09:03:57 +0200 [thread overview]
Message-ID: <4AD4265D.2050109@ladisch.de> (raw)
In-Reply-To: <3adffa60910121114p54e74010r541c6cee86db6721@mail.gmail.com>
Sam Lantinga wrote:
> I'm attaching the latest versions of the SDL audio files, and I'd
> really appreciate it if you take a look and sanity check our code.
> device = SDL_getenv("AUDIODEV"); /* Is there a standard variable name? */
ALSA's devices look at certain environment variables; you are supposed
to use names like "default" or "surround51" to get that default
configuration.
> if (channels == 6) device = "surround51";
> else if (channels == 4) device = "surround40";
The devices do not have automatic sample format/rate conversion; you
might want to use "plug:surround.." instead.
> /* This function waits until it is possible to write a full sound buffer */
> static void ALSA_WaitAudio(_THIS)
This function doesn't actually wait ...
> if ( status == -EAGAIN ) {
> SDL_Delay(1);
> continue;
> }
Not necessary in blocking mode.
> rate = spec->freq;
> status = SDL_NAME(snd_pcm_hw_params_set_rate_near)(pcm_handle, hwparams, &rate, NULL);
> spec->freq = rate;
The returned rate could be wildly different, but I guess SDL correctly
handles the new value in spec->freq.
> /* Set the buffer size, in samples */
> frames = spec->samples;
> status = SDL_NAME(snd_pcm_hw_params_set_period_size_near)(pcm_handle, hwparams, &frames, NULL);
This does _not_ set the buffer size.
> periods = 2;
> SDL_NAME(snd_pcm_hw_params_set_periods_near)(pcm_handle, hwparams, &periods, NULL);
A bigger number of periods would make the writing of audio data less
bursty.
> status = SDL_NAME(snd_pcm_sw_params_set_start_threshold)(pcm_handle, swparams, 0);
Zero doesn't really make sense; the default value 1 would be OK.
> status = SDL_NAME(snd_pcm_sw_params_set_avail_min)(pcm_handle, swparams, frames);
The default value is the period size anyway, so you can remove this.
(If you change the buffer size code above to use _set_buffer_size_near,
this call would be wrong.)
Best regards,
Clemens
next prev parent reply other threads:[~2009-10-13 7:04 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-10-12 18:14 Long-standing SDL ALSA bug Sam Lantinga
2009-10-13 3:36 ` The Source
2009-10-13 5:52 ` Peter Lawler
2009-10-13 7:03 ` Clemens Ladisch [this message]
2009-10-13 10:05 ` Sam Lantinga
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4AD4265D.2050109@ladisch.de \
--to=clemens@ladisch.de \
--cc=alsa-devel@alsa-project.org \
--cc=slouken@libsdl.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox