Package: libasound2-plugins
Priority: optional
Section: libs
Installed-Size: 488
Maintainer: Debian ALSA Maintainers
Architecture: amd64
Source: alsa-plugins
Version: 1.0.19-2
Depends: libasound2 (>> 1.0.18), libc6 (>= 2.2.5), libjack0 (>= 0.116.1), libpulse0 (>= 0.9.14), libsamplerate0
Filename: pool/main/a/alsa-plugins/libasound2-plugins_1.0.19-2_amd64.deb
Size: 119566
MD5sum: 89efb281a3695d8c0f0d3c153ff8041a
SHA1: fdd93b68ec0b8e6de0b67b3437b9f8c86c04b449
SHA256: 7eb5b023373db00ca1b65765720a99654a0b63be741a5f5db2516a8881048aa6
Description: ALSA library additional plugins
This package contains plugins for the ALSA library that are
not included in the main libasound2 package.
.
The following plugins are included, among other:
- a52: S16 to A52 stream converter
- jack: play or capture via JACK
- oss: run native ALSA apps on OSS drivers
- pulse: play or capture via Pulse Audio
- lavcrate, samplerate and speexrate: rate converters
- upmix and vdownmix: convert from/to 2 and 4/6 channel streams
.
ALSA is the Advanced Linux Sound Architecture.
Enhances: libasound2
Homepage: http://www.alsa-project.org/
Tag: devel::library, role::plugin, works-with::audio
Now something jumped out at me, run native ALSA apps on OSS drivers?
If you read my sound article, you know I'm an advocate of OSSv4, since it seems superior where it matters.
So I looked into the documentation for the Debian (as well as Ubuntu) package "libasound2-plugins" on how this ALSA over OSS works exactly.
I edited /etc/asound.conf, and changed it to the following:
pcm.!default {
type oss
device /dev/dsp
}
ctl.!default {
type oss
device /dev/mixer
}
And presto, every ALSA application now started properly outputting sound for me. No more need to always have to fiddle with configurations for each sound layer to use OSS, because the distros don't allow auto config of them.
I could never get flash on 64 bit with sound before, even though each new OSS release says they "fixed it". Now it does work for me.
I tested the following with ALSA:
MPlayer (-ao alsa)
Firefox, flashplugin-nonfree, Homestar Runner
ZSNES (-ad alsa)
bsnes (defaults)
Oh and in case you're wondering, mixing is working perfectly. I tried running four instances of MPlayer, two set to use ALSA, the other two set to output using OSS, and I was able to hear all four at once.
Now it's great to setup each application and sound layer individually to use OSS, so there's less overhead. But just making this one simple change means you don't have to for each application where the distro defaulted to ALSA, or have to suffer incompatibility when a particular application is ALSA only.
Note that depending how you installed OSS and which version, it may have tried forcing ALSA programs to use a buggy ALSA emulation library, which is incomplete, and not bug for bug compatible with the real ALSA. If that happened to you, here's how to use the real ALSA libraries, which are 100% ALSA compatible, as it's 100% the real ALSA.
First check where everything is pointing with the following command ls -la /usr/lib/libasound.*
I get the following:
-rw-r--r-- 1 root root 1858002 2009-03-04 11:09 /usr/lib/libasound.a
-rw-r--r-- 1 root root 840 2009-03-04 11:09 /usr/lib/libasound.la
lrwxrwxrwx 1 root root 18 2009-03-06 03:35 /usr/lib/libasound.so -> libasound.so.2.0.0
lrwxrwxrwx 1 root root 18 2009-03-06 03:35 /usr/lib/libasound.so.2 -> libasound.so.2.0.0
-rw-r--r-- 1 root root 935272 2009-03-04 11:09 /usr/lib/libasound.so.2.0.0
Now as you can see libasound.so and libasound.so.2 both point to libasound.so.2.0.0. The bad emulation is called libsalsa. So if instead of seeing "-> libasound..." you see "-> libsalsa..." there, you'll want to correct the links.
You can correct with the following commands as root:
cd /usr/lib/
rm libasound.so libasound.so.2
ln -s libasound.so.2.0.0 libasound.so
ln -s libasound.so.2.0.0 libasound.so.2
If you're using Ubuntu and don't know how to switch to root, try sudo su prior to the steps above.
If you'd like to try to configure as many applications as possible to use OSS directly to avoid any unneeded overhead, see the documentation here and here which provide a lot of useful information. However if you're happy with your current setup, the hassle to configure each additional application isn't needed as long as you setup ALSA to use OSS.
Enjoy your sound!
35 comments:
To be honest, I don't know why every Linux distro just adopts OSS by default. Better yet, drop support for ALSA altogether.
My current beef with OSS is that it doesn't support suspension. Before a computer can suspend, all the processes using sound must be killed. What is your solution to this? Do you simply not suspend your computer?
I personally don't believe in suspend.
I never had it working right in Linux, due to all the components in general. Sound card not suspending properly is the least of my worries.
Even in Windows XP on my laptop with its designed for Windows XP logo on it, it just doesn't come out of suspend on occasion.
Your tip on removing libsalsa isn't entirely right, since OSS startup will just recreate the symlink to libsalsa on the older OSSv4.0 version which used to install it.
Best to do "rm -f /usr/lib/oss/lib/libsalsa.so.2.0.0" first. Creating the libasound symlinks can be done by simply running "ldconfig" afterwards.
Secondly, it's unfortunate to hear that you couldn't get sound to OSS directly from 64 bit Flash - I can attest it does work.
Hi Yair.
Yes, you're right about a reboot bringing back SALSA. I forgot to mention that I commented the code that does that out of my start up scripts.
As for flash, I'm willing to believe it works fine for you and many other people. But till now, whenever I launched Firefox from the command line, when I navigated to a flash site with sound, I'd keep getting all these ALSA errors reported on my screen, how it couldn't find a sound card and whatever. So it kept using ALSA for whatever reason.
Anyways, at this point I don't really care which library flash uses to output, it's not that important to me.
Very Informative.. Thanks!
I'm not sure you've heard but there is no OSSv4 support in HAL which is not good for the future of OSS. I sent the question to the HAL developers and the post is now on the HAL mailing list. The topic can be found here:
http://thread.gmane.org/gmane.comp.freedesktop.hal/13243
and the mailings list is: hal@lists.freedesktop.org, mailing list details can be found here:
http://www.freedesktop.org/wiki/Software/hal
Like to see OSSv4 be included for HAL, it's a good sound system. As it is now I'm not really sure the HAL devs are aware of it. I like OSS too and as it is now KDE 4 (which almost exclusively uses HAL for device detection) isn't able to use OSS. ugh...
Hi akau.
If you have OSSv4 installed, and ALSA's lib setup to output to OSS, can HAL detect ALSA lib, so you get sound anyway?
insane coder said:
Hi akau.
If you have OSSv4 installed, and ALSA's lib setup to output to OSS, can HAL detect ALSA lib, so you get sound anyway?
Do you mean like this:
http://wiki.archlinux.org/index.php/OSS#ALSA_emulation
Haven't got to try this yet but because it says that it could induce latency, I've been holding off. Perhaps that is the only way to go??
I thought I'd try as you suggested in your post to give libasound a try but in Arch Linux libasound doesn't exist, only libalsa. It's described as such:
aur/libsalsa 4.1-1 (1)
ALSA emulation library for OSSv4 (libasound replacement)
Perhaps I'll give this a try, any thoughts suggestions be appreciated.
akau: Well, I suggest it in this article as the only way to go. libsalsa is not even close to replacing libasound, and there's really no reason to.
The only instance I found libasound added latency is when using OpenAL->libasound->OSSv4 (although it's a bit better than OpenAL->libasound->ALSA on the same machine).
The fundamental problem with OSSv4 is Hannu, unfortunately. OSSv4 is developed by only two developers. ALSA, for all of its flaws, has a much larger developer community. Hannu was too focused on how he was going to make money, and so he closed-source OSSv3 in an attempt to make money. If he had instead gathered a much larger developer community, and continued developing OSS as a hobby, with something else as a day job, when Linux became big, he probably could have gotten a job at one of the major Linux distributions, and possibly have hit it big with the dot-Com IPO lottery.
Consider some of your "Ancient Coding Ideas Finally in English", such as:
It's best to write code for the customer's demands, they will overlook its negative qualities.
Code that's not written for those buying it will be for naught, and improving it will lead to code repetition.
Those writing for a community should write the code for its own sake, those that came before you will help you.
You will end up getting credit for the work that gets added on as if you yourself did it.
or...
Desire what the community wants, and the community will want what you desire.
Do what they want instead of what you want, and other programmers will desire what you desire.
If Hannu had access to your wisdom, perhaps he would have been in a much better position.
What to do at this point is a hard question; I'm willing to believe you that OSSv4 may be technically superior to ALSA. But ALSA has a much larger development community; so the question is whether Linux's sound driver coverage would in the long run be better switching to ALSA, and are the switching costs worth it given the pain in terms of having two sound driver interfaces in the kernel?
The answer to that question is not obvious.... and the effort needed to import large amounts of external code into the Linux Kernel, in terms of making it meet kernel coding standards so it can be long term maintainable (especially given the lack of trust about whether Hannu might suddenly disappear and try to close-source future versions of sound drivers) is definitely non-trivial.
Hi Theodore.
>The fundamental problem with OSSv4 is Hannu, unfortunately. OSSv4 is developed by only two developers. ALSA, for all of its flaws, has a much larger developer community.
The amount of developers doesn't matter, it's the quality of the work they do. This should be obvious by ALSA being technically poorer despite its larger development community.
You also can't equate the amount of people to total hours put in. What they do is important too, ALSA is a lot of bloatware with how many hundreds of API calls that are useless? If that's what the majority of ALSA developers work on, then even by that measurement, they might as well only have half a developer.
>Hannu was too focused on how he was going to make money, and so he closed-source OSSv3 in an attempt to make money. If he had instead gathered a much larger developer community, and continued developing OSS as a hobby, with something else as a day job, when Linux became big, he probably could have gotten a job at one of the major Linux distributions, and possibly have hit it big with the dot-Com IPO lottery.
Yes, but that doesn't explain the poor choices made by the Linux community. FreeBSD continued on the OSS they had, and they're doing pretty good today, and don't have even a tenth of the issues Linux has with sound.
>Consider some of your "Ancient Coding Ideas Finally in English"
I agree with you, and in fact you could've picked even better quotes to more aptly fit the situation. That however doesn't change the facts that we the rest of the Linux developers and community have to deal with.
>If Hannu had access to your wisdom, perhaps he would have been in a much better position.
Yes, he would have. But who cares about him? I care about the rest of us.
>But ALSA has a much larger development community
Which has proven to be irrelevant.
>so the question is whether Linux's sound driver coverage would in the long run be better switching to ALSA, and are the switching costs worth it given the pain in terms of having two sound driver interfaces in the kernel?
Well, I made the case in my other article that the drivers themselves should all be shared. With OSSv4 only recently going open source, you already see a nice amount of sharing going on regarding the drivers, but that has to be extended, till there is no difference. The only difference between ALSA and OSS on the Kernel level should be their stack that runs on top of sound hooks to those drivers. We can wish for it, but I doubt that would happen.
>The answer to that question is not obvious.... and the effort needed to import large amounts of external code into the Linux Kernel, in terms of making it meet kernel coding standards so it can be long term maintainable
In order to use OSSv4, we don't have to import it into the Kernel. If we so desired we could leave that for a much later date. I made this point in my other article.
>(especially given the lack of trust about whether Hannu might suddenly disappear and try to close-source future versions of sound drivers) is definitely non-trivial.
The fact that this worries anybody shows an issue with the mentality of open source developers, especially those that work on Linux itself. So what if he does that? Does that mean our current excellent code base magically vanishes? FreeBSD didn't have a problem when Hannu did this in the past, they were able to carry on. If we in Linux are so dependent on a single person, what's going to happen when Linus is no longer around? What if heaven-forbid he gets hit by a car one day without any warning? We all going to roll over and die? Or have to rewrite every ounce of code with a completely new design since the original author is no longer around?
My worry about OSS is the high number of wakeups it generates. (OSS 4.1 (b 1052/200906210935), Linux/x86_64 2.6.30 #1 SMP PREEMPT) Powertop says oss_hdaudio0 produces 1877 wakeups per second despite of there is no running playback at the moment. Has anybody else met this issue? Do you know any solutions for this? My sudden googling didn't help.
>The amount of developers doesn't matter, it's the quality of the work they do.
I strongly disagree. There's something known as the 'bus factor' that needs to be taken into account. If one or both of the developers are no longer able to continue development (such as getting hit by a bus, getting a new job, dying of old age etc) then the OSS project would effectively cease to exist. We have to think of long term supportability otherwise in say 10 years time we will be in the same situation looking to replace OSS with something else.
http://en.wikipedia.org/wiki/Bus_factor
>>(especially given the lack of trust about whether Hannu might suddenly disappear and try to close-source future versions of sound drivers)
>The fact that this worries anybody shows an issue with the mentality of open source developers, especially those that work on Linux itself. So what if he does that? Does that mean our current excellent code base magically vanishes?
The problem is that the OSSv4 kernel code (which I've looked at) is barely commented. The style violations aren't necessarily indicative of bad coding style, but at the very least it is a different coding style than the rest of Linux kernel --- and the lack of comments doesn't win Hannu style points.
Whether you call "bad marketing", or blame it on ALSA's team "FUD", the fact of the matter is that the OSSv4 core developers have not been able to attract the same number of programmers as other sound projects. Granted, being technically good is important too --- and regardless of whether or not the OSSv4 team is "better" or not that than the ALSA core team, the ALSA team was capable of putting a sound system together with very complete coverage in terms devices and device functionality.
You might be complaining about the latency of ALSA, but no less of an authority than Hannu himself has said that stressing about sound latency is silly (he's right; what's more important is timing, so you can synchronize what's happening on the screen with the sound). See this entry on his web site.
OK, maybe ALSA's API could be better. It is trying to allow access to a more complex set of functionality than OSS, however. But at the end of the day, that's not what's important. The question is whether the two developers that OSS currently have are sufficient enough to provide sound driver support with equivalent functionality to ALSA (i.e., coverage in terms of number of devices, and support for all of the functionality of those devices). Note that Hannu himself has said that two people are not enough to create and support sound drivers for USB and Firewire-attached devices before they become obsolete.
So again, with Hannu at the helm, and his lack of ability to bring a development community, why should a distribution company spend money hiring a OSS developer who isn't capable of either doing the job himself or bringing together a team of volunteers to get the job done?
Maybe if the distribution could spend enough money to fund the entire sound problem from soup to nuts, but in this economic environment? Especially when most desktop users aren't willing to pay money for Liunx sound support? How do you make the business case that they should do this?
Hi Giga.
>>The amount of developers doesn't matter, it's the quality of the work they do.
>I strongly disagree. There's something known as the 'bus factor' that needs to be taken into account.
Didn't I just mention something about a developer getting hit by a car?
>If one or both of the developers are no longer able to continue development (such as getting hit by a bus, getting a new job, dying of old age etc) then the OSS project would effectively cease to exist.
Did that happen with FreeBSD, when OSS went closed source before?
> We have to think of long term supportability otherwise in say 10 years time we will be in the same situation looking to replace OSS with something else.
You don't have to replace something just because the main guys are gone.
I feel like I already responded to this.
Hi Theodore.
>The problem is that the OSSv4 kernel code (which I've looked at) is barely commented.
That is indeed an issue, so lets bring it up to him and get it commented.
>The style violations aren't necessarily indicative of bad coding style, but at the very least it is a different coding style than the rest of Linux kernel
Are we really so inept that we can't look at a program with a different style? If that's the case, let's just trash all open source programs right now.
>Whether you call "bad marketing", or blame it on ALSA's team "FUD", the fact of the matter is that the OSSv4 core developers have not been able to attract the same number of programmers as other sound projects.
Good, so why not do something about it yourself? Stop relying on what they attracted, you start attracting. Tell your friends.
>Granted, being technically good is important too --- and regardless of whether or not the OSSv4 team is "better" or not that than the ALSA core team, the ALSA team was capable of putting a sound system together with very complete coverage in terms devices and device functionality.
What you find complete may not be the same thing I find complete. If any percentage of users find ALSA is lacking something, then it should be obvious it is lacking something. Are we going to start doing something about it?
>You might be complaining about the latency of ALSA, but no less of an authority than Hannu himself has said that stressing about sound latency is silly (he's right; what's more important is timing, so you can synchronize what's happening on the screen with the sound). See this entry on his web site.
I've read that before. I don't think you understand what I'm referring to. Many people like to say how something has 0 or <10ms latency (that PulseAudio guy in that other thread is a real riot), as Hannu points out, measuring something that's 20ms vs. 80ms is just silly, non practical, and not even noticeable by the average user.
When I'm referring to latency, I'm referring to 30-100ms vs 2-5 seconds. Anyone without specialized equipment can hear that difference. It's easily measurable when you've tried playing many games. Especially when using PulseAudio.
>The question is whether the two developers that OSS currently have are sufficient enough to provide sound driver support with equivalent functionality to ALSA (i.e., coverage in terms of number of devices, and support for all of the functionality of those devices). Note that Hannu himself has said that two people are not enough to create and support sound drivers for USB and Firewire-attached devices before they become obsolete.
Driver-wise with what is going on today, it is indeed an issue. Hence I called that all drivers should be shared, would make life easier. In any event, someone is going to have to write new drivers. If there was only OSS today, they'd be writing them for OSS, and it'd be a non-issue.
>So again, with Hannu at the helm, and his lack of ability to bring a development community, why should a distribution company spend money hiring a OSS developer who isn't capable of either doing the job himself or bringing together a team of volunteers to get the job done?
What you're describing is a bona fide catch-22. Why should we do anything if it hasn't been done till now? Or we can stop bemoaning the lack of noticing OSS till now and start noticing it.
>Maybe if the distribution could spend enough money to fund the entire sound problem from soup to nuts, but in this economic environment?
Again, why did Red Hat fund PulseAudio?
>Especially when most desktop users aren't willing to pay money for Liunx sound support? How do you make the business case that they should do this?
It depends on who my user base is of my distro. If indeed all I do is sell servers, then of course I won't be able to make the case. But if I sell workstations with support to companies that need audio, I think it would make a lot of sense to me to provide a better audio solution than what my competitors are shipping.
Also look at Ubuntu, they're not even profitable. Mark Shuttleworth seems to have made his goal in life to take down Windows from the #1 OS position, and doesn't care how much money he flushes on the problem. If that is indeed the case, then if any money is being considered on improving audio to compete with Windows, then it should be considered on spending it on the solution which is closest to matching or surpassing Windows. I don't necessarily know with 100% certainty which technology that is, but I believe it is OSSv4.
>Didn't I just mention something about a developer getting hit by a car?
You did, but I believe you were referring to Linus at that point. The kernel has a large number of contributers and Linus doesn't actually write that much code these days, he oversees other peoples code. The kernel project would be safe as there are a number of candidates who are qualified to take over and already know the code base. In the case of OSS, since the code isn't commented and since not many people know the code, it's often (but not always) easier to just write your own from scratch rather than try to figure out what it is doing.
>Did that happen with FreeBSD, when OSS went closed source before?
I don't know the history of FreeBSD, but I got the impression that they kept the OSS API and wrote their own implementation. If that was the case, then yes it pretty much did happen with FreeBSD.
>So what if he does that? Does that mean our current excellent code base magically vanishes?
Excellent code bases are only as good as the maintenance support behind them.
Hi Giga.
All very good points. So lets ask Hannu to comment his code better, and let's build a community to maintain it.
Thank you for this awesome tip!
I noticed something funny though. Flash 64-bit works flawlessly with OSS4 (through OSS4's own "libflashsupport"). When I tested removing /usr/lib/libflashsupport.so and see if it works with ALSA now, it doesn't; sound plays, but video is extremely slow and skips, and Firefox almost hangs (or rather becomes extremely sluggish). Funny that I'm having the exact opposite of what you experience...
Anything else works 100% OK though. Thanks again for this tip!
> akau: Well, I suggest it in this article as the only way to go. libsalsa is not even close to replacing libasound, and there's really no reason to.
> The only instance I found libasound added latency is when using OpenAL- >libasound->OSSv4 (although it's a bit better than OpenAL->libasound->ALSA on the same machine).
Thanks for the response insane coder. I looked into getting asound into Arch Linux but don't know enough yet about build the package so I'm gonna have to hold off on that. The good news is that it looks like someone it working to get oss into xine as I notice there is a --enable-oss flag now. I tried it out and the startup sound now works (Amarok and Kmix don't) so hopefully this is good news for the future. Been using ALSA the last couple days... Not the same.
I don't get any problems with Xine and OSS4. I'm using KDE 4.2.4 with Xine as backend. Everything works correctly.
I'm on Gentoo Linux.
You gave the advice to create /etc/asound.conf with your suggested settings. I found however, that this created some problems. After doing so, a lot of applications were no longer able to play files with a different frequency than my sound card was set to. While my soundcard is set to play in 48.000 kHz, all mp3's in 44,1 kHz no longer played. It also means that programs with both alsa and oss backends, will revert to alsa (as it's the first thing they test).
hum...
Hi everybody, very interesting thread.
It just happened that I followed am Ubuntu guide (https://help.ubuntu.com/community/OpenSound), did all things clean (I hope...) and found myself with a buggy audio-system. My feeling is that OSS is probably a good solution but setting it up to work properly is beyond hope! Guess what... about the only thing that nearly works is Skype (using the OSS static ;-) ).
If OSS is only for gurus, then it's a bad move.
Want the result on my poor pc (FS Amilo 14xx):
- sound is scratchy
- no control, mixer has poor interface and you need a master in windows95 to use it (or was it msdos 3.4)!
- amarok and likes play distorted music and no volume control.
etc etc...
Now I revert to Alsa, doesn't matter if skype is lousy. And I'll wait for a fully tested guide on Jaunty before I ever try again OSS.
TOO BAD.
/JLM
For so many apps it seems I need to use SDL alsa output. Like for mplayer i need to use the -ao sdl command line option, and for zsnes i need to use -ad sdl..
Do you think my problems could be solving by using ossv4 instead of alsa?
Is -ao sdl actually using OSS? @_@
If your card is well supported by OSS4, I'd say go for it. In any case, it can't hurt to try.
McFiredrill:
If ZSNES only works for you with -ad sdl, consider getting a binary from here. Also read this if you still have problems.
@Insane Coder
Hmm interesting...I use gentoo and the latest version of ZSNES in portage is 1.51-r2, not sure if that's the same as the 1.51b from the thread you referenced...
Actually I tried it with -ao oss and it seems to work too...
Thanks for this excellent pointer/post.
I got significantly improved sound using oss4.2 and even got most alsa applications to work seamlessly using libasound2-plugins as you recommended.
However I am currently struggling to get xbmc video and audio to sync properly using the latest svn build. The older builds of xbmc seem to gel nicely with libasound2-plugins and not worry about the fact that the sound was non-alsa.
Excellent, saved a lot of hassle trying to work out alsa's awful config system.
As a bonus now UAE plays without annoying pauses in sound every second.
I can't believe that joke PulseAudio has any following whatsoever - maybe they're MS or Apple plants trying to make sure nothing ever works properly? I mean, it's such a blatantly ridiculous piece of crap people can't really believe it's any use.
Wisdom Overseasis authorized India's Exclusive Partner of Southwestern University PHINMA, the Philippines established its strong trust in the minds of all the Indian medical aspirants and their parents. Under the excellent leadership of the founder Director Mr. Thummala Ravikanth, Wisdom meritoriously won the hearts of thousands of future doctors and was praised as the “Top Medical Career Growth Specialists" among Overseas Medical Education Consultants in India.
Southwestern University PHINMAglobally recognized university in Cebu City, the Philippines facilitating educational service from 1946. With the sole aim of serving the world by providing an accessible, affordable, and high-quality education to all the local and foreign students. SWU PHINMA is undergoing continuous changes and shaping itself as the best leader with major improvements in academics, technology, and infrastructure also in improving the quality of student life.
Hi.....
The Open Sound System (OSS) is an interface for making and capturing sound in Unix and ... and not to the OSS API itself, or have been addressed in OSS version 4.
You are also read more Business Loan Calculator
what will be 2 major factor to choose spa?
Qualified Staff
Choose a b2b spa near me with qualified and experienced staff who are trained to provide professional services safely and effectively. Look for certifications and qualifications to ensure you're in good hands.
Customer Reviews
Read reviews and feedback from previous clients to get an idea of what to expect from the spa. Pay attention to both positive and negative reviews to make an informed decision.
Is any restrictions for f2m massage?
Any over 18 people can try this like me choose female to male spa near me for simple and best service
It helps promote blood circulation, reduce stress and tension, increase energy levels and improve body muscle strength. We offer people col atmosphere so they can relax and rejuvenate their whole body near spa me
Post a Comment