© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
0e1f616
(Get the code!)
"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/
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:/
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-
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:/
(explains which portions of the output below are pci_vid and pci_ssid.)
$ cat /proc/asound/
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/
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 ClickHereToCopy
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-
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://
(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://
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:/
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-
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.