4 ms·

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

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.

pyre 14y ago
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.
- takluyver 14y ago
  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'.
  - pyre 14y ago
    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.
    - takluyver 14y ago
      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.

pyre 14y ago

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.

takluyver 14y ago
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'.
- pyre 14y ago
  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.
  - takluyver 14y ago
    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.