You are not logged in.
mplayer should be compiled with alsa support
Offline
What about people not using alsa?
I guess that nothing prevents you to rebuild mplayer with alsa support on your own box...
FYI, you can also have a look there: http://bbs.archlinux.org/viewtopic.php?t=331
Offline
If you compile in support for Alsa, you do not exclude other sound libraries. Just add additional support for alsa.
Offline
Just add additional support for alsa.
Yes, and also deps with alsa...
Offline
what means alsa support here???
my mplayer works fine and i use alsa, without recompiling it ...
nothing,
maybe I have a perfect signature _someday_
Offline
You're probably using the snd-pcm-oss module, which makes ALSA compatible with OSS apps.
Offline
ahh, yes i do so ....
explains a lot ...
i this case i would also say to _not_ include alsa support in mplayer, as long as it is that simple to emulate this oss interface via the module .....
nothing,
maybe I have a perfect signature _someday_
Offline
hi,
i think it could be a solution to add a "directory" in the "current" tree which contains all the packages compiled with ALSA support like mplayer, sdl, etc...
It could help some people and prepare Arch Linux migration to Linux 2.6 kernel.
2nd solution:
Is it possible (i'm not developper) to create a system like the USE variable on Gentoo Linux ?
Comete
Offline
Aaaaah but I want (and have) support for ALSA and ARTS!
So then we have to make 3 files (or comment 2 ./configure lines)
Tricky stuff, ALSA will be the future of sound in linux (with Jack I hope ) but OSS is the standard in 2.4
And we're still on 2.4 so it's tricky
apt-get install arch
Offline
Another idea would be making ALSA the distribution default, and dump OSS for good where possible. It's close to impossible for a distribution to have packages for all viable combinations of configure options; That's what ABS is good for, compiling your own package with any non-default options with a minimum of fuss. What is considered as "default" though is a matter of the distribution, and I'd opt to go the ALSA way in the near future.
I am not well informed, however, about how good ALSA has become and whether there are still a lot of issues around that'd make staying with OSS a better choice for now. If it's working "good enough", Arch could be among the early adopters, as with DevFS. Since Arch is aimed at the experienced folks, it can break a few times if need be.
We need a clear path to follow, though. Letting too many mutually exclusive options coexist are a near guarantee for total package mayhem; "package ABC only works with kernel-XYZ, but only if package FGH and FGH2 are installed as well." *shudder*
Greets,
Dennis
"That's the problem with good advice. Nobody wants to hear it."
-- Dogbert
Offline
when the migration to the 2.6 kernel happens then the packages that can make use of alsa should be recompiled. there are a fair number of people that use OSS and OSS is enabled in the kernel. therefore i think continuing to compile apps with just OSS should be the standard.
just my 2 cents as i run one computer with alsa and one without.
AKA uknowme
I am not your friend
Offline