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