Bug 288992 - kaccess does not release/suspend pulseaudio sink
Summary: kaccess does not release/suspend pulseaudio sink
Status: RESOLVED NOT A BUG
Alias: None
Product: Phonon
Classification: Frameworks and Libraries
Component: Pulsesupport (show other bugs)
Version: unspecified
Platform: Ubuntu Linux
: NOR normal
Target Milestone: ---
Assignee: Harald Sitter
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-12-14 18:38 UTC by JPH
Modified: 2013-04-13 06:33 UTC (History)
4 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description JPH 2011-12-14 18:38:44 UTC
Version:           4.7 (using KDE 4.7.2) 
OS:                Linux

To save electricity, I wrote a little tool that automatically switches my external audio amplifier on and of when a sound is played by the system. It is a little script that queries pulseaudio to decide whether or not to power on the audio amp. Please refer to http://wirespeed.xs4all.nl/mediawiki/index.php/PC_energy_savings#External_audio_amp_switch for details.

After a reboot this tool works for a little while, then it freezes until I kill kaccess. After killing kaccess the tool works fine again without any other intervention.

Reproducible: Always

Steps to Reproduce:
I cannot reprocue it manually, but it happpens after every reboot.
1. Fresh boot into Kubuntu 11.10 (or 11.04)
2. Use the system for a while
3. Various sounds are played, the script turns my amp on and off
4. Then after a little while (30 min?) the script freezes
5. At $-prompt: /usr/bin/pacmd list-sinks | grep state
RUNNING

Actual Results:  
After a while it keeps saying:
state: RUNNING

And my electricity bill rises ;o)

Expected Results:  
The state should cycle through SUSPENDED - RUNNING - IDLE - SUSPENDED - ...

When a sound is played:
state: RUNNING

During approx. 3 seconds, when a sound is no longer playing:
state: IDLE

After these 3 seconds with no sound:
state: SUSPENDED

Then state stays SUSPENDED until a new sound is played.

I kill kaccess and the system works fine again from that moment onward. 
Kaccess is not respawned.
Comment 1 JPH 2011-12-17 00:31:57 UTC
Last message in .xsession-errors, just before kaccess refuses to suspend pulseaudio is:

 kded(2508) PowerDevilUPowerBackend::setBrightness: org.kde.powerdevil.backlighthelper.setbrightness failed 

I disabled "Display brightness" and "Dim display" in "Configure Power Management Profiles" as my hardware doesn't support it anyway.

---
Top -p <PID for kaccess> lists:
 2667 jhendrix  20   0  727m  29m  18m S  2.0  0.4   2:20.97 3 kaccess                                                       
14705 jhendrix  20   0  727m  29m  18m S  0.0  0.4   0:00.01 3 wavparse1:sink                                                
14707 jhendrix  20   0  727m  29m  18m S  0.0  0.4   0:00.00 0 queue0:src                                                    
14708 jhendrix  20   0  727m  29m  18m S  0.0  0.4   0:00.00 0 queue1:src                                                    
14709 jhendrix  20   0  727m  29m  18m S  0.0  0.4   0:02.26 0 threaded-ml                                                   

---
.xsession-errors starts to lists these messages, though the timing is off by exactly an hour. Not sure if it is related.
- kmix(2763) sink_input_cb: Ignoring sink-input due to it being designated as an event and thus handled by the Event slider 
- kded(2508)/kmix sink_input_cb: Ignoring sink-input due to it being designated as an event and thus handled by the Event slider
Comment 3 JPH 2011-12-17 10:30:23 UTC
As a work around I've been able to stop kaccess from starting up by disabling all options on all tabs under "Accessibility" in the "System Settings".

It is easy to see that kaccess is being enabled/disabled by starting 'watch $( ps -ef | grep kaccess )' in a shell. 

Don't forget to click apply in the System Settings window while experimenting.

Too bad I have to disable all options under Accessibility to solve my problem, I like the option of getting an bell warning when I accidentally hit Caps Lock...
Comment 4 Will Stephenson 2012-04-02 07:27:49 UTC
KAccess keeps a Phonon::MediaObject (withPhonon::AccessibilityCategory) around to customise the system bell for accessibility.  KNotify does the same thing, it keeps a minimum of one MediaObject with NotificationCategory ready for playback duties in the pool). Therefore either AccessiblityCategory prevents releasing/suspending PA and NotificationCategory does not, or you do not have knotify4 running.

Assigning to Phonon devs so they can check if there is a problem with MOs with AccessibilityCategory.
Comment 5 JPH 2012-04-02 07:31:41 UTC
$ ps -ef | grep knot
jhendrix  2677     1  1 Mar26 ?        03:07:13 /usr/bin/knotify4
jhendrix 10321 10297  0 09:30 pts/3    00:00:00 grep knot

Does that answer the question?
Comment 6 Harald Sitter 2012-09-09 12:05:38 UTC
what version of phonon? which phonon backend? what's the version of the phonon backend?
Comment 7 Myriam Schweingruber 2013-04-13 06:33:55 UTC
Closing for lack of feedback. Please feel free to reopen if you can reproduce this with the latest Phonon 4.6.0 or later and provide the requested feedback.