Bug 222540

Summary:	arts sound server refuses to start in "user" mode
Product:	[openSUSE] openSUSE 10.2	Reporter:	Darren Clarke <darren>
Component:	Sound	Assignee:	E-mail List <kde-maintainers>
Status:	RESOLVED INVALID	QA Contact:	E-mail List <qa-bugs>
Severity:	Normal
Priority:	P5 - None
Version:	Beta 2
Target Milestone:	---
Hardware:	x86
OS:	SUSE Other
Whiteboard:
Found By:	Other	Services Priority:
Business Priority:		Blocker:	---
Marketing QA Status:	---	IT Deployment:	---

Description Darren Clarke 2006-11-19 17:22:33 UTC

aRts will not start in normal "user" level mode (user level 1000), however if I login to KDE using root, sound (aRts) works fine.
Attempting to start / restart the sound server in KDE control centre results in a message window with 0-100% stating "Restarting the sound server" which never happens (continuously going from 0-100% and back to zero). The system becomes unresponsive because kcminit arts is continously respawning artsd which never starts. Nothing crashes, just slows the system to a crawl (20-30 versions of artsd attempting to start)
Soundcard is a Creative Labs Audigy SE (snd-ca0106 driver). Card configures correctly using alsaconf, volumes are correctly set in alsamixer (analog F only). Sound output works fine with alsa.

For the record I have installed Fedora Core 6 to test the sound in KDE and it works fine (not that I want to use FC6, but I needed a comparison install).

Comment 1 Stephan Binner 2006-11-20 08:48:23 UTC

> because kcminit arts is continously respawning artsd which never starts

This is likely a dupe and fixed with https://bugzilla.novell.com/show_bug.cgi?id=178930#c3

Comment 2 Stephan Binner 2006-11-20 08:48:53 UTC

Sorry, one component off :-)...

Comment 3 Stephan Kulow 2006-11-20 10:51:01 UTC

I assume this too.

Comment 4 Darren Clarke 2006-11-21 00:49:19 UTC

Sorry, but are you sure this is really fixed? By ensuring that the user was part of the audio group, it appears to have temporarily fixed the arts problem. Could it be a simple case of incorrect permissions, rather than the "patch" which would have no effect in my case as I stated that artsd was responding correctly when I logged in as root.

Comment 5 Darren Clarke 2006-11-21 09:03:08 UTC

Another point, if I run kcontrol as root I can start & stop artsd with no problems whatsoever.

Comment 6 Darren Clarke 2006-11-21 09:03:24 UTC

Another point, if I run kcontrol as root I can start & stop artsd with no problems whatsoever.

Comment 7 Stephan Kulow 2006-11-21 09:47:30 UTC

Then this affects all sound applications started as user. Is that what you're saying?

Comment 8 Takashi Iwai 2006-11-21 10:05:56 UTC

It must be fine to start arts as user.  It's just a normal sound application, and there should be nothing special regarding the permission.

If you think the problem got fixed, please close it.

Comment 9 Dirk Mueller 2006-11-21 10:38:25 UTC

sorry, but thats most likely a user configuration issue and not a blocker. 

how did you login? gdm?kdm?xdm? which version do you use? still beta2?

Comment 10 Darren Clarke 2006-11-21 10:45:07 UTC

Nice.
It is a user configuration issue? If this is the case it is set by default, NOT by my configuration.

How did I login? KDM. Version SuSE 10.2 Beta 2 (this is all in the info at the top of the bug...)

I've informed you of the issue (as have several other users), you guys are the developers, not me. I've told you what I did, how I did it, and you should have enough information to reproduce it. The problem is NOT fixed (otherwise why would I re-open it...). Do with the information as you wish, I really don't give a ....

Comment 11 Dirk Mueller 2006-11-21 11:57:35 UTC

try /sbin/resmgr sessions and /sbin/resmgr classes. the output should be non-empty, I would guess that this is not the case for you. 

there were some pam/resmgr problems, but they appear fixed now.