Bug 585074 - knotify4 prevents other programs from using sound
Summary: knotify4 prevents other programs from using sound
Alias: None
Product: Fedora
Classification: Fedora
Component: kdebase-runtime
Version: 12
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Than Ngo
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2010-04-23 04:45 UTC by patchesthecaveman
Modified: 2010-04-25 04:38 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2010-04-25 04:38:41 UTC
Type: ---

Attachments (Terms of Use)

Description patchesthecaveman 2010-04-23 04:45:44 UTC
Description of problem:
"knotify4" prevents other programs from accessing the sound until it is killed

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Boot computer/login to KDE
2. Startup sound plays
3. Open any media application (including Flash in browser or VLC, etc.)
Actual results:
sound doesn't work

Expected results:
sound plays

Additional info:

$ lsof /dev/snd/pcmC0D0p 
knotify4 1775   tc  mem    CHR  116,4          11074 /dev/snd/pcmC0D0p
knotify4 1775   tc   13u   CHR  116,4      0t0 11074 /dev/snd/pcmC0D0p

The only way I've found to get sound back is to kill the "knotify4" process, which works until another notification is triggered, at which point I must kill it again.

Comment 1 Rex Dieter 2010-04-23 13:53:03 UTC
I depends on a lot of things, mostly I take it you're not using pulseaudio?

Then, it may depend on which phonon backend you're using.

Comment 2 Kevin Kofler 2010-04-23 16:16:41 UTC
Basically, concurrent access to sound devices only works with PulseAudio, that's what it is for!

If you want to use dmix, you have to set that up manually, it is no longer set up automatically in Fedora because it has been replaced by PulseAudio.

Comment 3 Kevin Kofler 2010-04-23 16:17:21 UTC
And re dmix, see also bug 474259. (This might be a duplicate of that bug.)

Comment 4 patchesthecaveman 2010-04-24 20:23:00 UTC
I'm using the default gstreamer backend.  Would switching it to xine help?  I don't know what dmix is, and since you say it requires manual setup I'm assuming I'm not using it.

When PulseAudio is installed sound doesn't work at all on my computer, and KDE complains about default device problems at every login.  (Something that depended on it reinstalled it yesterday and I got some error messages out of VLC that might be useful in that regard.  I'll reinstall it later to see if I can figure that one out.)  Another strange problem that might be related is that I get no sound or video out of Juk or Dragon Player; I've had to use VLC.

At any rate, shouldn't knotify4 only lock the sound device when it's actually producing a sound?  

The low battery warning and adapter plug/unplug sounds do work while sound is playing from VLC.  In fact, right now both processes are sharing /dev/snd/pcmC0D0p just fine:
$ lsof /dev/snd/pcmC0D0p 
knotify4 2470   tc  mem    CHR  116,4          11948 /dev/snd/pcmC0D0p
knotify4 2470   tc   15u   CHR  116,4      0t0 11948 /dev/snd/pcmC0D0p
vlc      2471   tc  mem    CHR  116,4          11948 /dev/snd/pcmC0D0p
vlc      2471   tc   15u   CHR  116,4      0t0 11948 /dev/snd/pcmC0D0p

Only when I login and infrequently during the course of use do I have to kill knotify4 to get sound out of anything.

Comment 5 Kevin Kofler 2010-04-25 04:38:41 UTC
The default is Xine, not GStreamer. But I think it doesn't really matter here which you're using.

So you disabled PulseAudio and you didn't enable dmix (because you don't even know what it is)? Then of course only one device can access the audio device at a time. This is working exactly as designed, sorry.

Note You need to log in before you can comment on or make changes to this bug.