Bug 506021
Summary: | knotify4 needs to close the audio devices when it isn't playing anything | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Amit Shah <amit.shah> |
Component: | phonon | Assignee: | Rex Dieter <rdieter> |
Status: | CLOSED INSUFFICIENT_DATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | medium | Docs Contact: | |
Priority: | low | ||
Version: | 11 | CC: | amit.shah, fedora, gauret, jreznik, kevin, lkundrak, lorenzo, lpoetter, ltinkl, rdieter, smparrish, than, wonghow, wtogami |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2009-09-12 23:32:38 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Amit Shah
2009-06-15 10:17:38 UTC
PA adapts its wakeup intervals to what clients require and also has a logic to shorten them if we ever ran into a dropout, to minimize the chance that we run into another. PA will log about the wakeup interval changes in syslog. Could you please check what is written there? Any syslog lines which say something like "...increasing wakeup time..." or so? *** Bug 506022 has been marked as a duplicate of this bug. *** I don't see any such messages in my /var/log/messages file. Hmm, the output above, is anything actually played then? It seems that knotify4 seems to keep open the audio connection to PA and doesn't pause it, which then causes PA to constantly run the audio loop, and not close it because it assumes that the client is just temporarily underrun but actually playing something. knotify4 should not keep the audio device open if it isn't playing anything. Nothing was playing at that moment but I doubt anything could be played as well -- I tried twinkle and didn't get any sounds and I think kde too was trying to get sound out -- wasn't working. It got fixed after some fiddling with pulseaudio (remove, change kde sound to output via alsa, reinstall PA, change kde sound to pulseaudio again, reboot; just logout/login didn't work). Hmmm, I am not a KDE guy, I am pretty sure that PA is not as much fun as it could be on KDE, but uh, that's something the KDE folks need to fix. I will now reassign this to kdenotify4, so that they fix it to close the audio device when nothing is being played. If that is fixed, then PA will close the device when idle and wakeups go to zero. Any other way to try to reproduce this other than twinkle (a legacy kde3 app, which likely uses arts... *shudder*). ? From my casual use, and occasional music (amarok), I definitely do not see this. aRts closes itself after 60 seconds of inactivity and the old KDE 3 knotify didn't keep the aRts connection open. See how there's no aRts showing up in the list of clients. So it's really knotify4 which is at fault for PA not suspending. (Also pedantically reassigning from kdebase to kdebase-runtime because that's where knotify4 sits.) i cannot reproduce it by using phonon-gstreamer-backend, it's a bug in xine-libs https://bugs.kde.org/show_bug.cgi?id=151546 I cannot reproduce using phonon-backend-xine either. I'd bet there's a layered compatibility issue here, that includes any/all of phonon/xine-lib/pulseaudio/alsa-driver Which is what prompted my "how to reproduce" comment #7 It's not specific to twinkle. For example, I'm running twinkle right now without seeing any of arts/knotify4/pulseaudio using much CPU. There's some condition in knotify4 which causes it. I'm not sure what I had done, though, to get that condition. As a matter of fact, using phonon-backend-xine, after doing some amarok'ing... powertop lists 44.8% (114.7) <kernel core> : hrtimer_start_range_ns (tick_sched_timer) ... 1.5% (3.4) knotify4 : hrtimer_start_range_ns (hrtimer_wakeup) Now, switched to phonon-backend-gstreamer, (logout/login), again after some amarok'ing... powertop: 38.6% (200.6) <kernel core> : hrtimer_start_range_ns (tick_sched_timer) 18.4% (98.6) pulseaudio : hrtimer_start_range_ns (posix_timer_in) 17.1 (97.2) pulseaudio : hrtimer_start_range_ns (hrtimer_wakeup) ... 4.2% (20.7) knotify4 : hrtimer_start_range_ns (hrtimer_wakeup) interesting, -gstreamer backend seems to the one exhibiting the reported problem(s) for me. Thank you for taking the time to report this issue. This is an issue that needs to be addressed by the upstream developers. Please report this at http://bugs.kde.org and then add the upstream report information to this report. We will monitor the upstream report for a resolution to this issue, and will review any bug fixes that become available for consideration in future updates. Setting status to NEEDINFO, and awaiting upstream bug report URL for tracking. Thanks in advance. -- Steven M. Parrish - KDE Triage Master - PackageKit Triager Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers Since there are insufficient details provided in this report for us to investigate the issue further, and we have not received feedback to the information we have requested above, we will assume the problem was not reproducible, or has been fixed in one of the updates we have released for the reporter's distribution. Users who have experienced this problem are encouraged to upgrade to the latest update of their distribution, and if this issue turns out to still be reproducible in the latest update, please reopen this bug with additional information. Closing as INSUFFICIENT_DATA. -- Steven M. Parrish - KDE Triage Master - PackageKit Triager Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers |