"but I don't get why you're trying to play back a configuration file..."
Greetings, David -- yes, I was piping a textfile to the speakers, just to generate some noise (and prove whether they were working). One can omit those lines, or replace them with aplay /usr/share/sounds/alsa/Noise.wav but my favorite is this alternative -- espeak "I'll be back" The advantage of using aplay with a *known* filename (in the context of my script) is there are no dependencies; that's the reason behind it. "just running a 3.5+ ubuntu kernel (or 3.6+ upstream kernel) fixes this bug completely" Can you please put that in the read-me-first description? I actually looked for just such a phrase. I realize that it says FixReleased for Precise at the top, but the comments are confusing... you talk about backporting to the 3.5 kernel, but you also specify that as Quantal, then go on to mention that you *want* it in 12.04.2 -- without ever coming right out and saying that it in fact now is in 12.04.3 (and .2?). I suggest this sentence: "If you're suffering from... 1)... 2)... The easiest fix is to update your system to the latest 12.04.3+ updates, or alternatively a 12.10-or-later installation. If you have done so and still have problems, the workaround in comment#32 sometimes helps, but whether it does or not, please file a separate launchpad bug." https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1236965 I have filed another bug for my specific issues over here. As to the more general issue of making audio not suck: "Over 80% of audio bugs, including this one, are specific to the codec *configuration*, which is usually best described with the PCI SSID number or vendor+model. Bugs specific to a codec (Realtek ALC892) or controller chip (Intel ICH6) are much less common." Well... I have a relatively rare motherboard SSID... but still.... (alsa OR pulseaudio) ("alc 892" OR "alc892") ==>> 94 hits (alsa OR pulseaudio) ("1558:8000" OR "15588000" OR "0x15588000") ==>> zero hits Some rough back-of-the-browser calculations suggest that using the SSID as a key to debugging audio problems is rare, at the moment. Maybe it makes sense to start using it? If enough ubuntu people are aware of the SSID connection, and use it to debug their audio-related-difficulties, then launchpad search results specific to your motherboard or videocard would be much easier to locate. I'll go ahead and paste my SSID stuff here, into the bug... making my comment the NUMBER ONE HIT when googling. Not that I'm bragging or anything -- humble to the core, that's me. :-) https://wiki.ubuntu.com/Audio/SameHardware (explains which portions of the output below are pci_vid and pci_ssid.) $ cat /proc/asound/card*/codec#* | grep --before-context=4 --after-context=1 "Subsystem Id" Codec: Realtek ALC892 Address: 0 AFG Function Id: 0x1 (unsol 1) Vendor Id: 0x10ec0892 Subsystem Id: 0x15588000 Revision Id: 0x100302 -- Codec: ATI R6xx HDMI Address: 0 AFG Function Id: 0x1 (unsol 0) Vendor Id: 0x1002aa01 Subsystem Id: 0x00aa0100 Revision Id: 0x100200 $ lspci -vvnn | grep --after-context=1 "Audio device" 00:1b.0 Audio device [0403]: Intel Corporation 6 Series/C200 Series Chipset Family High Definition Audio Controller [8086:1c20] (rev 05) Subsystem: CLEVO/KAPOK Computer Device [1558:8000] -- 01:00.1 Audio device [0403]: Advanced Micro Devices, Inc. [AMD/ATI] Barts HDMI Audio [Radeon HD 6800 Series] [1002:aa88] Subsystem: CLEVO/KAPOK Computer Device [1558:8000] The webpage suggests manually *reading* through the output of these commands, hunting the ssid buried therein. I've added some grep to the commands, which reliably extracts the info... on English installs only. Won't work if your system is German/Japanese/Esperanto/other. I would modify the "wikipage" to show this trick, but it is immutable (sigh). A cleaner way to get these numbers: should there be a debug-tab in the sound-settings dialog-box, which gives the average enduser their specific SSID info, plus a ClickHereToCopyAlsaInfoReportToClipboard gui button? Let me rephrase that -- there *should* be such a thing. Do you feel like implementing it? If not, care to point me in the right direction? Reply via email if you wish. 'J wrote: _Do not see your microphone? (again with the hyperlink)_' "This backporting has already been done. ...I think this bug is not that much of an issue any more." Sure, what you say is true. But this bug WAS a problem, in the past. And my new bug, which I will file a separate bug report concerning, is also a problem. With the exact same symptoms. My point is, the current sound-settings GUI does not give the average enduser any clue when something is *wrong*. This can be a mismatch between what the pulseaudio layer believes is true versus what the alsa layer believes is true, or an assumption about hardware, or whatever. Yes, yes, I fully agree that the best approach is to fix the bugs at their root. I'd *also* like to have a dynamically-auto-updated helpstring in the sound-settings dialog-box, plus a debug-tab, to help speed that up. In my situation, I *knew* the box had internal speakers... but I did not know that pulseaudio could fail to recognize them! They were showing up in alsamixer, after all. Then, to report the bug, I had to figure out how to generate alsa-info, and all that jazz. Not impossible... but not very easy, either. I'm savvy, so the hard part for me was figuring out what the heck was going on. The only reason I finally stumbled across this bug-report, with the workaround that helped my issue, is because I read your 2011 paper on the design of the alsa stack, and noticed it said you were planning to make some changes to pulseaudio that would HIDE DEVICES, and then plugged your name plus pulseaudio into the interwebs... this bug report is hit#2. :-) Obviously, that is *not* the preferred way to debug audio. I see that you wrote a nice blog post about six months ago, on how NOT to debug audio. I saw plenty of advice to fiddle with model-strings, hand-compile ALSA drivers, purge pulseaudio. *Modern* advice, not just the older advice still hanging around to fallback to OSS. http://web.archive.org/web/20121007001709/http://voices.canonical.com/david.henningsson/2012/07/13/top-five-wrong-ways-to-fix-your-audio/ (Side note -- your blog shows up blank in Firefox on Ubuntu 12.04.3 when visiting the URL directly... maybe I should file this bug also? Blogtext is visible here -- http://voices.canonical.com/user/128/ -- but comments are only visible in archive.org, and not for all posts.) But where is your post saying what *to* do in order to debug audio? This official helpdoc is definitely not at all what I'm after -- https://wiki.ubuntu.com/DebuggingSoundProblems It tells me to manually verify whether things are muted. Doesn't pulse audio already know that? It tells me to manually verify whether things are plugged in. Doesn't jack-sense already tell us that? It tells me that my first step, if I *think* that I possibly *might* have an audio bug, is to run ubuntu-bug -s audio ... skipping DIY troubleshooting, skipping volunteer-forum-support, and going straight to the devteam. That all seems wrong to me. We have eclipse/xdebug/gdb for debugging buggy code. Where is the visual equivalent for debugging buggy audio? You mention in the comments on your post that it is difficult to DTRT in the audio world, because there is so much hardware diversity (my own case with "unusual hardware" being a clear example of same). What I'm suggesting is that, because of the inherent problem that the audio stack is complex, and the buggy^H^H^H^H^H diverse hardware drivers are seemingly endless, we are *guaranteed* to have people suffering from audio bugs, until and unless ubuntu bug#1 is really and truly resolved. I don't see much hope for ending binary-blob drivers, and even worse, binary-blob firmware, in the next five years. I do see that ubuntu is trying valiantly to increase the number of Linux devices in both the desktop and the mobile space, during the next five years. Conclusion, the audio stack will be buggier than ever, no matter how hard you try to DTRT in your code. (btw I fully sympathize with you here... fixing the way pulseaudio deals with aggregating alsamixer into a clean gui interface was totally necessary... but this bug was *bound* to happen) So, instead of putting the focus on trying to make the audio DTRT in an endlessly-changing sea of buggy hardware, I suggest we put some effort into making the debugging of audio problems far more straightforward. So endeth the rant. Sorry to overflow your inbox. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/946232 Title: [Meta-bug] Missing speaker and/or internal mic port To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/946232/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
