amarok does not work with pulseaudio [hardy]

[Mikael Nilsson]

Binary package hint: amarok

Trying to play any files using latest hardy gives me xine errors and amarok hangs.

Killing pulseaudio and restarting amarok makes everything work again.

[unksi (unksi)]

Happens here as well. Works well with ALSA set as backend.

[unksi (unksi)]

Here are attachments for outputs on terminal/apport. On fully updated Hardy amd64.

[Mikael Nilsson (mini)]

This bug is making Hardy really annoying for me.

amarok plays well for some time. Then, for no apparent reason, amarok complains about not being able to initialize device. Killing pulseaudio makes amarok play again. The same happens *every* time I login and start playing music with amarok.

Hardware: Dell XPS M1710 laptop, Sigmatel 9200 (intel-hda), running GNOME and up-to-date hardy.

[Matti Lindell (mlind)]

Looking the attached terminal output, this could be a dupe of bug #165220 (and http://www.pulseaudio.org/ticket/137) which suggest libtool as a culprit. Tried purging all pulseaudio related binaries and reinstall those back? You may need to use --force-depends flag with dpkg to ignore dependency issues temporarily.

[Daniel T Chen (crimsun)]

This is not an amarok issue. If you use the xine backend for amarok along with PulseAudio, you _must_ configure amarok to use esd instead of ALSA.

[Mikael Nilsson (mini)]

tis 2008-03-18 klockan 16:17 +0000 skrev Daniel T Chen:
> This is not an amarok issue. If you use the xine backend for amarok
> along with PulseAudio, you _must_ configure amarok to use esd instead of
> ALSA.

Oh, great!

I'm sure all end users will realize that immediately. The above
description seems like a perfect usability bug in amarok. How in the
world is anyone expected to know the above?

Given that pulseaudio is the defaultin hardy, and xine backend is the
only one, the default of "auto" must be a bug.

Please reopen.

/Mikael

>
> ** Changed in: amarok (Ubuntu)
> Status: Confirmed => Invalid
>
--
<email address hidden>

Plus ça change, plus c'est la même chose

[Mikael Nilsson (mini)]

Reopening.

Based on Daniel Chen's comment, the user is supposed to set the output to esd for the xine plugin. There is no esd choice for the xine plugin, so the suggestion does not work.

[KhaaL (khaal)]

I also have this annoying problem, and unable to choose ESD for xine.

[Brian Neltner (neltnerb)]

I just fixed this issue on my computer. Installing the package libxine1-gnome enabled ESD support for xine, and it was subsequently selectable in Amarok. This package should be added as a dependency for amarok for people using amarok from inside of gnome.

Additionally, I agree that the next update of Amarok should use ESD as the default output plugin (it still reported it as invalid, despite it playing sound through ESD once selected). I assume that the issue is that KDE users will not be wanting to use ESD? Is there a mechanism for selecting the output plugin depending on the sound manager being used?

[Pacho Ramos (pacho)]

This patch should fix xine-pulse plugin issues and fix pulse problems in amarok:
http://0pointer.de/public/xine-pulse-rework.patch

[Jack (ubuntu-chrisjs)]

Installing libxine1-gnome also worked for me.

[Pablo Estigarribia (pablodav)]

It's truth It works with libxine1-gnome, after install the package you can select esd as a sound server on amarok.
Also I had to install kcontrol and set the configuration for arts to work with esd.
I think is very important that these configurations come by default on Ubuntu 8.04, end users don't know anything about pulseaudio, esd, etc.

[Pacho Ramos (pacho)]

I already told about it above:

http://0pointer.de/public/xine-pulse-rework.patch needs to be applied to xine-lib for fixing its pulse plugin, after that, it amarok should being able to work with xine+pulse

You can also look to Mandriva 2008.1 src.rpm that has this problem already fixed (and many other pulse problems also)

Thanks a lot

[Harald Sitter (apachelogger)]

The question is, would Autodetect then use the pulseaudio plugin if alsa fails?
If not this would only be partly a solution.

[Pablo Estigarribia (pablodav)]

I don't know, I think amarok will not autodetect to use pulseaudio if alsa fails.
Also I don't have idea howto install xine pulse patch, i tried to search for a package: apt-cache search xine pulse but i didn't find anything.
Now It's working amarok for me with esd after install libxine1-gnome I had to set manually amarok engine to use esd. I think It should be done by default on Ubuntu for amarok package dependencies and configuration or something like this.
Also I would like to try this xine pulse patch, but I don't know how to.

Br,
Pablo.

[Kevin Oberle (kevin.oberle)]

You guys are missing that pulse audio was actually an option in amarok right up until an update released sometime around early april late marchish. It was working beautifully, mind you it still had to be manually selected by the user.

I'm wondering if it's possible to track down what changed around that time and find out what update removed the pulse audio option. Ideally someone could figure that out and hopefully bring back the pulse option but this time have it set as the default or have the auto detect favor it.

@Harald "would Autodetect then use the pulseaudio plugin if alsa fails"

Shouldn't it be the other way around? Use alsa if pulse fails??

[Harald Sitter (apachelogger)]

I did patch xinelib and run a stress test for about 2 hours now, using various sound applications at the same time. The patch Pacho pasted works like a charm.

Also autodetection works properly, if pulseaudio blocks access for alsa xine will automagically fallback to pulseaudio (i.e. the user will not see any error or something in case pulse blocks the audio device).

I attached a debdiff re-enabling pulseaudio in xine and applying the patch in question.

[dtaylor84 (davidt-launchpad)]

I can confirm that the attached debdiff fixes the problem for me -- i.e amarok now shows "pulseaudio" as a xine output plugin and autodetects it correctly.

[Pablo Estigarribia (pablodav)]

Very good, How I can download and test it?
I tried to leave autodetect for xine engine in amarok with libxine1-gnome installed, but it seems to work with alsa first instead of work with esd.

[Reinhard Tartler (siretart)]

the debdiff introduces changes to the packaging system (introduction of quilt), so I don't think it really qualifies for ubuntu.

Moreover, this bug is a duplicate of bug #131914, which has a proposed patch and link to test packages in the motumedia archive.

[XmIsTeR (xmisterhu)]

The patch fixed it for me too.

[Launchpad Janitor (janitor)]

This bug was fixed in the package xine-lib - 1.1.11.1-1ubuntu3

---------------
xine-lib (1.1.11.1-1ubuntu3) hardy; urgency=low

  [ Darren Salt ]
  * Fixes from upstream hg:
    - Matroska demuxer regression. (Closes: #474316)
    - PulseAudio plugin backported & re-enabled.
      This takes precedence over ALSA, but falls back cleanly.

  [ Reinhard Tartler ]
  * Cherrypick the above changes to the ubuntu package (LP: #176332, #131914)

 -- Reinhard Tartler <email address hidden> Sat, 12 Apr 2008 23:13:24 +0200

[Giannis M. (m-for-migish)]

The new package in the repositories works very well.

Thanks a lot!

[nstamoul (nikos-gr)]

Works like a charm!

[Pablo Estigarribia (pablodav)]

It works for me also!
Thanks a lot!

[Jeff Wilson (atlanta800)]

Works perfect! Thanks a ton!

[Ken J (mastermindg)]

I am not seeing this package in the repositories.

[Ken J (mastermindg)]

I am looking at the repository now and all of the libxine-related packages are all 1.1.11.1-1ubuntu3.

I am experiencing the same issue as described above. Amarok was working with xine and pulseaudio fine and then after a reboot I got a popup saying that I had to update my sound card with asoundconf and now xine is broken.

[Motin (motin)]

Same here, using 1.1.11.1-1ubuntu3.1 and Xine -> PulseAudio doesn't work any longer. It used to work in August... Wrote about this in the forums: http://ubuntuforums.org/showthread.php?t=923971

The question is if Ken J's and my issues are related to this bug report or if this is due to some new bug...