Bug 474259

Probably better reported upstream to bugs.kde.org.

We support and recommend the default working (as far as phonon is concerned anyway) pulseaudio solution.

Well, I have no problems with keeping pulseaudio, if it did not interfere with my mic capture volume. there is a known bug in F10 and (Ubuntu 8.10 too) where the mic capture volume is very low ( I literally have to scream when voice chatting) with HDA-Intel sound cards with digital microphones (on laptops) . And the affected application not only incluse skype , but also empathy and ekiga for the mic volume bug.

But that is besides the point, shouldnt xine backend work with plain simple alsa dmix (it used to work in F9 where too I had got rid of pulseaudio) !?!?!

We used to have a hack (I wrote) where we made Phonon always show the ALSA default device, but the problem is that this caused error messages on machines (including VMs) with no sound card at all. (We used that to support the PA ALSA plugin when the native xine-lib PA backend wasn't working. We dropped it once we had native PA output working.) And even worse, once we had that native xine-lib PA backend, with PA installed, in that situation (no sound card), it would try to connect to PA, fail (because PA only accepts connections if it has a working output), then try to use the default device, fail too (because there's no sound card), then fall back to PA again etc., ad infinitum (and spew an error message as a notification popup each time). So we dropped that hack.

A working heuristic might be to show the default device if and only if there's at least one hardware device. But I think you best take that up with Phonon's upstream developers (as Rex Dieter already suggested), as it's not a Fedora-specific issue, and does not even affect Fedora's default configuration.

As for why it worked in F9, did you ever upgrade your F9 at all? The ALSA default device hack was accidentally left in in the release (even though the PA ALSA backend was already working at that point), we killed it in an update soon after the release (because of the looping errors).

o! my bad there! I recollect now that I had shifted to phonon-gstreamer in f9 sometime as there was a bug with knotify cpu usage due to xine backend. ofcourse I was running F9 all updated :D (even from testing sometimes)

So , there are two possible ways for me(and many like me stuck with HDA Intel + low mic volume due to pulseaudio bug),
 
1] keep using gsteamer backend and tolerate bad performance in amarok2(eg internet streams metadata not loaded etc)
2]Hope for a fix to pulseaudio bug so that I can get back to Xine+pulseaudio and not have to scream into the microphone!

Thank you for the bug report.  This issue needs to be addressed by the upstream developers.  Please submit a report at http://bugs.kde.org. You are requested to add the bugzilla link here for tracking purposes. Please make sure the bug isn't already in the upstream bug tracker before filing it.

We *think* this is fixed in phonon-4.3 (coming with kde-4.2).  When it lands, please let us know if that's not the case.

Just installed phonon-4.3.0-2.fc10.i386 and phonon-backend-xine-4.3.0-2.fc10.i386 (kde-redhat), still does not work. :(

Looks like Phonon still doesn't understand what "default device" means...

Phonon tries to wrap the selected hardware device with plughw to get plugins, but that doesn't do the right thing with dmix, at least when it comes to interoperating with non-Phonon applications.

Reporter, could you please reply to the previous request? If you don't reply in within one month of the original request , we will have to close this bug as INSUFFICIENT_DATA. Thank you.

Hello all

I am sorry , I couldnt reply to the posts, my laptop is dead and I dont have a computer with me where I can try stuff to report here. I am stuck using Doze machines in my school :(  
On the upside, my new laptop is coming next week . Could you please elaborate a little more what exact info is needed.

Hi, I don't know if this is still actual for you, but as I've had now the same problem, maybe this will help you http://phonon.kde.org/cms/1032 - it worked for me :) You need to add this to device you wish to use in .asoundrc, then it will be listed in system settings.

hint {
        show on
        description "Name to display for the device"
    }

Reporter is this still an issue?

I am using pulseaudio now in Fedora 10, and the hence this issue doesnt bug me anymore. As lejma@seznam says, it works for him , so I guess we can count this issue as resolved.

Oops, reopening. Read his message carefully, he says:
> You need to add this to device you wish to use in .asoundrc
That's manual editing of a config file and it makes no sense for that to be required. Phonon should just be using the "default" device.

Hello,
I am testing fedora 11 with kde 4.2.3 and phonon-backend-xine-4.3.1-4.
I don't use pulseaudio because I don't like it and encounter the problem listed above.
The configuration only propose the soundcard "HDA intel" as output and not the default alsa mixer.
I've tried comment #12 but it does not change anything.
The problem is that applications like amarok blocks the soundcard.
Does someone have a solution to fix it ?

> Does someone have a solution to fix it ?

Well, the only solution I can offer is to use PulseAudio, it's the default for a reason... But you already wrote you don't like that solution.


Please (either you or the original reporter) file the bug upstream at https://bugs.kde.org/ as it needs to be addressed by the upstream Phonon developers. (We ask someone actually experiencing the problem to report the bugs so upstream has a real reporter to talk to in case they need more information.)

A simple solution is to add an hint for dmixer by default. So we can have the choice to use it on phonon.

Pulseaudio in F10 is broken in many ways (the bug I hate most is the pause bug http://www.pulseaudio.org/ticket/440 solved on pulseaudio 0.9.15, F10 uses 0.9.14). In addition to this pulseaudio eats cpu too much, mostly on slow machines.

So why we must be forced to use pulseaudio?

For all the people who wants to fix manually the problem, open /etc/asound.conf or ~/.asoundrc (if you don't want system wide configuration) and add something like this (thanks to http://noneus.de/?p=50 ):

pcm.!default {
  type plug   
  slave.pcm "dmixer"
}                   
pcm.dsp0 {          
  type plug         
  slave.pcm "dmixer"
}
pcm.dmixer {
  type dmix
  ipc_key 1024
  slave {
    pcm "hw:0,0"
    period_time 0
    period_size 1024
    buffer_size 8192
    #rate 44100 #many new cards are 48000 only
  }
  bindings {
    0 0
    1 1
  }
  hint {
    show on
    description "Dmixer Soundcard"
  }
}
ctl.dmixer {
  type hw
  card 0
}


bye!

*** Bug 520155 has been marked as a duplicate of this bug. ***

The workaround in #c18 does not work for me, Amarok is still blocking the sound card.

You can try this solution : 
https://bugs.kde.org/show_bug.cgi?id=194902

Add the controls to the file /etc/asound.conf for a multi-users settings, and restart.

This message is a reminder that Fedora 10 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 10.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '10'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 10's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 10 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Rex I bumbed this up to Rawhide.  If the issue is no longer applicable to Rawhide just change to to the latest version that it affects.

Steven

This bug appears to have been reported against 'rawhide' during the Fedora 13 development cycle.
Changing version to '13'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

This message is a reminder that Fedora 13 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 13.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '13'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 13's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 13 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Fedora 13 changed to end-of-life (EOL) status on 2011-06-25. Fedora 13 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.