Epic: "But the chain of logic from 'Linux is about
choice' to 'ship everything and let the user chose how they want their sound to not work' starts with fallacy and ends with disaster."
Is sound still a problem on Linux? I realize the article is about 5 years old, but Linux has been around for a long time now, and sound is a really basic function I'd expect even obtuse geeks would want to solve. If it is still a problem, seems that's a definitive concise example of why Linux can't win the OS wars: some things must work, even if nobody wants the task of making it work; sometimes the only solution is to pay someone to do what nobody else wants to.
It really isn't. Unless you have a card without a driver (exceedingly rare, though it's not uncommon to need a recent kernel to use recent hardware) ALSA pretty much Just Works. For complex features like streaming sound over the network you need PulseAudio, which due to its complexity takes more configuration and setup, but that's done out of the box on a fair number of distros. I don't know of any major software that requires OSS (though if I'm not mistaken it's still the preferred solution for BSD and therefore often available as an option), and only professional software uses JACK; users of JACK generally buy high-end hardware specifically for that purpose and know what they're doing.
So there are three major components for different purposes. Core audio support is the domain of ALSA itself and Linux does a good job with it. PulseAudio provides advanced capabilities on top of the more basic/hardware-oriented functionality in ALSA, and JACK provides low-latency audio for realtime applications that need it (not games, only really audio processing equipment). With large amounts of work the partial redundancy between these components could be removed, but it's really not a big issue; for desktop or professional use getting things to work right isn't too hard.
I actually find PulseAudio vs. JACK incredibly annoying. I like to play around with "professional" audio. I don't consider it professional, but more relevantly I like to play with certain apps that require JACK.
It's certainly an RTFM thing, but last time I didn't know how to get PulseAudio to go away. I wrote a shell script to keep killing it in a loop (since it restarts itself) long enough to get JACK to take over. I know there must be better ways...
Then inevitably once I've got JACK setup, I'll want to play some background music or watch some Flash video online without tearing down my JACK setup. Oops, does that audio player support JACK natively? Do I have that plugin installed? Can I run Pulse and have it direct output into JACK? None of this has worked smoothly in my experience.
> users of JACK generally buy high-end hardware specifically for that purpose and know what they're doing
This has not been my experience. I love to dabble, but apparently don't know what I'm doing.
May I humbly recommend adding the KXstudio Repos (https://launchpad.net/ubuntu/+ppas?name_filter=kxstudio) to your Ubuntu installation? the Cadence utility makes JACK configuration very painless, automagically setting up JACK to run everything, with ALSA loopback and PulseAudio bridges for input and output. Firefox/Flash/Phonon/Skype all route through PulseAudio, which gets sent to JACK. all ALSA-only applications get routed through Loopback, which gets sent to JACK. And you can route all of this sound (visually, if you use the Claudia app) to whatever processing or recording application you want.
Two weeks ago, I spent 20 minutes with 3 KXStudio Laptops and a master KXStudio workstation, and got all the laptops acting as input slaves to pipe live instruments and mics to Ardour running on the workstation using Opus as the transferring codec. all it took was loading the network module into JACK, and making sure there was gigE/cat6 for networking. we had mp3's and FLAC's of the concert ready for the band to review before their roadies were done packing up the gear.
As for high-end hardware, the laptops are using M-Audio Fast Track Pros and 10/10's. None of the hardware goes for more than $150, and we're using ultra-cheap AMD Fusion laptop slaves sourced from alibaba with an AMD A10-based workstation as master. We're at $2800, including 3 monitors.
Because an AMD A10 with 12GB of RAM is stupid overpowered for audio production, we installed MacOS X via KVM and routed that output through JACK as well. WINE loads quite a few professional digital audio workstation packages, and a ton of VSTs, and wineasio makes them all work with JACK. Running all this emulation doesn't make the system feel sluggish at all.
the main website is http://kxstudio.sourceforge.net, but the LiveCD downloadable there is based on Ubuntu 12.04. I installed raring, added the PPA's, and then installed packages. I like bleeding edge. but the official livecd is _very_ painless to install if you're having headaches configuring.
Reminds me of how I seem to need to purge anything related to "avahi" before I can get wireless networking to work. I don't know what that junk is for but I wish it wasn't installed by default.
I don't know why it is generally enabled on "server" installations. That being said, the only time I've had a legit use of it was on a media server, running mediatomb, which uses avahi to do SSDP/mDNS/zeroconf/DNS-SD [1], and on the client running VLC (I think the "local network" options interface with avahi itself). Which actually ended up being quite nice. I usually disable it, and try to uninstall it completely, on other server installations.
It provides compatibility with Apple's more recent network technologies (Bonjour/Rendezvous etc), plus probably other stuff I don't know anything about.
You can prefix your command with pasuspender to temporarily disable pulseaudio. This is usually what I do. It's kind of inconvenient and half the time I forget to do it, so sometimes I just write a little launcher script that includes it.
PulseAudio instantly respawns from this if you have autospawn set to yes (and most distributions do, and it takes some effort to get it working without that).
Typically when I want a quick-and-dirty "kill PulseAudio for real" solution I move /usr/bin/pulseaudio to /usr/bin/pulse-dead, issue pkill pulseaudio, and proceed until I want PA to come back to life, at which time I mv the binary back.
That only works as long as the command it wraps is living. I could use that approach, but typically I don't just want pulseaudio dead while gedit or something is running, I want it dead until I decide that I want it back. It usually happens this way when I'm debugging an audio issue, so it'd be annoying to have PA constantly cycling that way.
>It really isn't. Unless you have a card without a driver (exceedingly rare, though it's not uncommon to need a recent kernel to use recent hardware) ALSA pretty much Just Works. For complex features like streaming sound over the network you need PulseAudio, which due to its complexity takes more configuration and setup, but that's done out of the box on a fair number of distros.
So, in other words, it really is. All you said was just rephrasing the problem as solved.
For one, what's "exceedingly rare" is not getting any sound at all. That doesn't mean you get to enjoy all the features of your soundcard (from mixing panels to 3D audio and such). Or that it work without tinkering in ALL programs and across desktop environments.
There's also the issue of more professional sound work, which will be a world of pain. Getting any pro, multi-channel soundcards to work and such.
For anything else than basic sound playing, from recording a podcast, to streaming, to using a DAW etc, here be dragons.
The dog's breakfast of audio standards on Linux neatly encapsulates the weaknesses of systems as open and democratic as Linux and illustrates why it thrives on servers where these issues are less pressing and still languishes on the desktop where too much choice is not a virtue.
This legacy hampers Android too, which is a joke when it comes to multimedia APIs compared to the oligarchic iOS.
Desktop Linux is just missing a vertical here. The "open and democratic" methods of Linux, also called "free market" or "bazaar", are a fine as a stage of development. This is why distributions exist; they make the choices from the raw technology and bundle it up all neatly. The issue is that the distributions do not have a real attitude of tight integration and strict user-centric organizational imperatives. Ubuntu, Fedora, et al use their platforms as late-stage testbeds instead of standardized, consumer-ready desktop burns with full integration.
In many ways, OS X has shown us the ideal distribution. It's based on open technology and continually adopts new technology as it proves itself, but Apple is not afraid to integrate tightly and replace components with well-engineered, well-tested replacements as necessary (the origination of the divergence between X11 and Quartz), as long as it means a solid, unified, consistent and functional experience for their users.
We need that now. Canonical fancies themselves after that pattern but I don't believe they take the needed organization seriously enough and I don't believe they have the technical expertise necessary to really make the tough calls and implement a technically-sound user-centric system (see: Mir). They need to get some new leadership in there.
As a non-professional, I use a non-realtime JACK as the new ESD. I prefer that over the incomprehensible monster that PulseAudio is.
My needs are simple: I want sound from my audio player (MOC), from my browser (f.e. Youtube), from games and they shouldn't interfere. So my audio player shouldn't have exclusive access to the device and prevent me from hearing Youtube at the same time.
JACK does all this, is easy to configure and doesn't get in the way.
edit: I should mention I run Debian Testing and prefer to stay away from big desktop environment like Gnome (do we see a trend here?).
Whenever I see this 'multiple apps using a sound card at once' issue mentioned, I try to recall what sort of ALSA 'voodoo' I've employed to make this work for me. Then I realise; absolutely nothing.
I think the last time I ever had this problem was literally around 12 years ago, and it was caused by me fiddling with my alsa conf file. I haven't touched any ALSA related settings or done anything special in the last ~8 years, and I never have a problem with things like playing music and having a browser flash plugin using audio at the same time.
Not saying it doesn't happen to other people. Just genuinely curious and baffled.
Always confused me too. Alsa worked well, and then I remember Ubuntu introducing PulseAudio too early when it was immature, and it was horrible for a while, but six months later it had all been fixed and I never had any issues with PulseAudio again... What was that, like five or six years ago now?
happened for me as late as 2008 (last time I bothered checking) - GAIM/Pidgin were usually the culprit - once they'd played a sound, nothing else could until I killed it. Had issues on Ubuntu and Mandriva (and IIRC) fedora, over several versions, with both KDE and Gnome setups, on multiple laptops. Grew tired, switched to macbooks/osx.
Is there still debian testing, or are you calling 'wheezy' as testing? Just wondering
I thought the way it was supposed to work was, when testing gets re-tagged as stable, there's no 'testing' for a brief period (month?) until the next planned distro release is named.
This is not how it works. The next release name is announced approximately when the freeze starts. When a release happens, oldstable is archived, stable become the new oldstable, and the current state of testing becomes the new stable.
For a moment of time (we're talking hours), testing and stable have the same set of packages. Britney, the software
which migrates packages from unstable to testing, runs four times a day. During a freeze, it is configured to need "unblock exceptions" to migrate packages. When this is option is disabled, the following britney run will make the first difference between testing and stable.
Because it conveys relevant information. If you were on version 7 and the new version is version 13, a message is conveyed that there have been several major iterations since your last upgrade. Numerical versioning schemes (in general) make it simple to know if you're on a current version, and if not, how far off you are.
Now consider trying to make similar determinations if you know you're running "Gingerbread" but the latest version is "Jelly Bean", or if you're on "Intrepid Ibex" and the latest version is "Raring Ringtail".
It's even worse on Ubuntu, where they've chosen a reasonable, useful numerical versioning system (year.month), but then obscure it with stupid codenames.
IMO it's also much more difficult to remember the codenames. I had to verify that Android 4.2 was still called Jelly Bean and though I knew the latest Ubuntu was 13.04, I had to look up its codename altogether.
The fact that these projects continue to have underlying "developer use only"-type numerical versions only further emphasizes the utility of these. The codenames feel like a poorly-conceived marketing thing. I don't think most people have trouble remembering a coupled software package with a version number, like "Windows 7". I don't think they often say, "Oh crap, I know I had version 4 of something ... was it Android or Windows?"
The unique names really help with googleability. 'debian 7' will return more chaff than 'debian wheezy'. "Where's the 7 on this site? Oh, it's the forum page number" and so forth. Similarly I can ask a dev in a mixed shop "is wheezy or precise on this" and it's easier than saying "is debian 7 or ubuntu 12.04 on this". Ubuntu numbers are unusually regular and unique, which helps their googleability, but other versioning numbers aren't.
Thank you very very much. But I still think that it should be in uname -a. I have never heard of lsb_release... and I'm not new to the stuff.
If they really wanted to improve UI, it would also be in the 'system settings' link under the username on the desktop panel- for users that run desktops.
For what it's worth, Ubuntu versions are always Adjectivated Animals (with the adjective and the animal name always starting with the same letter), and ever since 6.06 LTS (Dapper Drake), they've been sorted alphabetically, incrementing the first letter with every release. So even without any further information, you can easily work out that Raring Ringtail is 9 releases ahead of Intrepid Ibex.
A not very well publicised guideline is that the codenames are only supposed to be used before release, and the version number after release. If you go to ubuntu.com they consistently use the version number, not the codename.
Both Ubuntu and Android use alphabetically sorted release names that are dense - so it's equally easy to know if Ice Cream Sandwich comes before Jellybean (it's the release before), assuming you're not dyslexic (which I am).
My sound card "mostly" worked when I installed Linux this year. But I spent a week researching to finally deduce how to modify my Skype and Alsa configs by hand to get Skype to use the microphone. I still don't remember what I did, though it had to do with setting a specific hardware type id. Nobody should ever have to do that.
For watching movies or listening to music, the Linux audio system is fine, but ALSA and PulseAudio introduce unacceptable latency for game devs. For example the WINE developers are having major issues with PulseAudio's latency[1]
There are actually 2 low level audio stacks that apps can use in Linux, OSS and ALSA.
Only OSS offers great sound and low latency,[2] but the kernel developers have refused to add the free GPL'd OSSv4 updates into the kernel, so we are all stuck with OSSv3 legacy and ALSA's latency and poor design decisions. Using the PA layer only makes the latency situation worse and added another layer for things to go wrong.
I don't get this. When I play ioquake3 games I click my mouse, my gun fires, and I hear the gun firing sound. No latency.
Is the problem people trying to play sounds for games over the network with pulseaudio? Is that use-case really something that needs to be worried about?
My condolences. I also have that one and solved the problem by shoving a cheap second hand Creative SB Audigy in the PCI slot. And It still crackles and pops and messes up every time skype makes a sound.
Edit: to clarify, using a PCI soundcard solved the crackling and popping in every application except skype, which I find acceptable for now, since I don't usually talk on skype. I might experiment with using JACK and somehow routing pulse through that.
Yes, it really is. So many Linux users prefer OSS (Open Sound System) over ALSA because ALSA gives damn poor sound quality. Just search it and see how people gets disappointed with the sound quality of ALSA.
An unexpected bonus when switching to FreeBSD was that it still uses OSS, and like the rest of FreeBSD it all works - maybe not out of the box, but once you've configured it it will never just break for no reason - the way linux of 5-10 years ago used to.
Am on debian squeeze, and am not able to find out how to switch between soundcards as the default. Sure I can fire up VLC or Audacity and select within, but the default movie player picks the default sound card and I can't see a way to change it. A minor gripe, probably user error on my part. Also youtube etc use the default soundcard.
I've been fighting with audio on my Debian Squeeze system for a while,
but I now think I've finally gotten everything to work. One caveat --
I've yet to try a lot of music listening, so perhaps the addition of the
dmix-module does criple the sound a bit -- hard to tell as long as my
only other audio source is record player -- if my hi-fi cd player hadn't
died a while back an a/b test would've been easier.
Anyway, no pulseaudio, simple usb soundcard/dac based on Burr-Brown from
TI[1] - and now (software) mixing of audio works across youtube/html5
audio in iceweasel (21.0~b6-1 from
"deb http://mozilla.debian.net/ experimental iceweasel-beta"), vlc and
flash audio in chromium[2]. All that was needed in the end, was the
following ~/.asoundrc:
# Aliases for the devices. I don't use the onboard audio -
# terribly noisy. The names (after card) come from
# /proc/asound/cards - see [1]
pcm.nvidia { type hw; card NVidia; }
ctl.nvidia { type hw; card NVidia; }
pcm.usb { type hw; card DAC; }
ctl.usb { type hw; card DAC; }
# If all you want is use usb as default,
# uncomment this, and ignore the rest.
#pcm.!default pcm.usb
ctl.!default ctl.usb
# For software mixing - allowing several programs to play audio
# at the same time:
#dmix for software mixing - http://alsa.opensrc.org/Dmix
pcm.!default {
type plug
slave.pcm "dmixer"
}
pcm.dmixer {
type dmix
ipc_key 1024 # must be unique!
slave {
pcm "hw:DAC"
}
}
Now, I've also realized that the main reason I started fighting with
this, was the delay introduced by pulsaudio, which is only a problem for
me in vlc -- and that could've been fixed (probably) by using the
tools->Track synchronization menu options. Just in case anyone else has
synchronization issues.
I currently don't do any gaming (except for Angband...) -- or other
synchronization-sensitive multimedia.
[1] according to /proc/asound/cards:
0 [DAC ]: USB-Audio - USB Audio DAC
Burr-Brown from TI USB Audio DAC at usb-0000:00:0b.0-3, full speed
[2] Apparently html5 audio (at least in videostreams) is broken in
chromiumr. Flash video (from eg regular non-html5-youtube) works
fine for me with this set up. Some more details at:
http://code.google.com/p/chromium/issues/detail?id=178626
I'm sure there will be a GUI way to switch the default but I tend to use environmental variables when I want to launch a program out of a non-default device
>Is it possible to use/set environment variables to change the default ALSA device?
>you can use ALSA_PCM_CARD or ALSA_CARD to set the default card, either by name or by number. If both are set, ALSA_PCM_CARD takes precedence. The device on the card can be set in the variable ALSA_PCM_DEVICE.
>though if I'm not mistaken it's still the preferred solution for BSD and therefore often available as an option
I believe you are mistaken. The BSDs have always avoided all the freakish audio framework nonsense from linux land. They provide an API that is somewhat compatible with OSS to allow software with linuxisms like assuming OSS to function. That API is a wrapper around the real audio system: http://www.openbsd.org/cgi-bin/man.cgi?query=ossaudio&ap...
Yes, sound is still a problem. I tried to change window managers on My Ubuntu desktop and totally lost sound.
I am well past the age of my life where there is anything productive about spending hours of my day futzing with sound drivers. I know how drivers work. I'm not becoming any better at working with computers by deciphering this year's way of sound not working with Linux.
(It did work out of the box. I was getting sick and tired of Unity and tried to put something else in place. Everything went to shit at that point. Now I am back at Unity.)
What you probably did was switch from a 'desktop environment' to (just) a window manager. A desktop environment includes many processes that are started on login and run in the background (e.g. dbus, pulse-audio, ssh-agent, gpg-agent, gnome-power-manager, etc).
"I tried to change window managers on My Ubuntu desktop and totally lost sound." - Once you do something as drastic as changing the default window manager on a distro you are largely on your own.
In the past switching window managers would leave you without a network connection because Network Manager applet would begin after you login into gnome. However this appears to be fixed and was not an issue the last few times I tried.
Having said all of this, I wonder if its reasonable to expect a distro to handle the situation where you completely swap out the user land that they ship with. The equivalent does not exist for windows / osx.
Thats a huge failure of abstraction. File a bug. A window manager should manage windows not sound. Someone outside the linux community would have no idea that the thing that controls title bars also happens to control sound.
On Debian with ratpoison / awesome / KDE / probably others it "just works" and you don't control your sound with your window or whatever.
It would be like configuring your mouse by modifying your network settings or configuring your video card by modifying your joystick/gamepad settings.
Here in the real world a desktop environment like Unity is a whoe lot more than just a window manager. It includes system management and configuration GUI components, including preferences panes and utilities to control audio functions. Unity is trying to provide a comprehensive user interface to the entire OS, or as much of it as possible.
And look what an epic failure that paradigm has turned into. Much like swiss army knives have ended production of all other tools, etc.
No matter how good of a job you do going down the wrong path, fundamentally, you're still going down the wrong path.
I'm, sorry, are you suggesting that integrated GUI environemnts such as MacOSX, Windows (and I'd argue iOS and Android too), are epic failures? In contrast of course to the awesome, eternal empire of success that is the Linux desktop?
The epic fail is in some misguided areas of linux land tying the GUI background image renderer and program launcher to the sound driver such that they (supposedly) cannot be separated in practice although there is no technical reason why they shouldn't be separated. And that's considered anything other than an epic fail.
It would be like demanding if I install grub bootloader, the plain text grub config file may ONLY be edited by vi. Why not nano or emacs? Well we're trying to implement a consistent user experience by limiting user choice and ...
Its a creeping windows "all in one" design model, which is mostly awful. The opposite of the unix "do one thing really well" model.
If android did something that dumb I'd call it out, although I can't think of any example of equal fail level. Imagine if you're only allowed to edit the screen brightness (or autodetect screen brightness), if and only if, you install dogcatcher podcast player, because hey, doggcatcher is awesome, who can disagree with that. And if you remove ConnectBot app then the systemwide GPS/location system completely stops working, because, hey, why not? "I replaced my cell phone battery and that made the volume buttons stop working, because it makes logical sense to bind the two concepts together"
> Once you do something as drastic as changing the default window manager on a distro you are largely on your own.
That's crazy. When did Linux get so _fragile_?
A windows manager is the application that handles windows management. Applications (browser, word processor) don't care what WM is running, and neither should utilities.
Changing a WM is strait forward. Exit, run 'xwmconfig', then startx and I'm back in.
Maybe Slack has me spoiled, or something - are the so-called modern Linuxi really so crufty that changing a WM cripples the host?
Modern Desktop Linux is very fragile because everything has to be configured and managed automatically. You haven't been able to startx without a lot of reconfiguring for years.
Ideally you want a full Desktop environment, but at a minimum you need a session manager (for auto-starting everything else, communicating with the * kits, * buses, * agents, and * managers for device integration, etc . . .), a settings daemon (stores settings for applications that care to use it, might be more than one of these - Xfce has two or three at the moment), a desktop manager (like a WM but for desktops), a window manager, a compositor (for special effects, might be part of the WM), plus miscellaneous bars, launchers, and plugins for same.
It's perfectly possible to split all this up, but then you have to make all the parts compatible. Most distros want more integration, not less.
> Modern Desktop Linux is very fragile because everything has to be configured and managed automatically. You haven't been able to startx without a lot of reconfiguring for years.
I guess I don't know what a Desktop Linux from a hole in the ground.
I use Slackware on my desktop, and it works just fine. I can switch WM using startx.
I will allow that installing Slack is not a pointy-clicky exercise, and if the application isn't in Slack's package manager you'll need to compile from source but .. it's not that complicated.
I hope you know what Desktop Linux is. I don't care that you don't use a Desktop distro because I use Gentoo and XMonad and am generally quite comfortable with both.
As for complicated well, that depends - complicated for who? There are a lot of people who couldn't configure && make && make install if their lives depended on it. Even if their lives literally depended on it. That's not necessarily their fault, but there you are nonetheless.
Apparently I don't run desktop Linux either because I have no problems editing settings with a text editor, nor do I drool on myself when it comes to reading documentation.
>Modern Desktop Linux is very fragile because everything has to be configured and managed automatically. You haven't been able to startx without a lot of reconfiguring for years.
What distribution does not support startx out of the box. If you boot into terminal (or kill the X service), then startx should just do whatever the system does to start the X server anyway.
startx is a shell script. The vast majority of distributions don't use it at all - they use a display manager that then does most, but not necessarily all, of what the xinit system does (plus some extras, depending on the DM).
startx from a VT should give you an X server. You can get from there to a standard session (minus the DM) by setting the appropriate environment variables and making sure the right session manager is executed.
I don't call that 'no configuration' though. And if you want to startx into Fluxbox you also have to make sure that all of the aforementioned services are run (unless you're totally abandoning your Desktop environment, in which case this whole conversation is pointless).
When users expect everything to "just work", it means that automated configuration has to integrate with a ton of components, thus supporting alternatives for every section of the stack becomes a huge endeavour.
There are no magic elves and fairies lower down in the stack.
Reliable user experiences come from
a) Reducing degrees of freedom - remove the number of things the end user can tweak / change (the mac way)
b) Monopolistic fiat - Publishing standards and strong arming vendors into supporting those (the wintel way)
Linux tries to approximate reliability using a "many eyes make bugs shallow" approach. However this kind of reliability is stochastic. Think of it as a gaussian centered around the defaults that ship out of the box on hardware that is fairly commonplace. The more you push your end config away from that center the more likely it is that you will have a suboptimal experience.
You can switch away from it, you just can't do it with "apt-get install <new window manager>". Try a distro that is designed for the WM you want to use.
I agree that in an ideal world installing a new WM would "Just Work", but we don't live in that world. Try installing a new WM on OS X or Windows and see how well things go. Not trashing those operating systems, just pointing out that GNU/Linux does, indeed, offer more choice. The fact that the choices are not ideally convenient to switch between is really a fairly minor issue.
You have to be joking me. "A distro that is designed for the WM you want to use"?
What does that even mean? That I have to have a special twm distro? Or an fvwm2 distribution? tvtwm was always my favorite window manager, but I seem to recall it needed some patches to really be perfect. Do I have to find somebody to build me my own distribution that has those patches?
A Window Manager manages windows, like the name suggests; it doesn't manage networking or sound. And if it does, then the whole system has failed to produce decent engineering boundaries and we should revert a few releases to when things had the correct levels of abstraction.
I think part of the problem here is that window managers and desktop environments are being conflated.
Desktop environments are sometimes set up to handle sound or networking.
I agree that it's not a good design, but I don't think it's as ridiculous for a desktop environment to handle these things as it is for a window manager to do so.
Apologies, I was very much conflating WM and DE. However, you mentioned Unity, which is really both (Unity itself is a DE but it brings its own WM to the table and assumes that you will use it). My point was that if you insist on extensive customization, you should be prepared to do some work. If you don't want to spend a lot of time fiddling (I know I don't) then you find a distro that does things the way you want them done and you use it. Things are the same in the Windows and Mac world, for better or worse.
I think GP's point was that you either 'deal with it' or find someone else (a packager for a distribution) to deal with it on your behalf, if you are having issues then a distribution is a possible solution.
KDE doesn't provide sound, just like KDE doesn't provide graphics drivers. I'm not sure why you feel sound support should be a function of the desktop environment.
My opinion on what should be a part of what is irrelevant.
My post was regarding the fact that people blame Linux when the real problem is their own lack of understanding.
A good answer to the original question would be: "Sound is not a problem in Linux. However, compared to other operating systems, it might require additional understanding of the way things work, especially if you want to customize your system. This requirement of knowledge is a problem in distributions like Ubuntu - where the user base is 'everyday people'."
Phonon is not a mixer. Phonon is essentially a built-in adapter layer over whatever audio driver and media decoder libraries you already have.
It's a little more complex nowadays as it was substantially modified to be a good PulseAudio citizen when running with PulseAudio, but Phonon doesn't talk to hardware, it talks to sound libraries such as VLC, gstreamer, or PulseAudio.
Ubuntu 12.04: I managed to have Unity and XFCE working as alternative 'sessions' along with DWM (with a .desktop file pointing at a start up script for the latter). I recollect some issues about different sound applets changing configs but sound would work under all three sessions.
I now use an Ubuntustudio install (13.04 with the default XFCE desktop). Sound just works, and detected my three sound output devices fine, and allows me to choose which one to use.
I quite like Unity but the bugs around LibreOffice global menu integration in 13.04 (with the resulting loss of highlighting of menu choices and the lack of 'accelerator key' menu selection) means I'm sitting this release out.
Yes. My desktop has mostly just worked for a few upgrades now, but new versions on my HTPC running XBMCbuntu have been hit and miss and taken some screwing around with the sound.
I use Linux servers mostly, but about a year ago I installed openSuSE on two new desktops. The problem was that, while sound "worked" in general, only one application could use the sound card at a time. That means when you have your audio player open, Youtube won't work at the same time. You'd have to close both apps and then re-open the browser so it could then hog the audio.
The most annoying thing about this, however, were some of my desktop Linux friends who insisted this behavior was totally acceptable and not a bug.
"The most annoying thing about this, however, were some of my desktop Linux friends who insisted this behavior was totally acceptable and not a bug."
Bingo. Spot on, and you've hit the biggest meta-issue when discussing desktop Linux usability issues. There isn't an agreed upon definition for "acceptable" that everyone can use to determine if something is really broken or not. I hit the same issue years ago, complained on some forums, people told me it wasn't a problem, I was doing something wrong, etc. Finally someone grokked what I was describing, agreed that I would be reasonable to expect 2 apps to be able to play sound at the same time, but that it "wasn't a big deal" and "never bothered" him. For a server, yes. For a desktop environment, it's been unacceptable to me for years, and was a primary reason why I switched away from desktop linux for day-to-day work (after about 5 years of dealing with the ups and downs of desktop linux' evolution).
I've been running openSuSE desktops for years. When pulse became standard, I made a practice of ripping it out (rpm -e...). I've happily had plain ALSA sound with sound from multiple apps at once. No, I don't know the details - only that it works. YMMV.
This is absolutely unacceptable, and the main reason I still use a SoundBlaster Live instead of my onboard sound. The SBLive can do hardware mixing and the Linux driver makes this transparent, so even OSS programs can run simultaneously.
ALSA is supposed to be able to do this transparently (in software) with dmix, but in my experience that only works with ALSA-aware programs, not those using the OSS API. I don't care that on Linux OSS is deprecated: it should just work.
In short, Linux sound is still obnoxious unless you are lucky enough to have hardware mixing work, or you only use programs which properly deal with ALSA.
>I don't care that xxxx is deprecated: it should just work.
Setting aside the concept of extrapolating from a small sample size using an admittedly deprecated system (on apparently poor hardware) which hasn't seen any significant use this decade, to "Linux sound is still obnoxious"...
The temerity of insisting that any deprecated software work perfectly is appalling. I am sad to say that my imagination does not stretch so far as to envision a world where this was a reasonable expectation. The one small solace that I can bring away from your post is that such an attitude must engender its own punishment.
Most users tend to assume that things that work will continue working. This is not an unreasonable assumption. It is the status quo on Windows and, whether you or I like it or not (I don't really mind, but whatever), that's the measuring stick for Linux-on-the-desktop. That Linux does not have the same track record with regards to backwards compatibility is not a failing in the user. You don't have to fix their problem, but don't wax on about their "temerity". That makes you a dick.
As is common in pretty much every endeavor, people trump process. OSS still exists and for a decent bit of legacy software isn't going away anytime soon. Breaking it screws over users. Screwing over users makes them complain. Putting on a song and dance about how "appalled" you are at users' complaints makes you a jerk. Don't be a jerk.
Having dedicated hardware for sound mixing is always a good idea. This is especially noticeable when the CPU is under heavy load like when games are running.
The only way I was able to solve the cracking and latency issues on my Linux box was to replace ALSA with OSS. Recently some newer software is causing issues again and I might have to give ALSA another shot. Things would be so much better if the Linux kernel just adopted OSS4
Linux is already winning the OS wars, it's called Android ;-) Just being snarky, I get your point. I've said this before, and I think it is important to keep in mind when discussing GNU/Linux: things work quite well... on supported hardware.
The vast majority of tales of woe related to GNU/Linux and hardware end up coming down to incompatible hardware. This is a communication problem, not a technical problem. No one gets upset that OS X won't run on a random Acer netbook from 4 years ago because Apple has made clear that their OS is only supposed to work on their hardware.
GNU/Linux evangelists, on the other hand, have, in the past especially, had a tendency to sell their operating system as magical software that works on every machine always. This is, of course, totally false. When I buy a laptop I check several sources (including the Ubuntu Certified list) to make sure the machine I end up with will be fully supported, preferably with open drivers.
GNU/Linux evangelists, on the other hand, have, in the past especially, had a tendency to sell their operating system as magical software that works on every machine always. This is, of course, totally false.
It's not totally false; Linux will work on almost everything, most of the time. While I'll second the notion that you should really, really, really, really make sure that your hardware is supported before you buy the hardware, I think I can safely say that the range of driver support in the Linux kernel is unparalleled. The only other OS that even competes (and for that, only CPU architectures) is NetBSD. In my experience, if Linux doesn't support a piece of hardware out of the box, you had better dump that hardware, because brother, that hardware won't be supported by anything.
I think the distinction is that Linux can be made to work on almost anything - if you're willing to hunt through forums, edit config files, and on rare occasions compile a driver. And it might give you trouble, say, suspending and resuming. I doubt Windows is much better on a technical level, but then OEMs deal with choosing hardware and selecting drivers, so end users don't have to.
> It's not totally false; Linux will work on almost everything, most of the time.
For certain definitions of the word "work" :-). Much of the reputation GNU/Linux has for being wonky and difficult to use comes not from alpha hacker types, their systems work just fine, but from relatively ordinary people with work to do who were talked into installing "Linux" to escape malware, get access to more free software, speed up an old computer, etc. For these people, editing xorg.conf is an unacceptable pre-condition to using a computer. Is there anything wrong with that? Absolutely not (IMHO).
> In my experience, if Linux doesn't support a piece of hardware out of the box,
> you had better dump that hardware, because brother, that hardware won't
> be supported by anything.
In my experience, the hardware support/drivers, esp. video and wireless, is better in wintel front.
Sure, linux versions of those drivers usually give more power to user regarding configuration of device, but brother, I have never had to fiddle with driver configuration to get HW acceleration working for flash in windows. Just download and install video adapter drivers, install flashplayer, and it just works.
Not really. Regarding "usual" sound, I haven't had a problem for years now, and just a while ago I actually set up a fairly complex system with JACK for a music performance I was preparing (midi controllers each connected to a specific synth software, some of that straight to output, some of it to looper software first, along with the mic input, etc.) and I was surprised at how smooth it all went.
Linux sound hasn't been a problem for some of us for, oh, I don't know, well over 10 years (1999? 1998? I can't remember), and no, I'm not talking about "well I can write sound drivers, therefore it works for me, har har har!" I've never quite understood the problems people had, since I've always had Linux sound "just work" for me out of the box. Sure, back in the ISA bus days, you had to specify things like IRQs, but you had to do that on any OS where you had cards with hardware jumperable IRQs.
Pulseaudio, I thankfully didn't have to deal with until it was actually working, but it still struck me as very much an NIH solution in search of a problem. I still remember the Enlightened Sound Daemon with software mixing, and thought it was nifty, but not a hard requirement.
I don't know about now, but running Linux on a ThinkPad X41 a couple of years ago with suspend-to-RAM. After a fresh boot a sleep-wake will work twice before the auto switching between speakers and headphones quits. Hibernating and waking will fix it only for one sleep-wake cycle. A full reboot would fix it so that it would work for two more sleep-wake cycles.
I was fully willing to get my hands dirty with a little help (couldn't make heads or tails of the ALSA code), but Ubuntu just decided to shelf it into the 'leave it alone until everyone goes away' bucket on LaunchPad.
I know how frustrating it can be when your bug isn't getting attention, but I've also been on the other side of that. It's not like Ubuntu (or any project) has hordes of developers who're just too lazy to tackle your bug: maybe not many people have that model, or don't tend to switch between speakers and headphones much. Maybe people couldn't reproduce the bug, or maybe just no-one could see how to fix it.
There's a whole host of reasons why bugs don't get fixed, but it's rarely because the project as a whole 'just decided to shelve it'.
I realize that there are reasons, and I'm not necessarily angry at Ubuntu, but I've dealt with these types of issues before and it's frustrating. I had the ALSA source code and was ready to attempt some hardware hacking, but:
1) The chipset was a common one, and the issue specific to this model. I had no idea how to proceed from there.
2) I couldn't make heads or tails out of the structure of the code, and what was happening (or why). I tried to find some sort of "this is happening here" where I could work out the rest from there, but couldn't find it.
3) I volunteered myself on the bug page, but there was never a response to it.
4) I've never hacked on kernel code (beyond compiling it from scratch 'back in the day') or done any hardware hacking, but I was willing to look at resources if people pointed me in the right direction.
The project "as a whole" doesn't do anything with respect to specific bugs (there are exceptions), but the individuals that do take action, take that action on behalf of Ubuntu.
Perhaps the problem is that in large projects, many areas don't have someone who feels ultimately responsible for making sure each bug gets a response. It's very easy to glance over a list of new bugs and leave the ones you don't know anything about for someone else to tackle, but inevitably there are bugs that no-one really feels comfortable tackling. Hardware specific stuff is especially bad, because device interfaces do some crazy things, and only someone with the same model can investigate it.
Kudos for being willing to dive into the code, though, and I'm sorry to hear no-one offered advice with that.
Sound isn't a problem for me. I just use ALSA and everything works (I haven't edited a single configuration file, actually).
The sound-server wars are still ongoing but I've personally never had any cause to touch anything besides ALSA or OpenAL/SDL on the development side either. Other people may have different experiences.
More like "it depends" or maybe "if you want it to be". For the vast majority of basic use cases (listening to music using XMMS, Rhythmbox, Youtube videos, etc.) it usually "just works" with most recent Linux distros on most non-esoteric hardware. At least that's been my experience using that last 5 or 6 Fedora releases, on a variety of hardware.
Now, if you want to get into fiddling with JACK vs. PulseAudio and tweaking ALSA, etc., then you can get into some complicated shit, most of which I don't understand, which I why I just leave it alone. But, I'm not doing specialized audio production and editing stuff either. That's a whole different world, which I can't speak to at all.
Sound on Linux wasn't a problem 5 years ago. In fact, it wasn't a problem even earlier. I started using linux on a regular basis circa 2006 and never ran into any problems with sound. I used different distros (knoppix, ASPLinux, openSUSE, ubuntu, linux mint, arch) on different desktop machines and laptops. The worst problem I had was with winmodems that refused to work with anything but windows, but even that I was able to solve by installing some weird drivers.
For everyone claiming sound is a problem, there are dozens of users for whom it just works. Most of them are not passionate enough about sound to say it just works.
Yes, also problems with wireless/wired network card drivers and DVD playback are common. These are the kinds of things where you've just gotten them working, then you upgrade your distro and they stop working again. In theory they all probably work, even for your hardware, but getting the right versions of all the software necessary running at once on your machine is a pain.
It doesn't have anything to do with paying the people who work on Linux, it's that the manufacturers of these devices don't have a commercial interest in making their hardware work in 30 different Linux distributions. They do have an interest in their products working flawlessly on all versions of OS X and Windows, and so they do what it takes to make it happen.
Linux-based systems are great, but not when it comes to desktops where productivity is the point. They are good for desktops where tinkering and copyleft are the point. They are obviously a superior choice for anything that isn't a desktop.
OK, I'm curious: DVD playback is definitely a bit of a fiddle (mostly for legal reasons), and I've heard of wifi problems (although I understand most recent chipsets work)... but wired network drivers? I've never heard about problems with wired networking, and none of the computers I've installed Linux on has ever had a problem with it.
It was a Thinkpad from around 1999, and my ethernet stopped working after an Ubuntu upgrade, sometime around kernel 2.6.8 if I remember correctly. I'm sure there'd have been a fix if I'd found the right forum or IRC channel, but having lived through Gentoo and Debian installs, by then I had simply stopped caring. Apple was making fully functional Unix desktops, which is all I really cared about, so I went and got one and that was that.
Just to add my two cents here, two things... I'm using a Thinkpad X230 with Fedora 17. Everything was working pretty good, but one of the updates caused sound from VLC to have a lot of static for the first 30 seconds or so after waking from suspend. But only VLC -- no other apps were affected. I reverted to an earlier kernel, problem went away. Seems this was fixed after a couple months on another kernel update (or combination of kernel and VLC update).
Secondly -- I picked up a generic USB 5.1 sound card. All works well, except the center and subwoofer channels are switched. I've seen a few posts here and there on editing some PulseAudio configs, but they don't seem to apply to the version that Fedora 17 ships with. But the proper fix is to register this sound module in the "glitches" section of the appropriate Kernel driver, and have it swap the channel mappings there. Still working on finding which data structures the output channel maps are stored in -- if anyone here has worked with programming these kernel modules, let me know and I'll dig up where I left off.
I recently had trouble with my sound card on Arch Linux. Upon booting, once in a while, my default sound output would change and not work even after I'd edit it. Turns out it was my card model that wasn't supported and I just removed it. I've been working with the on-board output since then and everything is going just fine.
Yes. My current fun issue with PulseAudio is that volume control handling is broken in all sorts of interesting ways, especially with applications that try and change their own volume. Also it randomly stops playing sound correctly and has to be killed and restarted if I want to get it back.
It has worked for me on every system I've ever had, most of which have been laptops. Nowadays, I use Ubuntu, and nearly everything works out of the box on every system I have. Currently, the only issue is the backlight on a very new gaming laptop. I had to download and compile a third-party kernel module for that, which while not a big hassle for me is clearly unacceptable from a usability perspective.
I suggest that some of the problems people are having stem from using distros that either don't care about or have the resources to support desktop use.
For me it is. I had to uninstall pulseaudio to get sound to work at my Debian Wheezy machine. With alsa though it has worked without any problems. And yes, I am a lazy bastard who has not reported the bug.
It was. Before pulseaudio became the de-facto standard lots of people wouldn't even install an additional layer and use plain old alsa. Which meant you couldn't change the volumes of applications individually. You could have used artsd, esd, or something else, but the problem was that there shouldn't be 3 bad solutions to choose from. There should be one good solution.
I remember installing redhat 9 and having to configure my sound card driver manually for an old creative soundblaster about 10 years ago. Further, back in those days it was not at all obvious how to get Linux to even play an MP3 (I know, this is an audio encoding and not related to the audio subsystem, but my point is: it was hard. These days you just install a mainstream distro and mp3 codec is there.)
Linux has come a tremendous way in the last 10 years.
Don't you remember the nightmares? Editing Xorg.conf, and such? But wait, I remember when it was still called XF86Config. /me shudders
Today anyone can pop in an ubuntu dvd and be rolling in seconds with all hardware working (for a lot of systems*). Not long ago we had to research our hardware and hunt down solutions just to get a working machine.
Really. I just installed LM LXDE 11 on an ancient PC the other day that had a Soundblaster card covered in dust. Started up an MP3 and started plugging a 1/8" plug into holes on the back. When I got to the SB card, bingo. No install, no prefs ... just worked.
It's always been a morass of competing, incompatible sound servers and APIs. Coding up anything more trivial than "beep" that works on a wide variety of distributions is painful.
I don't even understand where this myths come from.
Linux "the kernel" switched 15 years ago from OSS to ALSA for drivers, ALSA has been backwards compatible with OSS since.
Gnome and KDE used to have their own user space sound servers (called EsounD and aRts) mostly to impement software mixing. They were completely replaced over 5 years ago by PulseAudio which is backwards compatible with both as well as applications using ALSA or OSS API.
You could code an application using OSS API and be compatible with the first release of linux that had sound. What problems do you have exactly with your beeps?
What does "just work" mean? I have a mythtv frontend that squirts its video out a HDMI and audio out of a optical fiber to the surround sound system. It would drive me crazy if sound came out of the horrible TV speakers instead of the surround sound system.
Two separate problems:
1) Default behavior where no change is the least surprising so at least that is OK.
2) Modify config where its obviously a fail if you can't figure out how to change the config.
For whatever its worth, if you use ALSA, mythtv is ALSA compatible, so I merely go into "config" "audio" and mess around with audio options to my hearts content.
Quickfix: Install pavucontrol. You can control on a per application basis which output to send audio to and move the stream on the fly.
It doesn't "Just work" in windows. Windows will set a default and send all audio to that device without any controls for moving audio from one output to another. I have to restart my browser if I want to move from watching netflix on my monitor to my TV.
For many years, the API incompatibility between OSS and ALSA made getting sound working at all was often a nightmarish task. There were a number of sound servers that tried to alleviate the problem, but they all used incompatible APIs and couldn't be used in parallel.
It was, and is, awful.
It's only very, very recently that PulseAudio has gotten to the point where it works most of the time, and it still has major unresolved problems.
And there are still programs that use the OSS and ALSA APIs directly. While it does work fairly well, there are still incompatibility issues with programs that use Pulse.
It's ludicrous to suggest that there are no problems.
It was a problem until Pulseaudio became good -- to my experience, that happened around the 2.0 release. And in a technical sense, it's still a problem, since ALSA contains so much useless complexity now that something like PA finally exists.
As a Java game engine developer, I can say it's still a problem with Java. Sound mixing will work or not depending on people's installed sound system, sound cards, Linux distro, and a plethora of other factors I don't understand (and apparently no one understands, according to forum searches).
And yes, I know most of you don't like Java, but this is still a problem that doesn't happen in any other OS (OS X is Unix and handles this fine).
I commonly use 3 machines where I want sound (work,home,laptop) running a variety of different distros (arch,debian,ubuntu) and sounds works for me in all of them, mostly alsa although ubuntu is pulseaudio.
In the 99% case it just works, the only config I have to do is for my external DAC and that requires a few line config file (telling alsa to default to using my DAC rather than the first card it finds)
Sound setup bad? Not compared to 5 or 10 years ago, no. During that period (I can guarantee!) both Win and OSX were ALSO -miserable- experiences. Swim 10 yards, gain a foot bad. Make music for 5 minutes, debug the system for 2 hours bad.
Do you have anything at all to back up this claim? Sound on Mac OS and OS X has always been an It Just Works™ experience, largely due to the tight integration between the hardware and the software (never any driver issues, etc).
Are you trolling? 5 to 10 years ago?! Windows 7 already came out 4 years ago. Windows XP is 12 years old, and audio already worked perfectly then. Hell, I can remember using Win 3.1 almost 20 years ago, and the audio there worked pretty well too, for the limited use cases the pc could handle.
Instead of the word "sound" I should have made clear that I was referring to professional audio, not PC-speaker quality sound. Unless you could afford a full-time technician, the hard- and software hurdles were formidable.
I think if sound was working on the Linux server estates of tens of thousands of servers that I have worked on, that would be a problem. I don't really see Linux as a desktop OS, but the attempts at making it one is quite valiant.
The new challenge in the embedded community is device tree apparently. Lots of gripes about arbitrarily changing something that worked. Printing continues to be painful, as does direct to framebuffer graphics.
Read the title of the article. GNOME relies on PulseAudio. If thinks break when you break a desktop environments expectations, it should not be surprising.
"Linux sound hasn't been a problem for some of us for, oh, I don't know, well over 10 years"
"Sound on Linux wasn't a problem 5 years ago. In fact, it wasn't a problem even earlier."
"Sound setup bad? Not compared to 5 or 10 years ago, no. During that period (I can guarantee!) both Win and OSX were ALSO -miserable- experiences."
"No, sound is not a problem on Linux. I wonder if it ever was actually."
"I don't even understand where this myths come from."
Another reason I gave up on Linux was all the denialists that insisted that everything works fine on Linux and that if it's not working fine for me then I must be doing something wrong.
I don't understand how one can come here and say "Not a problem" edgewise to so many comments saying "Yes, definitely". Never listen to a fanatic, I guess.
A lot of it probably stems from the use cases. Most Linux distros have the "out of the box" use case down. When people start to fiddle with it or push the limits, they increasingly change their tone. Nothing fanatical about it. Just different points of view.
I can state it simply. My laptop dual-boots into Linux Mint 14 and Windows 8. Both systems recognized the soundcard without any hassle. If I pick a random YouTube video (so not anything ultra fancy), the Windows 8 sound is phenomenal and Linux Mint sound is passable. And I'm not talking sound on the level of "The Great MP3 Bitrate Experiment"[1], I'm talking the quality of a Bose against airline freebie headsets.
You have that with any topic. If you want to be credible, investigate which percentage of people have problems. That is an interesting statistic.
Compare to this: You want to buy a new laptop. You'll see various complaints. Maybe even the same amount of complaints for company X and company Y. This doesn't at all indicate a problem. However, if company X has 0.1% laptop market share and company Y has 40% market share, I'd go for company Y (same amount of complaints vs bigger usage).
Or in other words: Suggesting "there is a problem" as well as "there is not a problem" is both useless. Loads of distributions use PulseAudio by default btw. :P
