On Tuesday 24 February 2009 08:20:27 am Greg Freemyer wrote:
On Tue, Feb 24, 2009 at 9:11 AM, Alberto Passalacqua
<alberto.passalacqua@tin.it> wrote:
HOWEVER: disabling it should be the last option. It shouldn't be taken as the primary option as the subject says.
Well, we all agree on this (I hope). At least on my side, I'm not trying to do it for a question of principle.
Actually the PA problems can be categorized to two regions:
1. audio quality issues 2. integration issues
About 1, it comes more or less from "glitch-free" feature of PA (ironically). These are simply bugs to be fixed, not to hide. It's unfortunate that this feature was introduced to 11.1 before maturing.
The second issue includes the third-vendor softwares like skype, and the issues about mixer applications. The mixer issues will (should) be improved in future. But the third-vendor issue isn't always easy to fix. But, we can expect that they are going to fix the codes if they see the wide deployment and the massive problem reports...
I have no idea about Adobe. Skype is actively working on it, it seems. They have an experimental PA support which should be part of the next release, but what they said on their website is that it has stability problems (strange!) ;-)
I would add some other stuff actually, if you didn't include them in the "mixer problems". Which are the crashes of the daemon that leave you without controls. On my side they are pretty frequent, and in theory a patch was already applied for that in 11.0.
Regards, A.
It seems like sound in general is a mess with linux. I know my personal experience with it over the last 18 months has been poor.
I actually was pretty happy with it for11.1 out of the box, but for me with the KDE 4.2 factory and the most recent you updates, if has been highly unstable. I had pulse audio enabled until a few days ago when it just got to be too much of a hassle.
For me it was problem with KDE3, as still use it most of the time.
The trouble seems to be the variety of hardware / software people are using
That is the problem anywhere. In windows vendors provide drivers, which works fine for vendors that know how to write drivers and don't want to abuse installation to push junk utilities on users. When that is not the case you get broken windows installation and pile of junk that runs without your knowledge all the time. Linux has problem that too many drivers are written by people that are not insiders ie. can't access confidential infomation, spend time guessing how hardware works, instead of developing actual driver.
plus the lack of feedback to the factory team to make decisions with.
The feedback exist, though, majority outside bugzilla. The problem is that bugzilla user and communication interface are outdated, plus there is problem that bugzilla is not configuration support, so questions of that kind are not accepted, and people should have some skills in order to provide data for developers. Who doesn't use command line can't help much.
It seems like what is needed is way to automatically gather hardware / software info, plus ask the user about their experience with sound.
Can smolt be leveraged to do something like that?
Good idea. Though, user interface needs some work too. Currently you can automatically report hardware info, but you need password for online edit. Online edit allows you to change marks for each reported piece of hardware, and add comments in the wiki. For wiki you need login. Workflow is relative simple if user is willing to spend time learning it, but it is still good only for old type of Linux users. The whole workflow from encountering the bug to solution is separated in a few pieces that users must learn that they exist and how to use, before they can get what they need, ie. bug solution. Basically none of options is really helpful for todays average users. Without reliance on engineering software solution to understand users (human input), which with best effort will not happen any soon, problem is how to use best properties of communication media as forums, USENET, IRC, and mail, hardware reporting tools as smolt, bug tracking software and skilled volunteers as mediators. -- Regards, Rajko -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org