[opensuse-factory] horrific sound configuration process in TW
more than 5 hours trying success after success on same machine in 13.1 13.2 42.1 Mageia 5 Only in Mageia was sound actually easy to configure (via MCC). 42.1 was only slightly harder (via YaST2). 13.2 was quite hard, required replacing phonon-backend-vlc with phonon-backend-gstreamer. 13.1 wouldn't work either, seemed to have same only temporarily and only in yast2 behavior/obstacle as TW until after replacing phonon-backend-vlc with phonon-backend-gstreamer and a reboot. I tried TW for a while without Packman enabled, later enabled it to try to install SMPlayer and VLC. At first I excluded all *pulse*. In desktop settings -> phonon audio & video, the only sound device listed is default, no mention of any intel device as in other releases or yast2. Deleting Intel 82801G (ICH7 Family) AC'97 Audio Controller (rev 01) and re-adding it either quick or normal in YaST2 always produces sound when configuring, but it doesn't survive reboot, and never works in K*5 or SMPlayer. Eventually I tried advanced, including a click on reset, instead of quick or normal, and it has stuck so far through two reboots. One possible clue: nothing providess libdbus-1.so.3(LIBDBUS_1_3)(64bit) needed by vlc-noX-2.2.1-299.1.x86_64, which remains even after getting KDE to produce sound. SMPlayer still plays video only. :~( https://en.opensuse.org/SDB:Audio_troubleshooting is ancient. Selected rpms installed: alsa-1.1.0-1.1.x86_64 alsa-firmware-1.0.29-1.1.noarch alsa-oss-1.0.28-3.3.x86_64 alsa-plugins-1.1.0-1.1.x86_64 alsa-plugins-pulse-1.1.0-1.1.x86_64 alsa-utils-1.1.0-1.2.x86_64 dbus-1-1.8.20-1.1.x86_64 dbus-1-glib-0.104-1.2.x86_64 dbus-1-python-1.2.0-6.5.x86_64 dbus-1-python3-1.2.0-6.5.x86_64 dbus-1-x11-1.8.20-1.1.x86_64 gstreamer-0_10-0.10.36-18.3.x86_64 gstreamer-0_10-plugins-base-0.10.36-13.1.x86_64 gstreamer-1.6.1-1.1.x86_64 gstreamer-plugins-base-1.6.1-1.1.x86_64 kdbusaddons-tools-5.16.0-1.1.x86_64 libdbus-1-3-1.8.20-1.1.x86_64 libdbus-1-3-32bit-1.8.20-1.1.x86_64 libdbusmenu-qt2-0.9.2+14.04.20131209-3.3.x86_64 libdbusmenu-qt5-2-0.9.3+15.10.20150604-1.1.x86_64 libgstreamer-0_10-0-0.10.36-18.3.x86_64 libgstreamer-1_0-0-1.6.1-1.1.x86_64 libpulse0-7.1-1.1.x86_64 libpulse-mainloop-glib0-7.1-1.1.x86_64 phonon-backend-gstreamer-4.8.2-2.1.x86_64 pulseaudio-7.1-1.1.x86_64 ruby2.1-rubygem-ruby-dbus-0.11.0-4.3.x86_64 ruby2.2-rubygem-ruby-dbus-0.11.0-4.3.x86_64 system-config-printer-dbus-service-1.5.7-5.1.noarch -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/
On Mon, 07 Dec 2015 09:05:03 +0100, Felix Miata wrote:
more than 5 hours trying success after success on same machine in
13.1 13.2 42.1 Mageia 5
Only in Mageia was sound actually easy to configure (via MCC). 42.1 was only slightly harder (via YaST2). 13.2 was quite hard, required replacing phonon-backend-vlc with phonon-backend-gstreamer. 13.1 wouldn't work either, seemed to have same only temporarily and only in yast2 behavior/obstacle as TW until after replacing phonon-backend-vlc with phonon-backend-gstreamer and a reboot. I tried TW for a while without Packman enabled, later enabled it to try to install SMPlayer and VLC. At first I excluded all *pulse*.
Why? Doing this already makes things hard. The setup without PA is only for experts who know what they are doing :)
In desktop settings -> phonon audio & video, the only sound device listed is default, no mention of any intel device as in other releases or yast2.
Deleting Intel 82801G (ICH7 Family) AC'97 Audio Controller (rev 01) and re-adding it either quick or normal in YaST2 always produces sound when configuring, but it doesn't survive reboot, and never works in K*5 or SMPlayer. Eventually I tried advanced, including a click on reset, instead of quick or normal, and it has stuck so far through two reboots.
YaST setup is only for the kernel module. If it works for root (or in YaST test sound), it's fine. The rest is the problem of upper layers. Takashi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 7 December 2015 at 09:05, Felix Miata
<SNIP>
Felix, Is this a bug report? I do not see a single question mark in the email, so I suspect this is the case If so, then I have some advice for filing a good bug report TITLE: Keep your bug report title as professional, technical, and precise. Do not use words like "horrific" which is a statement of opinion, not a matter of fact. Such emotional language is likely to annoy the person who's working on the area you want fix, so ultimately the choice of language will make it *less likely* that they want to help you BACKGROUND INFO: Include details about your system. This is especially true when reporting bugs that are already covered by openQA (and Audio Playback already is). In those cases you need to explain what is different about your system from openQA and everyone elses systems that are working fine. So details about your hardware, such as the exact video card you have, should be considered mandatory. Comparing the video card you actually have with the one detected by YaST might be a helpful troubleshooting step. DETAILED DOCUMENTATION: Explain, in detail, everything you have done that makes your installation different from a default. You accomplished this to some degree in your email ("At first I excluded all *pulse*") but such details should be made clear, ideally bullet points, not just throw into the mix. In this case I also suspect you've added additional repositories (as your problem seems to actually be codec related, not audio related, I suspect you've added packman) - such steps are very important to mention. And last, but most certainly most important FILE YOUR BUGS IN BUGZILLA - This is a mailinglist, for discussions. If this email is a bug report, and I see no reason to suspect it as something else, it has no place here and should be filed as a bug in https://bugzilla.opensuse.org If you didn't intend for this email to be seen as a bug, but as a prompt to start a conversation I'd recommend a totally different writing style, especially the following TITLE: Productive discussions don't start by someone declaring something as 'horrific'. "Confused with TW Audio Configuration" would have been a much more enticing title for a call for help and discussion LESS DETAIL: If you want to start a discussion, we don't need to see your package list. This isn't a bug report. Keep the details relevant, and maybe refer to your bug report with the details. Otherwise keep the message on point - what are the key issues, what are your thoughts, what are you questions? ASK QUESTIONS: You're not going to trigger a meaningful conversation with shouting loudly declaring the state of something is bad. Ask questions about the reasoning behind it, try and learn more about the situation, give suggestions as to how we can make it better. This is opensuse-factory, not opensuse-soapbox ----- And now, regardless of your intent of your email, I will respond in the best way I can
At first I excluded all *pulse*
So, it looks like you broke it. Don't you think there is a reason pulseaudio is the default audiostack in openSUSE? Have you tried this without removing it? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Richard Brown composed on 2015-12-07 12:04 (UTC+0100):
Felix Miata wrote:
Is this a bug report?
No. It's not a problem that seems reasonably succeptible of a repeatable reproduction scenario required of a useful bug report. I did get some sound eventually, but not across the board.
I do not see a single question mark in the email, so I suspect this is the case
It's more akin to a review, but heavily colored by the frustration of 5+ hours of rebooting, searching, trying this, trying that, and accomplishing little in the context of having reached success in well under an hour on the same machine multiple elsewheres than in TW. If I had to describe the problem in as few characters as possible, I would have to include the string "broken deps". Success in 4 other distros proves hardware is not a problem. Process seems to be two problems: 1-YaST2 configuration doesn't stick. YaST2 only plays a test sound immediately after using it to configure the sound device. Once YaST2 sound has been exited, it is incapable of playing a test sound until having deleted the sound device and then adding it back. Last night's was not my first observation of this phenomenon either, as I recall it happening several times dating back too far to remember, probably several years. 2-No comprehensive sound configuration utility. Takashi responded "YaST setup is only for the kernel module." Why is that? Overcoming above is complicated by an ostensible help page https://en.opensuse.org/SDB:Audio_troubleshooting on which most recent release in a list of releases to which applicable is the four-year-old, long-out-of-support 12.1.
...Do not use words like "horrific" which is a statement of opinion, not a matter of fact.
Horrific is an experience, an observation, considerably worse than merely unfortunate or bad.
BACKGROUND INFO: Include details about your system. This is especially true when reporting bugs that are already covered by openQA (and Audio Playback already is). In those cases you need to explain what is different about your system from openQA and everyone elses systems
Speaking of QA, how does a (TW) release user relate whatever openQA is to problem solving? https://en.opensuse.org/Special:Search for openqa doesn't turn up anything among the 6 hits that looks helpful.
that are working fine. So details about your hardware, such as the exact video card you have, should be considered mandatory. Comparing the video card you actually have with the one detected by YaST might be a helpful troubleshooting step.
I'm pretty sure the OP attachment included all relevant hardware info. You're complaining by your overall response both about too much detail and too little detail.
DETAILED DOCUMENTATION: Explain, in detail, everything you have done that makes your installation different from a default. You accomplished this to some degree in your email ("At first I excluded all *pulse*") but such details should be made clear, ideally bullet points, not just throw into the mix. In this case I also suspect
After such a lengthy frustration period, details and recollection fade away.
you've added additional repositories (as your problem seems to actually be codec related, not audio related,
Really? Basic sounds from KDE require codec(s) that don't get pulled via dep chain?
I suspect you've added packman) - such steps are very important to mention.
I did write that both PA and Packman were added only later in the process. Total repo count is 8, among which optional only libdvdcss, 3 mozillas and lastly packman, as written, added late in the process (to see if adding the AV apps would force installation of missing deps).
And last, but most certainly most important
FILE YOUR BUGS IN BUGZILLA - This is a mailinglist, for discussions.
Bugs are supposed to be filed for single issues. Until a problem is broken down to a single issue with reproduction scenario, it doesn't belong in BZ.
If this email is a bug report, and I see no reason to suspect it as something else, it has no place here and should be filed as a bug in https://bugzilla.opensuse.org
Again, I file bugs when I can reproduce a specific problem at will. More nebulous problems are best taken to discussion lists for comment, to flesh out, to isolate.
TITLE: Productive discussions don't start by someone declaring something as 'horrific'. "Confused with TW Audio Configuration" would have been a much more enticing title for a call for help and discussion
Being tired has its effect. Does one compile and send what one can remember before more time passes trying to recuperate and more is forgotten?
LESS DETAIL: If you want to start a discussion, we don't need to see your package list. This isn't a bug report. Keep the details relevant,
More often problems come to mailing lists absent sufficient detail. I try not to do that. When tired, reducing details to only those relevant (trimming) becomes its own problem.
...This is opensuse-factory, not opensuse-soapbox
TW morphed opensuse-factory into a user list. Sometimes soapboxing happens in user lists, where it hopefully draws some useful discussion, possibly even help.
And now, regardless of your intent of your email, I will respond in the best way I can
At first I excluded all *pulse*
So, it looks like you broke it.
"At first" means what it says. Pulseaudio was added before OP. I don't believe _I_ "broke" anything. The installation was built up from a minimal X install. PA was not prevented from being installed. Anything that depends on *pulse* should have been pulled in automatically when that thing was installed.
Don't you think there is a reason pulseaudio is the default audiostack in openSUSE?
Where does anything doc that that is the case? I have no knowledge what makes up an audio "stack". All I "know" is that AV is built from an incomprehensible combination of components with names like OSS, AVC, PCM, ALSA, Pulse, codec, H.264, MPEG and many more. For years I've been reading in FOSS user forums that when audio fails, eliminating PA is often a magic bullet. So (only initially) I tried not having it (KISS), and only after not having it failed, and nothing requiring "it" pulled it in as dependency, I specifically added "it".
Have you tried this without removing it?
But "it" (whatever makes "it" up) never was "removed". Tried this what exactly? Is there some GUI tool missing in between YaST2>Hardware>Sound and (KDE)SystemSettings/ConfigureDesktop>Multimedia>AudioPlayback? Apulse, pulseaudio-utils, pulseaudio-system-wide are among the not installed packages (absent from my installed packages list) - are any of them required for KDE and/or SMPlayer to make sound? If so, my trouble smells like dep breakage. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hi again,
On 7 December 2015 at 20:10, Felix Miata
...Do not use words like "horrific" which is a statement of opinion, not a matter of fact.
Horrific is an experience, an observation, considerably worse than merely unfortunate or bad.
My advice stands - if this is a bug report, or a review for discussion, starting it with 'horrific' in the title is not going to endear either a maintainer to fix the bug(s) for you or the community to discuss your observations in a positive manner. It's good advice, I implore you to follow it.
Speaking of QA, how does a (TW) release user relate whatever openQA is to problem solving? https://en.opensuse.org/Special:Search for openqa doesn't turn up anything among the 6 hits that looks helpful.
that are working fine. So details about your hardware, such as the exact video card you have, should be considered mandatory. Comparing the video card you actually have with the one detected by YaST might be a helpful troubleshooting step.
I'm pretty sure the OP attachment included all relevant hardware info.
It's bad practice to send attachments to a mailinglist - and in my case I filter them all out as a force of habit.
You're complaining by your overall response both about too much detail and too little detail.
Correct. For a 'review' or a 'point of discussion' I think your original post was excessive in detail and actually neglecting to make any point, or raise any questions, bit of a dead end really As a bug report, it's missing sufficient detail - you admit this yourself "After such a lengthy frustration period, details and recollection fade away."
Being tired has its effect. Does one compile and send what one can remember before more time passes trying to recuperate and more is forgotten?
If you do not have sufficient detail to make a mailinglist post that conveys what need to be conveyed, then my advice is to not make a mailinglist post.. anything else is wasting everyone's time here.
The installation was built up from a minimal X install. PA was not prevented from being installed. Anything that depends on *pulse* should have been pulled in automatically when that thing was installed.
If you wanted a working KDE desktop installation, why didn't you install the KDE option during install? Starting from Minimal X and manually stepping up from there is exactly the kind of important detail that was lacking in your original post. Now it's important that you list exactly how you added stuff after your Minimal X installation. Which patterns? Exactly which repositories were installed before you picked those patterns? Those details are important. If you don't have them, then this thread is as much of a waste of time as an insufficient bugzilla entry would be (and I agree, it does seem that you're lacking sufficient information for a bugzilla entry)
...This is opensuse-factory, not opensuse-soapbox
TW morphed opensuse-factory into a user list. Sometimes soapboxing happens in user lists, where it hopefully draws some useful discussion, possibly even help.
Tumbleweed has enabled and does encorage more people to read and use these lists. That doesn't excuse posts like yours, which do not follow good principles like the ones I shared in my original, which start with emotional statements, are missing key details, and ultimately are lacking in a point. In fact, it makes posts like your original one more problematic, it's not just your time and developers time you're wasting, but all the additional people who now use this list. It's more important than every that everyone takes the individual responsibility to ensure that their mailinglist traffic to this list is relevant to all of the users on this list. This is the mailinglist for technical discussions regarding the development of Tumbleweed and Leap. Your post had significant flaws which turns it into a rant, instead of potentially a productive start of a useful conversation. I have given you advice to change that. Instead you have chosen to waste everyones time even more and argue every point with me. Please think again and realise that posts like your original don't really help, and take my advice so your next ones can be useful. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Richard Brown composed on 2015-12-07 21:06 (UTC+0100):
This is the mailinglist for technical discussions regarding the development of Tumbleweed and Leap.
Where does non-development user of Tumbleweed discussion belong? TW quesions on the opensuse list get chastized for not being sent here. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
* Felix Miata
Richard Brown composed on 2015-12-07 21:06 (UTC+0100):
This is the mailinglist for technical discussions regarding the development of Tumbleweed and Leap.
Where does non-development user of Tumbleweed discussion belong? TW quesions on the opensuse list get chastized for not being sent here.
At the beginning of Tumbleweed it was announced here that this forum shoud be used to discuss "Tumbleweed", not opensuse list, and I have never seen any announcement otherwise. And it was not limited to "development" discussion, although by it's very nature discussion of Tumbleweed is about it's development. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535 @ http://linuxcounter.net -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hey, On 08.12.2015 03:16, Felix Miata wrote:
Richard Brown composed on 2015-12-07 21:06 (UTC+0100):
This is the mailinglist for technical discussions regarding the development of Tumbleweed and Leap.
Where does non-development user of Tumbleweed discussion belong?
Like always opensuse@opensuse.org and it's language siblings. I have made this a tad more clear in the descriptions on http://lists.opensuse.org
TW quesions on the opensuse list get chastized for not being sent here.
They shouldn't be. Henne -- Henne Vogelsang, Mailinglist Admin http://www.opensuse.org -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Mon, 07 Dec 2015 20:10:57 +0100, Felix Miata wrote:
Richard Brown composed on 2015-12-07 12:04 (UTC+0100):
Felix Miata wrote:
Is this a bug report?
No. It's not a problem that seems reasonably succeptible of a repeatable reproduction scenario required of a useful bug report. I did get some sound eventually, but not across the board.
I do not see a single question mark in the email, so I suspect this is the case
It's more akin to a review, but heavily colored by the frustration of 5+ hours of rebooting, searching, trying this, trying that, and accomplishing little in the context of having reached success in well under an hour on the same machine multiple elsewheres than in TW.
If I had to describe the problem in as few characters as possible, I would have to include the string "broken deps". Success in 4 other distros proves hardware is not a problem.
Process seems to be two problems:
1-YaST2 configuration doesn't stick. YaST2 only plays a test sound immediately after using it to configure the sound device. Once YaST2 sound has been exited, it is incapable of playing a test sound until having deleted the sound device and then adding it back. Last night's was not my first observation of this phenomenon either, as I recall it happening several times dating back too far to remember, probably several years.
Usually you don't need to configure via YaST nowadays. Rather better to avoid it as much as possible.
2-No comprehensive sound configuration utility. Takashi responded "YaST setup is only for the kernel module." Why is that?
Because it's the only thing you can set up commonly in the system level. All the rest depends on your DE and your choice of sound backend setup, including the choice of packages and the choice of plugins.
Overcoming above is complicated by an ostensible help page https://en.opensuse.org/SDB:Audio_troubleshooting on which most recent release in a list of releases to which applicable is the four-year-old, long-out-of-support 12.1.
Right, the documentation should be updated. The generally often seen problem is: people who have used PCs for long time tend to want more detailed controls, and started configuring the system unnecessarily. Then it screws up things easily. In your case, excluding PA, fiddling the system-level sound setup via YaST, then shuffling the sound layer setups...; no surprise that it doesn't always work flawlessly. Look at the graphics setup. Few people fiddle with xorg.conf today. Most of graphics setups are done in a more dynamic way instead. The similar trend is found for sound setup, too. You *shouldn't* change the system setup unless you know what you're doing. This is the way many DEs want / try to go. Instead, the sound setup is done in an upper level, typically in PulseAudio, then covered by more APIs on it like gstreamer, phonon, etc. Yet, there are a few basic DEs that don't cover in such a way and let the system all done. Of course, on such DEs, you'll have to set up everything manually, and old kludges are still useful. An old-school grumpy developer like me still prefers this way, and some in-detail documentation might help. But, this is totally different knowledge from what other people need for a normal sound setup. So, again, the documentation should be updated: but to a direction to minimize the need for any changes. If you start modifying something, it's already out of the scope and it's at your own risk. If you had to change anything to make something working, it's safer to report at first before screwing up. Takashi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Takashi Iwai composed on 2015-12-07 21:35 (UTC+0100):
Felix Miata wrote:
Usually you don't need to configure via YaST nowadays. Rather better to avoid it as much as possible.
IME, this is often the case, but hardly universal. Unfortunately when sound doesn't "just work", getting it to work is commonly an unduly frustrating ordeal.
2-No comprehensive sound configuration utility. Takashi responded "YaST setup is only for the kernel module." Why is that?
Because it's the only thing you can set up commonly in the system level. All the rest depends on your DE and your choice of sound backend setup, including the choice of packages and the choice of plugins.
Why is it in cases where sound does not "just work", is YaST2 (often) incapable of producing a test sound except in the process of initially configuring it? This happens to me time and again, in different releases dating back years, and on different hardware, though nearly always Intel chipset motherboards with onboard Intel sound device (typically using snd-intel8x0 driver on a business Dell PC Optiplex line model). In the current TW, 13.2 and 13.1 cases (not that preciptating thread's OP), again as observed many times past, going through "Advanced setup with possibility to change options", on reaching "Settings for sound card", volume's initial level is 0. Why would 0 ever be the initial value on a previously "unconfigured" sound device?
In your case, excluding PA, fiddling the system-level sound setup via YaST, then shuffling the sound layer setups...; no surprise that it doesn't always work flawlessly.
I never "excluded PA". I simply did not choose to install it, and nothing requiring it required it be installed. Only later I took the trouble to add it myself, unfortunately without changing results.
Look at the graphics setup. Few people fiddle with xorg.conf today. Most of graphics setups are done in a more dynamic way instead.
The similar trend is found for sound setup, too. You *shouldn't* change the system setup unless you know what you're doing. This is the way many DEs want / try to go. Instead, the sound setup is done in an upper level, typically in PulseAudio, then covered by more APIs on it like gstreamer, phonon, etc.
I don't see how "upper layers" can be expected to be successful regardless of choice of "upper layers" if YaST2 can't produce sound more than during initial configuration of the only sound device. FWIW, a possibly related problem I frequently encounter is some failure or another requires a forced reboot. CAD commonly fails to force the reboot, with flooding/repeated messages whild holding down "failed to store sound card state". -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Thu, 10 Dec 2015 07:47:20 +0100, Felix Miata wrote:
Takashi Iwai composed on 2015-12-07 21:35 (UTC+0100):
Felix Miata wrote:
Usually you don't need to configure via YaST nowadays. Rather better to avoid it as much as possible.
IME, this is often the case, but hardly universal. Unfortunately when sound doesn't "just work", getting it to work is commonly an unduly frustrating ordeal.
Right, and as you noticed, it's not universal at all. Sometimes tweaking via YaST sound module helps magically, but it's not the right solution in most cases. So, please don't advertise it as a generic way to fix everything.
2-No comprehensive sound configuration utility. Takashi responded "YaST setup is only for the kernel module." Why is that?
Because it's the only thing you can set up commonly in the system level. All the rest depends on your DE and your choice of sound backend setup, including the choice of packages and the choice of plugins.
Why is it in cases where sound does not "just work", is YaST2 (often) incapable of producing a test sound except in the process of initially configuring it?
Why? A simple answer: a possible bug there, what else? :)
This happens to me time and again, in different releases dating back years, and on different hardware, though nearly always Intel chipset motherboards with onboard Intel sound device (typically using snd-intel8x0 driver on a business Dell PC Optiplex line model).
An old machine like this might be problematic with the modern configuration, unfortunately, indeed. But, you can't apply your story as a generic case. Look around how many people are still using this old chipset. And you may better blame people who defined AC97 standards...
In the current TW, 13.2 and 13.1 cases (not that preciptating thread's OP), again as observed many times past, going through "Advanced setup with possibility to change options", on reaching "Settings for sound card", volume's initial level is 0. Why would 0 ever be the initial value on a previously "unconfigured" sound device?
It's the kernel driver's default, and it's the safest value, not to break loud speakers. Which is safer than this?
In your case, excluding PA, fiddling the system-level sound setup via YaST, then shuffling the sound layer setups...; no surprise that it doesn't always work flawlessly.
I never "excluded PA".
You wrote it: "I tried TW for a while without Packman enabled...(snip). At first I excluded all *pulse*. In desktop settings...."
I simply did not choose to install it, and nothing requiring it required it be installed.
OK, then please write more correctly at the next time.
Only later I took the trouble to add it myself, unfortunately without changing results.
Yes, this often causes a trouble, especially in the older distros. BTW, which DE are you testing at all? This was never clear, and without that information, it's impossible to advice or debug. I thought KDE on TW requires PA, but it seems like my wrong memory.
Look at the graphics setup. Few people fiddle with xorg.conf today. Most of graphics setups are done in a more dynamic way instead.
The similar trend is found for sound setup, too. You *shouldn't* change the system setup unless you know what you're doing. This is the way many DEs want / try to go. Instead, the sound setup is done in an upper level, typically in PulseAudio, then covered by more APIs on it like gstreamer, phonon, etc.
I don't see how "upper layers" can be expected to be successful regardless of choice of "upper layers" if YaST2 can't produce sound more than during initial configuration of the only sound device.
You misunderstand. If YaST could produce the sound initially, then it works in that level. The fact that the modified volume setup isn't restored means just that a wrong volume setup is restored instead. It's just a matter of volume setup (or in the case of PA, it might be routing or else), usually, and it has nothing to do with YaST directly. Do you see the same problem when you reboot in runlevel 3 *right after* the initial YaST setup without any GUI? This excludes the influence on the setup by DE. If this works, OTOH, the remaining problem is in the upper layer.
FWIW, a possibly related problem I frequently encounter is some failure or another requires a forced reboot. CAD commonly fails to force the reboot, with flooding/repeated messages whild holding down "failed to store sound card state".
This is likely an old bug that has been addressed recently. If this still happens on Leap or TW, please file a bug report. Takashi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Takashi Iwai composed on 2015-12-10 09:42 (UTC+0100):
On Thu, 10 Dec 2015 07:47:20 +0100 Felix Miata wrote:
BTW, which DE are you testing at all? This was never clear, and
OP referred to kdbusaddons-tools-5.16.0-1.1.x86_64, K*5 and phonon-backend-* in TW context, which I thought made it clear enough I'm a KDE user.
without that information, it's impossible to advice or debug. I thought KDE on TW requires PA, but it seems like my wrong memory.
Including other machines with same problem, all DEs I use have apparently identical trouble: KDE3 (on gx28x TW) KDE4 (other hosts) KF5 (other hosts) TDE (on gx28x 13.1 & 13.2)
Look at the graphics setup. Few people fiddle with xorg.conf today. Most of graphics setups are done in a more dynamic way instead.
The similar trend is found for sound setup, too. You *shouldn't* change the system setup unless you know what you're doing. This is the way many DEs want / try to go. Instead, the sound setup is done in an upper level, typically in PulseAudio, then covered by more APIs on it like gstreamer, phonon, etc.
I don't see how "upper layers" can be expected to be successful regardless of choice of "upper layers" if YaST2 can't produce sound more than during initial configuration of the only sound device.
You misunderstand. If YaST could produce the sound initially, then it works in that level. The fact that the modified volume setup isn't restored means just that a wrong volume setup is restored instead. It's just a matter of volume setup (or in the case of PA, it might be routing or else), usually, and it has nothing to do with YaST directly.
Do you see the same problem when you reboot in runlevel 3 *right after* the initial YaST setup without any GUI? This excludes the influence on the setup by DE. If this works, OTOH, the remaining problem is in the upper layer.
In 13.1 in multi-user.target, setup sound in YaST works, and still works in YaST after rebooting back to multi-user.target. I started new thread in [opensuse]. http://lists.opensuse.org/opensuse/2015-12/msg00365.html And filed a Fedora bug: https://bugzilla.redhat.com/show_bug.cgi?id=1292025 I have normal system sounds, HTML5 sounds (Firefox/Youtube) and SMPlayer sounds in Debian Jessie, all without anything regarding sound in /etc/modprobe.d/. # aplay -l **** List of PLAYBACK Hardware Devices **** card 0: ICH6 [Intel ICH6], device 0: Intel ICH [Intel ICH6] Subdevices: 1/1 Subdevice #0: subdevice #0 card 0: ICH6 [Intel ICH6], device 4: Intel ICH - IEC958 [Intel ICH6 - IEC958] Subdevices: 1/1 Subdevice #0: subdevice #0 # lspci | grep Audio 00:1e.2 Multimedia audio controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) AC'97 Audio Controller (rev 03) -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Thu, 17 Dec 2015 05:33:32 +0100, Felix Miata wrote:
Takashi Iwai composed on 2015-12-10 09:42 (UTC+0100):
On Thu, 10 Dec 2015 07:47:20 +0100 Felix Miata wrote:
BTW, which DE are you testing at all? This was never clear, and
OP referred to kdbusaddons-tools-5.16.0-1.1.x86_64, K*5 and phonon-backend-* in TW context, which I thought made it clear enough I'm a KDE user.
You tested only KDE? Haven't you tried without GUI?
without that information, it's impossible to advice or debug. I thought KDE on TW requires PA, but it seems like my wrong memory.
Including other machines with same problem, all DEs I use have apparently identical trouble:
A different hardware, a different problem... For each case, open a bug report, as Richard already suggested.
KDE3 (on gx28x TW) KDE4 (other hosts) KF5 (other hosts) TDE (on gx28x 13.1 & 13.2)
What's TDE? Takashi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Takashi Iwai composed on 2015-12-17 07:49 (UTC+0100):
On Thu, 17 Dec 2015 05:33:32 +0100 Felix Miata wrote:
Takashi Iwai composed on 2015-12-10 09:42 (UTC+0100):
On Thu, 10 Dec 2015 07:47:20 +0100 Felix Miata wrote:
BTW, which DE are you testing at all? This was never clear, and
OP referred to kdbusaddons-tools-5.16.0-1.1.x86_64, K*5 and phonon-backend-* in TW context, which I thought made it clear enough I'm a KDE user.
You tested only KDE?
KDE3, KDE4, KF5 & TDE, and a dabble in IceWM as double check.
Haven't you tried without GUI?
Tried what without GUI? I don't expect sound outside GUI, so have no familiarity with that's available to test it there. alsaconf reports no sound devices exist, even though lsmod | grep snd reports 7-11 line items, depending on machine's hardware and distro release. alsamixer offers adjustments, but no apparent way to test. aplay and its man page provide no obvious way to test either. As previously noted, https://en.opensuse.org/SDB:Audio_troubleshooting is ancient and in need of bringing up to 13.2, Tumbleweed and 42.1. speaker-test -c2 -l5 -twav reports unable to open slave...playback open error: -2,No such file or directory (13.2 on 00:03.0 Audio device: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor HD Audio Controller (rev 06) http://fm.no-ip.com/Tmp/Linux/Sound/alsa-info-msi85.txt ).
without that information, it's impossible to advice or debug. I thought KDE on TW requires PA, but it seems like my wrong memory.
Including other machines with same problem, all DEs I use have apparently identical trouble:
A different hardware, a different problem... For each case, open a bug report, as Richard already suggested.
Every installation for which sound is not produced automagically needs an openSUSE bug filed? That's a lot of bugs. Whatever isn't happening ought to have (a) solution(s) that simply hasn't yet been unearthed. Besides, a reliably repeatable reproduction scenario has still not yet become apparent to me, and the troubles are not limited to openSUSE, but are occurring also in Fedora https://bugzilla.redhat.com/show_bug.cgi?id=1292025 and others http://trinity-users.pearsoncomputing.net/?0::9601. I have 3 Dell Optiplex GX280s, with upwards of 8 distros installed on each. On one machine, sound works in all distros. On the other two machines, sound works in none (except Windows XP). Very exasperating.
KDE3 (on gx28x TW) KDE4 (other hosts) KF5 (other hosts) TDE (on gx28x 13.1 & 13.2)
What's TDE?
KDE3 fork primarily intended for users of distros no longer providing KDE3. https://www.trinitydesktop.org/index.php -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Fri, 18 Dec 2015 10:19:09 +0100, Felix Miata wrote:
Takashi Iwai composed on 2015-12-17 07:49 (UTC+0100):
On Thu, 17 Dec 2015 05:33:32 +0100 Felix Miata wrote:
Takashi Iwai composed on 2015-12-10 09:42 (UTC+0100):
On Thu, 10 Dec 2015 07:47:20 +0100 Felix Miata wrote:
BTW, which DE are you testing at all? This was never clear, and
OP referred to kdbusaddons-tools-5.16.0-1.1.x86_64, K*5 and phonon-backend-* in TW context, which I thought made it clear enough I'm a KDE user.
You tested only KDE?
KDE3, KDE4, KF5 & TDE, and a dabble in IceWM as double check.
See, you are testing multiple DEs, but it wasn't clear at all in OP.
Haven't you tried without GUI?
Tried what without GUI? I don't expect sound outside GUI, so have no familiarity with that's available to test it there.
Testing on GUI (e.g. on runlevel 3) is the best method to identify whether the problem lies in the lowlevel (either in kernel driver or in alsa-lib). This would be asked in anyway if you reported a bug. If the sound works reliably there, the problem is in the upper layer, e.g. in sound backend like PA, or its higher layer like gstreamer / phonon, or even higher like kmix. So the debug continues.
alsaconf reports no sound devices exist, even though lsmod | grep snd reports 7-11 line items, depending on machine's hardware and distro release. alsamixer offers adjustments, but no apparent way to test. aplay and its man page provide no obvious way to test either. As previously noted, https://en.opensuse.org/SDB:Audio_troubleshooting is ancient and in need of bringing up to 13.2, Tumbleweed and 42.1. speaker-test -c2 -l5 -twav reports unable to open slave...playback open error: -2,No such file or directory (13.2 on 00:03.0 Audio device: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor HD Audio Controller (rev 06) http://fm.no-ip.com/Tmp/Linux/Sound/alsa-info-msi85.txt ).
alsaconf is a deprecated tool and it shouldn't be used any longer for normal users. I wanted to delete it from the distribution for avoiding confusion, but I was too lazy to do that :)
without that information, it's impossible to advice or debug. I thought KDE on TW requires PA, but it seems like my wrong memory.
Including other machines with same problem, all DEs I use have apparently identical trouble:
A different hardware, a different problem... For each case, open a bug report, as Richard already suggested.
Every installation for which sound is not produced automagically needs an openSUSE bug filed?
Yes.
That's a lot of bugs.
Yes.
Whatever isn't happening ought to have (a) solution(s) that simply hasn't yet been unearthed. Besides, a reliably repeatable reproduction scenario has still not yet become apparent to me, and the troubles are not limited to openSUSE, but are occurring also in Fedora https://bugzilla.redhat.com/show_bug.cgi?id=1292025 and others http://trinity-users.pearsoncomputing.net/?0::9601. I have 3 Dell Optiplex GX280s, with upwards of 8 distros installed on each. On one machine, sound works in all distros. On the other two machines, sound works in none (except Windows XP). Very exasperating.
To repeat myself -- a different machine, a different problem :)
KDE3 (on gx28x TW) KDE4 (other hosts) KF5 (other hosts) TDE (on gx28x 13.1 & 13.2)
What's TDE?
KDE3 fork primarily intended for users of distros no longer providing KDE3. https://www.trinitydesktop.org/index.php
Thanks, good to know. Is it included in TW? Takashi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Takashi Iwai composed on 2015-12-18 11:42 (UTC+0100):
On Fri, 18 Dec 2015 10:19:09 +0100 Felix Miata wrote:
Takashi Iwai composed on 2015-12-17 07:49 (UTC+0100):
What's TDE?
KDE3 fork primarily intended for users of distros no longer providing KDE3. https://www.trinitydesktop.org/index.php
Thanks, good to know. Is it included in TW?
ATM, apparently only available for 13.1, 13.2 and 42.1. https://wiki.trinitydesktop.org/OpenSUSEInstall -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Fri, 18 Dec 2015 12:00:22 +0100, Felix Miata wrote:
Takashi Iwai composed on 2015-12-18 11:42 (UTC+0100):
On Fri, 18 Dec 2015 10:19:09 +0100 Felix Miata wrote:
Takashi Iwai composed on 2015-12-17 07:49 (UTC+0100):
What's TDE?
KDE3 fork primarily intended for users of distros no longer providing KDE3. https://www.trinitydesktop.org/index.php
Thanks, good to know. Is it included in TW?
ATM, apparently only available for 13.1, 13.2 and 42.1. https://wiki.trinitydesktop.org/OpenSUSEInstall
Well, I meant as SUSE official packages. They aren't also *included* in 13.1 and others, right? Takashi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Takashi Iwai composed on 2015-12-18 12:04 (UTC+0100):
Thanks, good to know. Is it included in TW?
ATM, apparently only available for 13.1, 13.2 and 42.1. https://wiki.trinitydesktop.org/OpenSUSEInstall
Well, I meant as SUSE official packages. They aren't also *included* in 13.1 and others, right?
TDE is not available _IN_ any major distro. It's been too short of manpower to get through the hoops required for any such inclusion. It's primary contributors are entirely made up of users of various debian variants or Debian proper. I think the person primarily responsible for availability of TDE for openSUSE is David C. Rankin, who I think is a 13.1 user whose primary distro was switched to ArchLinux. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Takashi Iwai composed on 2015-12-18 11:42 (UTC+0100):
Haven't you tried without GUI?
Tried what without GUI? I don't expect sound outside GUI, so have no familiarity with that's available to test it there.
Testing on GUI (e.g. on runlevel 3) is the best method to identify whether the problem lies in the lowlevel (either in kernel driver or in alsa-lib). This would be asked in anyway if you reported a bug.
If the sound works reliably there, the problem is in the upper layer, e.g. in sound backend like PA, or its higher layer like gstreamer / phonon, or even higher like kmix. So the debug continues.
So to confirm whether sound works correctly, or at all, in runlevel 3, exactly what commands should be used, and do they need to be done by superuser, ordinary/regular user, or both? -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Fri, 18 Dec 2015 12:38:55 +0100, Felix Miata wrote:
Takashi Iwai composed on 2015-12-18 11:42 (UTC+0100):
Haven't you tried without GUI?
Tried what without GUI? I don't expect sound outside GUI, so have no familiarity with that's available to test it there.
Testing on GUI (e.g. on runlevel 3) is the best method to identify whether the problem lies in the lowlevel (either in kernel driver or in alsa-lib). This would be asked in anyway if you reported a bug.
If the sound works reliably there, the problem is in the upper layer, e.g. in sound backend like PA, or its higher layer like gstreamer / phonon, or even higher like kmix. So the debug continues.
So to confirm whether sound works correctly, or at all, in runlevel 3, exactly what commands should be used, and do they need to be done by superuser, ordinary/regular user, or both?
There is nothing special. Boot in runlevel 3 as a normal user. Start alsamixer. Then try to mute and adjust volume for "Master", "Headphone", "Speaker", etc via 'M' key and cursor keys. Quit by ESC key. (For AC97, there can be some external amp mixer item. If there is, unmute it, too.) If the mixer shows nothing or too few items, it's either that the primary device is HDMI/DP (recent Intel boards have so), or that the pulseaudio is used as the standard backend. In the former case, pass -c1 option to alsamixer to control the secondary device. In the latter case, pass -c0 option, supposing the target device being #0. Then try "aplay -vv /usr/share/sounds/alsa/test.wav" or any WAV file you want to test. When PA is used, pass -Dplughw:0 or -Dplughw:1 option depending on the device you test. If this works, reboot in runlevel 3, and login as the same user again. Now check aplay again whether it works without adjusting the mixer. Or, it might be that the device permission isn't set. Such a problem happens if your system is badly configured. Usually logind gives you the permission per login. In doubt, you can test the procedure above as root, at least. Takashi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
[Instead of littering https://bugzilla.opensuse.org/show_bug.cgi?id=954824 with an arguably different bug, replying here to comments 9 & 10 there, and WRT 13.2 specifically] (In reply to Takashi Iwai from bug comment #10)
First off, you must not remove 50-alsa.conf.
When I write "remove" a file in a troubleshooting context, it means remove the filename, not delete the file. e.g. mv 50-alsa.conf .50-alsa.conf.01
This isn't a file YaST create but it's a static system configuration.
Where does it come from? Why do some of my installations have it and others not? On Mageia 5 on the comment 6 & 7 machine, which has working sound (after urpmi task-pulseaudio, but not before), neither 50-alsa.conf nor 50-sound.conf nor anything equivalent exist in /etc/modeprobe.d/ (but in which is blacklisted snd-pcsp and pcspkr).
Try to reinstall alsa.rpm to recover it.
More simply here, cp -a /etc/modprobe.d/.50-alsa.conf.01 /etc/modprobe.d/50-alsa.conf via a simple Shift-F3 in mc.
It's 50-sound.conf that YaST creates. This is the file you can modify.
Putting options snd-hda-intel index=1,0 in it has changed the device priority as expected to 'HDA Intel PCH', but otherwise so far has not enabled sound on Youtube or systemsounds from KDE3/KDE4/KF5/TDE in 13.1 or 13.2 or TW or 42.1.
After that (and setting index=1,0 option in 50-sound.conf) and reboot in runlevel 3, check /proc/asound/cards at first. If the desired entries don't appear in the expected order (first analog then HDMI), anything wrong in the setup already.
[On 13.2] 0 [PCH ]: HDA-Intel - HDA Intel PCH HDA Intel PCH at 0xf7d10000 irq 46 1 [HDMI ]: HDA-Intel - HDA Intel HDMI HDA Intel HDMI at 0xf7d14000 irq 45 # aplay -vv /usr/share/sounds/alsa/test.wav claims to play, but there's no sound # aplay -vv /usr/share/sounds/alsa/test.wav -c0 aplay: main:563: value0 for channels is invalid # aplay -vv /usr/share/sounds/alsa/test.wav -c1 claims to play, but there's no sound # aplay -vv /usr/share/sounds/alsa/test.wav -Dplughw:0 plays # aplay -vv /usr/share/sounds/alsa/test.wav -Dplughw:1 aplay: main:722: audio open error: No such file or directory
If /proc/asound/cards looks correct,
NAICT, it's OK
then run "setup_default_volume -f 0".
[on 13.2] # setup_default_volume -f 0 produces a cnf error. # cnf setup_default_volume produces command not found. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Mon, 21 Dec 2015 00:48:40 +0100, Felix Miata wrote:
[Instead of littering https://bugzilla.opensuse.org/show_bug.cgi?id=954824 with an arguably different bug, replying here to comments 9 & 10 there, and WRT 13.2 specifically]
(In reply to Takashi Iwai from bug comment #10)
First off, you must not remove 50-alsa.conf.
When I write "remove" a file in a troubleshooting context, it means remove the filename, not delete the file. e.g. mv 50-alsa.conf .50-alsa.conf.01
It doesn't matter whether to rename or not. It's the system static configuration that isn't supposed to be changed.
This isn't a file YaST create but it's a static system configuration.
Where does it come from?
I already wrote it.
Why do some of my installations have it and others not?
It's for evaluating /etc/sysconfig stuff, which is specific to SUSE.
On Mageia 5 on the comment 6 & 7 machine, which has working sound (after urpmi task-pulseaudio, but not before), neither 50-alsa.conf nor 50-sound.conf nor anything equivalent exist in /etc/modeprobe.d/ (but in which is blacklisted snd-pcsp and pcspkr).
See above.
Try to reinstall alsa.rpm to recover it.
More simply here, cp -a /etc/modprobe.d/.50-alsa.conf.01 /etc/modprobe.d/50-alsa.conf via a simple Shift-F3 in mc.
It would work, of course.
It's 50-sound.conf that YaST creates. This is the file you can modify.
Putting options snd-hda-intel index=1,0 in it has changed the device priority as expected to 'HDA Intel PCH', but otherwise so far has not enabled sound on Youtube or systemsounds from KDE3/KDE4/KF5/TDE in 13.1 or 13.2 or TW or 42.1.
It won't work unless you adjust the mixer setup correctly at first.
After that (and setting index=1,0 option in 50-sound.conf) and reboot in runlevel 3, check /proc/asound/cards at first. If the desired entries don't appear in the expected order (first analog then HDMI), anything wrong in the setup already.
[On 13.2] 0 [PCH ]: HDA-Intel - HDA Intel PCH HDA Intel PCH at 0xf7d10000 irq 46 1 [HDMI ]: HDA-Intel - HDA Intel HDMI HDA Intel HDMI at 0xf7d14000 irq 45 # aplay -vv /usr/share/sounds/alsa/test.wav claims to play, but there's no sound
You have to run set_default_volume before testing aplay. Otherwise it's useless.
# aplay -vv /usr/share/sounds/alsa/test.wav -c0 aplay: main:563: value0 for channels is invalid
Of course, it won't work. aplay interprets -c differently from alsamixer.
# aplay -vv /usr/share/sounds/alsa/test.wav -c1 claims to play, but there's no sound # aplay -vv /usr/share/sounds/alsa/test.wav -Dplughw:0 plays # aplay -vv /usr/share/sounds/alsa/test.wav -Dplughw:1 aplay: main:722: audio open error: No such file or directory
If /proc/asound/cards looks correct,
NAICT, it's OK
then run "setup_default_volume -f 0".
[on 13.2] # setup_default_volume -f 0 produces a cnf error. # cnf setup_default_volume produces command not found.
It was a typo, the script is named set_default_volume. Takashi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Takashi Iwai composed on 2015-12-21 09:31 (UTC+0100): Based upon your direction, mostly having to do with including 'options snd-hda-intel index=1,0' in /etc/modprobe.d/, setting set_default_volume -f 0, and adjusting alsamixer in multi-user.target, I have sound of all types tried on host msi85 in the following: 13.1/TDE and KDE4 13.2/KDE4 42.1/KDE3 In TW/KF5 I get sound from aplay, YaST2 play test sound and Firefox/YoutubeHTML5, but not SMPlayer or KF5. In K5 systemsettings multimedia, no sound devices are found or listed on either device preference or backend tab, even though phonon-backend-vlc-0.8.2-1.1 from OSS is installed, and content from /proc/asound/devices and /proc/asound/cards matches that in the other installations. SMPlayer-15.11.0-1.1 from OSS exits with code 2 and reports "Failed to recognize file format" trying to load any audio or video file, even after explicitly setting its sound preference to the same alsa HDA Intel PCH device that works elsewhere. lsmod | grep snd produces 11 lines as in the other installations. These are installed packages that seem relevant: # rpm -qa | sort | egrep 'alsa|arts|mix|kspace|imedia|pavucontrol|phono|pulse' alsa-1.1.0-1.1.x86_64 alsa-firmware-1.0.29-1.1.noarch alsa-oss-1.0.28-3.3.x86_64 alsa-plugins-1.1.0-2.1.x86_64 alsa-utils-1.1.0-1.2.x86_64 kmix-15.08.3-1.1.x86_64 libQt5Multimedia5-5.5.1-1.1.x86_64 libphonon4-4.8.1-1.3.x86_64 libphonon4qt5-4.8.3-3.1.x86_64 libpulse-mainloop-glib0-7.1-1.1.x86_64 libpulse0-7.1-1.1.x86_64 phonon-backend-vlc-0.8.2-1.1.x86_64 plasma5-workspace-5.4.2-2.1.x86_64 Asking zypper for alsa-tools in TW results in a package named as10k1. What next to try? http://fm.no-ip.com/Tmp/Linux/Sound/alsa-info-ostw-partialOK.txt -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Thu, 24 Dec 2015 09:16:25 +0100, Felix Miata wrote:
Takashi Iwai composed on 2015-12-21 09:31 (UTC+0100):
Based upon your direction, mostly having to do with including 'options snd-hda-intel index=1,0' in /etc/modprobe.d/, setting set_default_volume -f 0, and adjusting alsamixer in multi-user.target, I have sound of all types tried on host msi85 in the following:
13.1/TDE and KDE4 13.2/KDE4 42.1/KDE3
In TW/KF5 I get sound from aplay, YaST2 play test sound and Firefox/YoutubeHTML5, but not SMPlayer or KF5.
Check which sound backend your SMPlayer is using. If it's a direct ALSA-API usage, this should work as long as the backend mplayer can interpret.
In K5 systemsettings multimedia, no sound devices are found or listed on either device preference or backend tab, even though phonon-backend-vlc-0.8.2-1.1 from OSS is installed, and content from /proc/asound/devices and /proc/asound/cards matches that in the other installations. SMPlayer-15.11.0-1.1 from OSS exits with code 2 and reports "Failed to recognize file format" trying to load any audio or video file, even after explicitly setting its sound preference to the same alsa HDA Intel PCH device that works elsewhere.
Well, it doesn't mean anything about the sound device failure directly. It rather suggests that your SMPlayer can't play the given file format. What file did you try to play? Doesn't it work even with a normal WAV file? If playing a normal WAV file still doesn't work, report it to Bugzilla, likely KDE category or such, as it's either an application itself or KF5-specific problem.
lsmod | grep snd produces 11 lines as in the other installations. These are installed packages that seem relevant: # rpm -qa | sort | egrep 'alsa|arts|mix|kspace|imedia|pavucontrol|phono|pulse' alsa-1.1.0-1.1.x86_64 alsa-firmware-1.0.29-1.1.noarch alsa-oss-1.0.28-3.3.x86_64 alsa-plugins-1.1.0-2.1.x86_64 alsa-utils-1.1.0-1.2.x86_64 kmix-15.08.3-1.1.x86_64 libQt5Multimedia5-5.5.1-1.1.x86_64 libphonon4-4.8.1-1.3.x86_64 libphonon4qt5-4.8.3-3.1.x86_64 libpulse-mainloop-glib0-7.1-1.1.x86_64 libpulse0-7.1-1.1.x86_64 phonon-backend-vlc-0.8.2-1.1.x86_64 plasma5-workspace-5.4.2-2.1.x86_64
Asking zypper for alsa-tools in TW results in a package named as10k1.
Felix, don't try too much things you are not sure what doing :) Usually you don't have to install any package from alsa-tools for normal operation. And, on TW, alsa-tools was split to various individual packages. That's the reason it doesn't hit only by name. Takashi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
My previous post was sent before I remembered my msi85 machine has two TW installations, one with "normal" KF5, the other with zypper locks set to block replacing KDE4 functionality with KF5's feature losses and crashing. The one with KF5 continues to have audio trouble. The one without KF5 works as well as 13.1, 13.2 and 42.1. Only two locks are responsible for the KDE4 retention: breez* kde-oxygen-fonts Takashi Iwai composed on 2015-12-24 09:59 (UTC+0100):
On Thu, 24 Dec 2015 09:16:25 +0100 Felix Miata wrote:
Takashi Iwai composed on 2015-12-21 09:31 (UTC+0100):
Based upon your direction, mostly having to do with including 'options snd-hda-intel index=1,0' in /etc/modprobe.d/, setting set_default_volume -f 0, and adjusting alsamixer in multi-user.target, I have sound of all types tried on host msi85 in the following:
13.1/TDE and KDE4 13.2/KDE4 42.1/KDE3
In TW/KF5 I get sound from aplay, YaST2 play test sound and Firefox/YoutubeHTML5, but not SMPlayer or KF5.
Check which sound backend your SMPlayer is using. If it's a direct ALSA-API usage, this should work as long as the backend mplayer can interpret.
Changing between pure alsa and alsa (0.0 - HDA Intel PCH) produces no apparent difference. It's set to simply alsa on the working SMPlayer in the KDE4 TW installation.
In K5 systemsettings multimedia, no sound devices are found or listed on either device preference or backend tab, even though phonon-backend-vlc-0.8.2-1.1 from OSS is installed, and content from /proc/asound/devices and /proc/asound/cards matches that in the other installations. SMPlayer-15.11.0-1.1 from OSS exits with code 2 and reports "Failed to recognize file format" trying to load any audio or video file, even after explicitly setting its sound preference to the same alsa HDA Intel PCH device that works elsewhere.
Well, it doesn't mean anything about the sound device failure directly. It rather suggests that your SMPlayer can't play the given file format. What file did you try to play?
Several audio and video types. Can't say exactly which, because the failure causes the selections not to be remembered in player history.
Doesn't it work even with a normal WAV file?
Doesn't work even with /usr/share/sounds/alsa/test.wav.
If playing a normal WAV file still doesn't work, report it to Bugzilla, likely KDE category or such, as it's either an application itself or KF5-specific problem.
That's the question, against what? Is the KDE failure likely the same failure as smplayer's? [broken KF5]
# rpm -qa | sort | egrep 'alsa|arts|mix|kspace|imedia|pavucontrol|phono|pulse' alsa-1.1.0-1.1.x86_64 alsa-firmware-1.0.29-1.1.noarch alsa-oss-1.0.28-3.3.x86_64 alsa-plugins-1.1.0-2.1.x86_64 alsa-utils-1.1.0-1.2.x86_64 kmix-15.08.3-1.1.x86_64 libQt5Multimedia5-5.5.1-1.1.x86_64 libphonon4-4.8.1-1.3.x86_64 libphonon4qt5-4.8.3-3.1.x86_64 libpulse-mainloop-glib0-7.1-1.1.x86_64 libpulse0-7.1-1.1.x86_64 phonon-backend-vlc-0.8.2-1.1.x86_64 plasma5-workspace-5.4.2-2.1.x86_64
[OK KDE4] # rpm -qa | sort | egrep 'alsa|arts|mix|kspace|imedia|pavucontrol|phono|pulse' alsa-1.1.0-1.1.x86_64 alsa-oss-1.0.28-3.3.x86_64 alsa-plugins-1.1.0-2.1.x86_64 alsa-utils-1.1.0-1.2.x86_64 kdebase4-workspace-4.11.22-4.1.x86_64 kmix-15.08.3-1.1.x86_64 libQt5Multimedia5-5.5.1-1.1.x86_64 libphonon4-4.8.1-1.3.x86_64 libphonon4qt5-4.8.3-3.1.x86_64 libpulse-mainloop-glib0-7.1-1.1.x86_64 libpulse0-7.1-1.1.x86_64 phonon-backend-vlc-0.8.2-16.4.x86_64 0.8.2-16.4 came from Packman in June. Everything else in KDE4 seems to have come from OSS. Even though the two installations run the same kernel and use the same content in /etc/moduprobe.d/, the snd modules loaded in the two different TW installations differ: --- 1 2015-12-24 05:51:02.095724644 -0500 (broken KF5) +++ 2 2015-12-24 05:51:09.245708595 -0500 (working KDE4) @@ -1,11 +1,13 @@ -snd 90112 16 snd_hda_codec_realtek,snd_hwdep,snd_timer,snd_hda_codec_hdmi,snd_pcm,snd_hda_codec_generic,snd_hda_codec,snd_hda_intel +snd 90112 14 snd_hda_codec_realtek,snd_hwdep,snd_timer,snd_hda_codec_hdmi,snd_pcm,snd_seq,snd_hda_codec_generic,snd_hda_codec,snd_hda_intel,snd_seq_device snd_hda_codec 147456 4 snd_hda_codec_realtek,snd_hda_codec_hdmi,snd_hda_codec_generic,snd_hda_intel snd_hda_codec_generic 81920 1 snd_hda_codec_realtek snd_hda_codec_hdmi 53248 1 snd_hda_codec_realtek 86016 1 snd_hda_core 73728 5 snd_hda_codec_realtek,snd_hda_codec_hdmi,snd_hda_codec_generic,snd_hda_codec,snd_hda_intel -snd_hda_intel 40960 4 +snd_hda_intel 40960 2 snd_hwdep 16384 1 snd_hda_codec snd_pcm 135168 4 snd_hda_codec_hdmi,snd_hda_codec,snd_hda_intel,snd_hda_core -snd_timer 36864 1 snd_pcm +snd_seq 77824 0 +snd_seq_device 16384 1 snd_seq +snd_timer 36864 2 snd_pcm,snd_seq soundcore 16384 1 snd How can it be determined why the differences? -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Thu, 24 Dec 2015 12:24:00 +0100, Felix Miata wrote:
My previous post was sent before I remembered my msi85 machine has two TW installations, one with "normal" KF5, the other with zypper locks set to block replacing KDE4 functionality with KF5's feature losses and crashing. The one with KF5 continues to have audio trouble. The one without KF5 works as well as 13.1, 13.2 and 42.1.
Only two locks are responsible for the KDE4 retention:
breez* kde-oxygen-fonts
Takashi Iwai composed on 2015-12-24 09:59 (UTC+0100):
On Thu, 24 Dec 2015 09:16:25 +0100 Felix Miata wrote:
Takashi Iwai composed on 2015-12-21 09:31 (UTC+0100):
Based upon your direction, mostly having to do with including 'options snd-hda-intel index=1,0' in /etc/modprobe.d/, setting set_default_volume -f 0, and adjusting alsamixer in multi-user.target, I have sound of all types tried on host msi85 in the following:
13.1/TDE and KDE4 13.2/KDE4 42.1/KDE3
In TW/KF5 I get sound from aplay, YaST2 play test sound and Firefox/YoutubeHTML5, but not SMPlayer or KF5.
Check which sound backend your SMPlayer is using. If it's a direct ALSA-API usage, this should work as long as the backend mplayer can interpret.
Changing between pure alsa and alsa (0.0 - HDA Intel PCH) produces no apparent difference. It's set to simply alsa on the working SMPlayer in the KDE4 TW installation.
In K5 systemsettings multimedia, no sound devices are found or listed on either device preference or backend tab, even though phonon-backend-vlc-0.8.2-1.1 from OSS is installed, and content from /proc/asound/devices and /proc/asound/cards matches that in the other installations. SMPlayer-15.11.0-1.1 from OSS exits with code 2 and reports "Failed to recognize file format" trying to load any audio or video file, even after explicitly setting its sound preference to the same alsa HDA Intel PCH device that works elsewhere.
Well, it doesn't mean anything about the sound device failure directly. It rather suggests that your SMPlayer can't play the given file format. What file did you try to play?
Several audio and video types. Can't say exactly which, because the failure causes the selections not to be remembered in player history.
Doesn't it work even with a normal WAV file?
Doesn't work even with /usr/share/sounds/alsa/test.wav.
If playing a normal WAV file still doesn't work, report it to Bugzilla, likely KDE category or such, as it's either an application itself or KF5-specific problem.
That's the question, against what? Is the KDE failure likely the same failure as smplayer's?
I don't know of KF5 details, so let's start from KDE, I'd say. It might be that KF5 works only with PulseAudio, for example. In anyway, definitely this isn't about the generic lowlevel sound problem, as aplay works as is. It's either a system setup problem for KF5, or some application-specific problem.
[broken KF5]
# rpm -qa | sort | egrep 'alsa|arts|mix|kspace|imedia|pavucontrol|phono|pulse' alsa-1.1.0-1.1.x86_64 alsa-firmware-1.0.29-1.1.noarch alsa-oss-1.0.28-3.3.x86_64 alsa-plugins-1.1.0-2.1.x86_64 alsa-utils-1.1.0-1.2.x86_64 kmix-15.08.3-1.1.x86_64 libQt5Multimedia5-5.5.1-1.1.x86_64 libphonon4-4.8.1-1.3.x86_64 libphonon4qt5-4.8.3-3.1.x86_64 libpulse-mainloop-glib0-7.1-1.1.x86_64 libpulse0-7.1-1.1.x86_64 phonon-backend-vlc-0.8.2-1.1.x86_64 plasma5-workspace-5.4.2-2.1.x86_64
[OK KDE4] # rpm -qa | sort | egrep 'alsa|arts|mix|kspace|imedia|pavucontrol|phono|pulse' alsa-1.1.0-1.1.x86_64 alsa-oss-1.0.28-3.3.x86_64 alsa-plugins-1.1.0-2.1.x86_64 alsa-utils-1.1.0-1.2.x86_64 kdebase4-workspace-4.11.22-4.1.x86_64 kmix-15.08.3-1.1.x86_64 libQt5Multimedia5-5.5.1-1.1.x86_64 libphonon4-4.8.1-1.3.x86_64 libphonon4qt5-4.8.3-3.1.x86_64 libpulse-mainloop-glib0-7.1-1.1.x86_64 libpulse0-7.1-1.1.x86_64 phonon-backend-vlc-0.8.2-16.4.x86_64
0.8.2-16.4 came from Packman in June. Everything else in KDE4 seems to have come from OSS.
Even though the two installations run the same kernel and use the same content in /etc/moduprobe.d/, the snd modules loaded in the two different TW installations differ: --- 1 2015-12-24 05:51:02.095724644 -0500 (broken KF5) +++ 2 2015-12-24 05:51:09.245708595 -0500 (working KDE4) @@ -1,11 +1,13 @@ -snd 90112 16 snd_hda_codec_realtek,snd_hwdep,snd_timer,snd_hda_codec_hdmi,snd_pcm,snd_hda_codec_generic,snd_hda_codec,snd_hda_intel +snd 90112 14 snd_hda_codec_realtek,snd_hwdep,snd_timer,snd_hda_codec_hdmi,snd_pcm,snd_seq,snd_hda_codec_generic,snd_hda_codec,snd_hda_intel,snd_seq_device snd_hda_codec 147456 4 snd_hda_codec_realtek,snd_hda_codec_hdmi,snd_hda_codec_generic,snd_hda_intel snd_hda_codec_generic 81920 1 snd_hda_codec_realtek snd_hda_codec_hdmi 53248 1 snd_hda_codec_realtek 86016 1 snd_hda_core 73728 5 snd_hda_codec_realtek,snd_hda_codec_hdmi,snd_hda_codec_generic,snd_hda_codec,snd_hda_intel -snd_hda_intel 40960 4 +snd_hda_intel 40960 2 snd_hwdep 16384 1 snd_hda_codec snd_pcm 135168 4 snd_hda_codec_hdmi,snd_hda_codec,snd_hda_intel,snd_hda_core -snd_timer 36864 1 snd_pcm +snd_seq 77824 0 +snd_seq_device 16384 1 snd_seq +snd_timer 36864 2 snd_pcm,snd_seq soundcore 16384 1 snd
How can it be determined why the differences?
You're likely looking at the wrong place. The sound lowlevel system itself is working. So the problem is in the upper level, which isn't seen at all in the outputs you stated in the above. Takashi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Takashi Iwai composed on 2015-12-24 14:10 (UTC+0100):
[broken KF5]
# rpm -qa | sort | egrep 'alsa|arts|mix|kspace|imedia|pavucontrol|phono|pulse' alsa-1.1.0-1.1.x86_64 alsa-firmware-1.0.29-1.1.noarch alsa-oss-1.0.28-3.3.x86_64 alsa-plugins-1.1.0-2.1.x86_64 alsa-utils-1.1.0-1.2.x86_64 kmix-15.08.3-1.1.x86_64 libQt5Multimedia5-5.5.1-1.1.x86_64 libphonon4-4.8.1-1.3.x86_64 libphonon4qt5-4.8.3-3.1.x86_64 libpulse-mainloop-glib0-7.1-1.1.x86_64 libpulse0-7.1-1.1.x86_64 phonon-backend-vlc-0.8.2-1.1.x86_64 plasma5-workspace-5.4.2-2.1.x86_64
[OK KDE4] # rpm -qa | sort | egrep 'alsa|arts|mix|kspace|imedia|pavucontrol|phono|pulse' alsa-1.1.0-1.1.x86_64 alsa-oss-1.0.28-3.3.x86_64 alsa-plugins-1.1.0-2.1.x86_64 alsa-utils-1.1.0-1.2.x86_64 kdebase4-workspace-4.11.22-4.1.x86_64 kmix-15.08.3-1.1.x86_64 libQt5Multimedia5-5.5.1-1.1.x86_64 libphonon4-4.8.1-1.3.x86_64 libphonon4qt5-4.8.3-3.1.x86_64 libpulse-mainloop-glib0-7.1-1.1.x86_64 libpulse0-7.1-1.1.x86_64 phonon-backend-vlc-0.8.2-16.4.x86_64
0.8.2-16.4 came from Packman in June. Everything else in KDE4 seems to have come from OSS.
Even though the two installations run the same kernel and use the same content in /etc/moduprobe.d/, the snd modules loaded in the two different TW installations differ: --- 1 2015-12-24 05:51:02.095724644 -0500 (broken KF5) +++ 2 2015-12-24 05:51:09.245708595 -0500 (working KDE4) @@ -1,11 +1,13 @@ -snd 90112 16 snd_hda_codec_realtek,snd_hwdep,snd_timer,snd_hda_codec_hdmi,snd_pcm,snd_hda_codec_generic,snd_hda_codec,snd_hda_intel +snd 90112 14 snd_hda_codec_realtek,snd_hwdep,snd_timer,snd_hda_codec_hdmi,snd_pcm,snd_seq,snd_hda_codec_generic,snd_hda_codec,snd_hda_intel,snd_seq_device snd_hda_codec 147456 4 snd_hda_codec_realtek,snd_hda_codec_hdmi,snd_hda_codec_generic,snd_hda_intel snd_hda_codec_generic 81920 1 snd_hda_codec_realtek snd_hda_codec_hdmi 53248 1 snd_hda_codec_realtek 86016 1 snd_hda_core 73728 5 snd_hda_codec_realtek,snd_hda_codec_hdmi,snd_hda_codec_generic,snd_hda_codec,snd_hda_intel -snd_hda_intel 40960 4 +snd_hda_intel 40960 2 snd_hwdep 16384 1 snd_hda_codec snd_pcm 135168 4 snd_hda_codec_hdmi,snd_hda_codec,snd_hda_intel,snd_hda_core -snd_timer 36864 1 snd_pcm +snd_seq 77824 0 +snd_seq_device 16384 1 snd_seq +snd_timer 36864 2 snd_pcm,snd_seq soundcore 16384 1 snd
How can it be determined why the differences?
You're likely looking at the wrong place. The sound lowlevel system itself is working. So the problem is in the upper level, which isn't seen at all in the outputs you stated in the above.
Entirely logical but for one thing: both installations are on the same machine of the same "release" running the same kernel. Obviously installed packages and kernel mods are enough for expected results at low level, but nevertheless the kernel mods are *not* identical, so why the difference, and why couldn't the difference account for an upper level failure? -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Thu, 24 Dec 2015 17:30:05 +0100, Felix Miata wrote:
Takashi Iwai composed on 2015-12-24 14:10 (UTC+0100):
[broken KF5]
# rpm -qa | sort | egrep 'alsa|arts|mix|kspace|imedia|pavucontrol|phono|pulse' alsa-1.1.0-1.1.x86_64 alsa-firmware-1.0.29-1.1.noarch alsa-oss-1.0.28-3.3.x86_64 alsa-plugins-1.1.0-2.1.x86_64 alsa-utils-1.1.0-1.2.x86_64 kmix-15.08.3-1.1.x86_64 libQt5Multimedia5-5.5.1-1.1.x86_64 libphonon4-4.8.1-1.3.x86_64 libphonon4qt5-4.8.3-3.1.x86_64 libpulse-mainloop-glib0-7.1-1.1.x86_64 libpulse0-7.1-1.1.x86_64 phonon-backend-vlc-0.8.2-1.1.x86_64 plasma5-workspace-5.4.2-2.1.x86_64
[OK KDE4] # rpm -qa | sort | egrep 'alsa|arts|mix|kspace|imedia|pavucontrol|phono|pulse' alsa-1.1.0-1.1.x86_64 alsa-oss-1.0.28-3.3.x86_64 alsa-plugins-1.1.0-2.1.x86_64 alsa-utils-1.1.0-1.2.x86_64 kdebase4-workspace-4.11.22-4.1.x86_64 kmix-15.08.3-1.1.x86_64 libQt5Multimedia5-5.5.1-1.1.x86_64 libphonon4-4.8.1-1.3.x86_64 libphonon4qt5-4.8.3-3.1.x86_64 libpulse-mainloop-glib0-7.1-1.1.x86_64 libpulse0-7.1-1.1.x86_64 phonon-backend-vlc-0.8.2-16.4.x86_64
0.8.2-16.4 came from Packman in June. Everything else in KDE4 seems to have come from OSS.
Even though the two installations run the same kernel and use the same content in /etc/moduprobe.d/, the snd modules loaded in the two different TW installations differ: --- 1 2015-12-24 05:51:02.095724644 -0500 (broken KF5) +++ 2 2015-12-24 05:51:09.245708595 -0500 (working KDE4) @@ -1,11 +1,13 @@ -snd 90112 16 snd_hda_codec_realtek,snd_hwdep,snd_timer,snd_hda_codec_hdmi,snd_pcm,snd_hda_codec_generic,snd_hda_codec,snd_hda_intel +snd 90112 14 snd_hda_codec_realtek,snd_hwdep,snd_timer,snd_hda_codec_hdmi,snd_pcm,snd_seq,snd_hda_codec_generic,snd_hda_codec,snd_hda_intel,snd_seq_device snd_hda_codec 147456 4 snd_hda_codec_realtek,snd_hda_codec_hdmi,snd_hda_codec_generic,snd_hda_intel snd_hda_codec_generic 81920 1 snd_hda_codec_realtek snd_hda_codec_hdmi 53248 1 snd_hda_codec_realtek 86016 1 snd_hda_core 73728 5 snd_hda_codec_realtek,snd_hda_codec_hdmi,snd_hda_codec_generic,snd_hda_codec,snd_hda_intel -snd_hda_intel 40960 4 +snd_hda_intel 40960 2 snd_hwdep 16384 1 snd_hda_codec snd_pcm 135168 4 snd_hda_codec_hdmi,snd_hda_codec,snd_hda_intel,snd_hda_core -snd_timer 36864 1 snd_pcm +snd_seq 77824 0 +snd_seq_device 16384 1 snd_seq +snd_timer 36864 2 snd_pcm,snd_seq soundcore 16384 1 snd
How can it be determined why the differences?
You're likely looking at the wrong place. The sound lowlevel system itself is working. So the problem is in the upper level, which isn't seen at all in the outputs you stated in the above.
Entirely logical but for one thing: both installations are on the same machine of the same "release" running the same kernel. Obviously installed packages and kernel mods are enough for expected results at low level, but nevertheless the kernel mods are *not* identical, so why the difference, and why couldn't the difference account for an upper level failure?
Are you 100% sure that both machines have been installed and modified in the very same way? Look at /etc/modprobe.d/50-alsa.conf and /etc/sysconfig. Are these present and same on both machines? Takashi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Takashi Iwai composed on 2015-12-25 09:04 (UTC+0100):
Are you 100% sure that both machines
One multiboot machine. Two installations.
have been installed and modified in the very same way? Look at /etc/modprobe.d/50-alsa.conf and
One file was copied to the other, so same file.
/etc/sysconfig. Are these present and same on both machines?
This is first in thread mention of /etc/sysconfig. What settings within /etc/sysconfig/sound should be used for which DEs, and modified directly, or via some GUI tool (e.g. YaST2 or KDE systemsettings)? Oh, and the machine has 3 hds with most installations on only one, but a couple of installations on a RAID1 disk pair. 13.2/KDE3 on the RAID works across the board too. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Fri, 25 Dec 2015 09:34:03 +0100, Felix Miata wrote:
Takashi Iwai composed on 2015-12-25 09:04 (UTC+0100):
Are you 100% sure that both machines
One multiboot machine. Two installations.
have been installed and modified in the very same way? Look at /etc/modprobe.d/50-alsa.conf and
One file was copied to the other, so same file.
/etc/sysconfig. Are these present and same on both machines?
This is first in thread mention of /etc/sysconfig. What settings within /etc/sysconfig/sound should be used for which DEs, and modified directly, or via some GUI tool (e.g. YaST2 or KDE systemsettings)?
You can modify it manually freely. One exception is $PULSEAUDIO_ENABLE that needs more other setups, and it's actually read/written by either YaST or setup-pulseaudio script. $SOUNDFONT_FILES is also read/set by YaST, but you can ignore it unless you have an old SoundBlaster board. The difference of lsmod on your machines comes from the fact that one machine didn't load the sequencer module. So, one machine has likely LOAD_SEQUENCER="no" while another has "yes". Set to "no" on both. (The difference might happen if you carry the setup from the old distro where LOAD_SEQUENCER="yes" as default at that time.) LOAD_OSS_EMUL_MODULES, LOAD_OSS_SEQ_MODULE can be "no", too. PULSEAUDIO_SYSTEM should be "no" for normal usage, too. Takashi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
[LMDE2 Betty/kernel 3.16.0 has nothing sound-related in /etc/modprobe.d/, only some blacklisting and some video-related, and worked/works automagically] Intel Haswell B85 chipset motherboard: http://us.msi.com/product/motherboard/B85-G41-PC-Mate.html # lspci | grep udio 00:03.0 Audio device: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor HD Audio Controller (rev 06) 00:1b.0 Audio device: Intel Corporation 8 Series/C220 Series Chipset High Definition Audio Controller (rev 04) # rpm -qa | sort | egrep 'alsa|arts|kspace|mix|pavu|phonon|pulse' alsa-1.0.27.2-3.5.1.x86_64 alsa-firmware-1.0.27-2.1.2.noarch alsa-oss-1.0.25-8.4.1.x86_64 alsa-plugins-1.0.27-3.1.1.x86_64 alsa-plugins-pulse-1.0.27-3.1.1.x86_64 alsa-tools-1.0.27-5.1.3.x86_64 alsa-utils-1.0.27.2-4.5.1.x86_64 kdebase4-workspace-4.11.12-123.1.x86_64 kmix-4.11.5-190.3.x86_64 libphonon4-4.7.1-8.3.x86_64 libpulse-mainloop-glib0-4.0.git.270.g9490a-20.1.x86_64 libpulse0-4.0.git.270.g9490a-20.1.x86_64 pavucontrol-2.0-2.4.2.x86_64 phonon-backend-gstreamer-0_10-4.7.1-2.12.1.x86_64 #phonon-backend-vlc-0.8.2-16.2.x86_64 # from packman, didn't work phonon-backend-vlc-0.7.1-13.3.x86_64 # from Updates pulseaudio-4.0.git.270.g9490a-20.1.x86_64 trinity-arts-1.5.10-1.oss131.opt.x86_64 trinity-kmix-3.5.13.2-4.oss131.opt.x86_64 #YaST2 sound config: http://fm.no-ip.com/SS/Suse/YaST/y2sound-msi85-os131.png #alsa-info.txt: http://fm.no-ip.com/Tmp/Hardware/Audio/alsa-info-msi85-os131-OK.txt # lsmod | sort | grep snd snd 87502 15 snd_hda_codec_realtek,snd_hda_codec_hdmi,snd_hda_intel,snd_hda_codec,snd_hwdep,snd_pcm,snd_seq,snd_timer,snd_seq_device snd_hda_codec 205305 3 snd_hda_codec_realtek,snd_hda_codec_hdmi,snd_hda_intel snd_hda_codec_hdmi 50353 1 snd_hda_codec_realtek 61254 1 snd_hda_intel 52401 3 snd_hwdep 13602 1 snd_hda_codec snd_page_alloc 18710 2 snd_hda_intel,snd_pcm snd_pcm 110211 3 snd_hda_codec_hdmi,snd_hda_intel,snd_hda_codec snd_seq 69752 0 snd_seq_device 14497 1 snd_seq snd_timer 29433 2 snd_pcm,snd_seq soundcore 15047 1 snd # cat /proc/asound/cards 0 [PCH ]: HDA-Intel - HDA Intel PCH HDA Intel PCH at 0xf7d10000 irq 46 1 [HDMI ]: HDA-Intel - HDA Intel HDMI HDA Intel HDMI at 0xf7d14000 irq 45 # cat /proc/asound/devices 1: : sequencer 2: [ 1- 8]: digital audio playback 3: [ 1- 7]: digital audio playback 4: [ 1- 3]: digital audio playback 5: [ 1- 0]: hardware dependent 6: [ 1] : control 7: [ 0- 2]: digital audio capture 8: [ 0- 0]: digital audio playback 9: [ 0- 0]: digital audio capture 10: [ 0- 0]: hardware dependent 11: [ 0] : control 33: : timer #/etc/modprobe.d/50-alsa.conf (unknown 2013-11-28 source) install snd /sbin/install-snd-module snd $CMDLINE_OPTS install snd-pcm /sbin/install-snd-module snd-pcm $CMDLINE_OPTS install snd-seq /sbin/install-snd-module snd-seq $CMDLINE_OPTS #/etc/modprobe.d/50-alsa.conf (unknown 2015-04-27 source) options snd slots=snd-hda-intel # u1Nb.rDQtddvcN62:82801G (ICH7 Family) High Definition Audio Controller alias snd-card-0 snd-hda-intel #/etc/modprobe.d/99-local.conf (custom) options snd-hda-intel index=1,0 #alsamixer settings http://fm.no-ip.com/SS/Suse/alsamixer-msi85-os131.png Last thing after all above configurations and before logging into Xorg sessions: Delete *config*kmix*rc files. Sounds tested working: YaST2 play test sound on default device Youtube HTML5 KDE4 system sounds TDE 3.5.13.2 system sounds SMPlayer aplay -vv /usr/share/sounds/alsa/test.wav aplay -vv /usr/share/sounds/alsa/test.wav -c1 aplay -vv /usr/share/sounds/alsa/test.wav -Dplughw:0 :-D https://www.youtube.com/watch?v=S0JTmNXrt5U Next up: trying again in 13.2, TW, 42.1, Wheezy & Fedora (Mageia 5 & LMDE2 already were working). -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Felix Miata composed on 2015-12-21 03:36 (UTC-0500):
#/etc/modprobe.d/50-alsa.conf (unknown 2013-11-28 source) install snd /sbin/install-snd-module snd $CMDLINE_OPTS install snd-pcm /sbin/install-snd-module snd-pcm $CMDLINE_OPTS install snd-seq /sbin/install-snd-module snd-seq $CMDLINE_OPTS
#/etc/modprobe.d/50-alsa.conf (unknown 2015-04-27 source) options snd slots=snd-hda-intel # u1Nb.rDQtddvcN62:82801G (ICH7 Family) High Definition Audio Controller alias snd-card-0 snd-hda-intel
Obviously both are not 50-alsa.conf. The latter is 50-sound.conf. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (5)
-
Felix Miata -
Henne Vogelsang -
Patrick Shanahan -
Richard Brown -
Takashi Iwai