| ALSA: "default" vs "hw" [message #1151] |
Sun, 24 February 2008 06:22  |
|
When docs say
| Quote: |
ALSA NOTE: When using the alsa driver, the "default" translates to "hw", not "default", before being sent to the ALSA API. This is necessary because ALSA's "default" audio device has very poor buffering control capabilities. If you really want to use ALSA's "default" device, use "sexyal-literal-default".
|
it's bacause in src/sexyal/drivers/alsa.c:312 a call to
"snd_pcm_hw_params_set_period_size()" works with "hw" device but fails with "default" device?
It happens to me with a hda-intel AD1988 integrated sound card. But with a Sound Blaster Live! emu10k1 soun card the "default/sexyal-literal-default" device works just fine and I end with a "Buffer size: 1536 sample frames(32.000000 ms)".
So it looks like a hda-intel driver bug and not like a problem with ALSA default device buffering control capabilities.
If it's so, this problems happens with more sound cards? Because if it just happens with hda-intel perhaps hw should not be the default since it disables software mixing and other apps end without sound.
|
|
| Re: ALSA: "default" vs "hw" [message #1197 is a reply to message #1151 ] |
Fri, 04 April 2008 02:02  |
|
Thank you for pointing this out. My laptop has one of those hda-intel's too.
Changing the default device to "sexyal-literal-default" in mednafen.cfg allows other apps to have sound etc before/during/after loading mednafen.
|
|
| Re: ALSA: "default" vs "hw" [message #1276 is a reply to message #1197 ] |
Mon, 09 June 2008 12:51 |
|
I have discovered where the problem is. Our soundcards don't support hardware mixing, so they use dmix by default. And by default dmix uses a 1024 period.
In /usr/share/alsa/pcm/dmix.conf there is:
period_size {
@func refer
name {
@func concat
strings [
"cards."
{
@func card_driver
card $CARD
}
".pcm.dmix.period_size"
]
}
default 1024
}
If you modify the "default 1024" for "default 128" you can get the 128 period using the "default" device.
There are any strict requirements for this low period size? I have not yet tested PulseAudio, but looks like everybody is going to use it and I think it will not work with applications that use hw directly (since PulseAudio uses it itself). So this will be a frequently reported problem.
Between, perhaps you will be interested in PulseAudio since it allows very low latencies (it can overwrite the sound card buffer at any time, so latency doesn't depends of buffer or period size). See http://0pointer.de/blog/projects/pulse-glitch-free.html
|
|
Members 
Search 
Help 
Register 
Login 
Home 
]