Re: [pulseaudio-discuss] fedora 17 yum upgrade

2013-09-12 Thread Brendan Jones

On 09/12/2013 05:22 PM, Jim Duda wrote:

Hello,

I did a fresh fedora 17 install a couple of months ago.
I did a yum update after the install.
I haven't received any updates since then, which I find odd.
I've done a yum clean all.

How can I diagnose if my yum/rpm installation is configured correctly?

package-cleanup --problems and package-cleanup --orphans yields no clues.

Regards,

Jim

linux# yum check-update
Loaded plugins: fastestmirror, langpacks, presto, refresh-packagekit
http://linuxdownload.adobe.com/linux/x86_64/repodata/repomd.xml: [Errno 14] curl#6 - 
"Could not resolve host: linuxdownload.adobe.com; Unknown error"
Trying other mirror.
google  

 |  951 B  00:00:00
livna   

 | 1.3 kB  00:00:00
rpmfusion-free-updates  

 | 3.3 kB  00:00:00
rpmfusion-nonfree-updates   

 | 3.3 kB  00:00:00
updates/17/x86_64/metalink  

 | 2.2 kB  00:00:00
google/primary  

 | 1.9 kB  00:00:00
Loading mirror speeds from cached hostfile
  * fedora: mirror.solarvps.com
  * livna: rpm.livna.org
  * rpmfusion-free: mirror.liberty.edu
  * rpmfusion-free-updates: mirror.web-ster.com
  * rpmfusion-nonfree: mirror.liberty.edu
  * rpmfusion-nonfree-updates: mirror.web-ster.com
  * updates: mirror.solarvps.com
google


This is the wrong list for this question. However, the answer is here:

https://lists.fedoraproject.org/pipermail/announce/2013-July/003177.html

As F17 has reached end of life, you should probably upgrade.
http://fedoraproject.org/wiki/Upgrading

___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss


Re: [pulseaudio-discuss] jackdbus module, pulse fails to conform on device reservation API

2013-01-15 Thread Brendan Jones

On 01/14/2013 02:44 AM, Ian Malone wrote:

On 3 December 2012 04:07, Brendan Jones  wrote:

On 12/02/2012 11:42 PM, Tanu Kaskinen wrote:




Thanks, I'm now able to reproduce the bug. I will try to find the root
cause.


Thanks Tanu! Let me know what we can do to help. Fedora is a release behind
you guys for F18 (we will not be ugrading to 2.99 until F19 I believe), but
Rex Dieter should not have too many problems with backporting bug fixes into
2.1. He also provides a repo for those wanting to try the latest pulseaudio
but he hasn't updated it to 2.99 for F18. I will endeavour to take on a
bigger role in diagnosing pulseaudio bugs with you guys from here on.


This single commit, between 2.99.1 and 2.99.2 seems to be what
prevents the problem in for this case. Applying it to Fedora's 2.1
package also fixes the problem, I guess the rate change may be one of
the cases that causes the self-request to happen.

http://cgit.freedesktop.org/pulseaudio/pulseaudio/commit/?id=cd1102cce01e47645ed03ddf46a0a8b80d65fc9e

We could ask Rex to apply it in Fedora as a backport, but I suspect it
only avoids triggering the bug and is not the bug itself.


I can confirm that it works, but I'd lying if I said I understood why.
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss


Re: [pulseaudio-discuss] [PATCH] reserve-monitor: Don't trigger on our own events

2013-01-14 Thread Brendan Jones

On 01/13/2013 03:02 PM, Ian Malone wrote:

On 11 January 2013 14:57, David Henningsson
 wrote:

On 01/11/2013 02:37 PM, Brendan Jones wrote:


On 01/11/2013 02:04 PM, David Henningsson wrote:


This fixes a bug where pulseaudio would give up the device (due to
a request from JACK), but then immediately grab it again because
the monitor callback fired, telling that the device is now available.

(Note: the protocol does not specify a timeout, i e if pulseaudio
is requested to give its device up but JACK does not grab the dbus name,
at what point is PulseAudio allowed to re-grab it?)



Is this a fix for the bug that is mentioned in this thread?


http://lists.freedesktop.org/archives/pulseaudio-discuss/2012-November/015254.html



Maybe, but it wouldn't surprise me if there was more than one thing that
needed fixing here.



Indeed, unfortunately applied to 2.1 this doesn't fix that particular
problem (in fact stops 'test' playback in the phonon setup being
played). The issue in the November thread may have been fixed in
2.99.3, or maybe my testing was inconsistent. (That it doesn't fix one
particular error is of course not an objection to a patch that fixes
others.)


Hi Ian,

is this in conjuction with Tanu's patch as well?

regards,

Brendan
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss


Re: [pulseaudio-discuss] [PATCH] reserve-monitor: Don't trigger on our own events

2013-01-11 Thread Brendan Jones

On 01/11/2013 02:04 PM, David Henningsson wrote:

This fixes a bug where pulseaudio would give up the device (due to
a request from JACK), but then immediately grab it again because
the monitor callback fired, telling that the device is now available.

(Note: the protocol does not specify a timeout, i e if pulseaudio
is requested to give its device up but JACK does not grab the dbus name,
at what point is PulseAudio allowed to re-grab it?)



Is this a fix for the bug that is mentioned in this thread?

http://lists.freedesktop.org/archives/pulseaudio-discuss/2012-November/015254.html




___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss


Re: [pulseaudio-discuss] jackdbus module, pulse fails to conform on device reservation API

2012-12-03 Thread Brendan Jones

On 12/02/2012 11:42 PM, Tanu Kaskinen wrote:

On Wed, 2012-11-28 at 23:24 +0100, Brendan Jones wrote:

On 11/24/2012 02:06 PM, Tanu Kaskinen wrote:

On Mon, 2012-11-19 at 21:45 +0100, Brendan Jones wrote:

I'm seeing this in virtual box under KDE (also Fedora 18 / pulseaudio 2.1).


I guess it should be quite easy to reproduce this if I'd try this with
virtual box with the same setup as you. I've never used virtual box (or
any other virtual machine), but I think I should learn to do that. After
installing virtual box, I guess I need some OS image - could you point
me to the one that you were using when you reproduced this?


Thanks for following up. I also tried your patch with the same results.

You can try the latest Fedora 18 Beta. I've been using the Live KDE spin.

http://fedoraproject.org/get-prerelease

You can tab to get to the live kernel boot parameters and add a 3 to get
to init 3 equivalent.

  From there you can edit the /usr/bin/start-pulseaudio-kde script to add
log in and install packages into the live image as you require, e.g.

su -c 'yum install jack-audio-connection-kit-dbus d-feet
pulseaudio-debuginfo qjackctl'

Followed by init 5 to get X under liveuser


Thanks, I'm now able to reproduce the bug. I will try to find the root
cause.

Thanks Tanu! Let me know what we can do to help. Fedora is a release 
behind you guys for F18 (we will not be ugrading to 2.99 until F19 I 
believe), but Rex Dieter should not have too many problems with 
backporting bug fixes into 2.1. He also provides a repo for those 
wanting to try the latest pulseaudio but he hasn't updated it to 2.99 
for F18. I will endeavour to take on a bigger role in diagnosing 
pulseaudio bugs with you guys from here on.



___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss


Re: [pulseaudio-discuss] jackdbus module, pulse fails to conform on device reservation API

2012-11-19 Thread Brendan Jones

On 11/13/2012 08:20 PM, Tanu Kaskinen wrote:

On Sun, 2012-11-11 at 12:21 -0500, Ian Malone wrote:

On 10 November 2012 05:25, Ian Malone  wrote:

On 9 November 2012 17:34, Tanu Kaskinen  wrote:

On Tue, 2012-11-06 at 15:58 -0500, Ian Malone wrote:

method call sender=:1.110 ->
dest=org.freedesktop.ReserveDevice1.Audio1 serial=6
path=/org/freedesktop/ReserveDevice1/Audio1;
interface=org.freedesktop.ReserveDevice1; member=RequestRelease
int32 2147483647
error sender=:1.35 -> dest=:1.110
error_name=org.freedesktop.DBus.Error.UnknownMethod reply_serial=6
string "Method "RequestRelease" with signature "i" on interface
"org.freedesktop.ReserveDevice1" doesn't exist
"





If I hadn't seen it before I would say that that's exactly the message
I expect a message framework (d-bus here) to generate when the method
wasn't present. And indeed it is:
$  dbus-send --session --print-reply --reply-timeout=2000
--type=method_call --dest=org.freedesktop.ReserveDevice1.Audio1
/org/freedesktop/ReserveDevice1/Audio1
org.freedesktop.ReserveDevice1.RequestRelease int32:5
Error org.freedesktop.DBus.Error.UnknownMethod: Method
"RequestRelease" with signature "i" on interface
"org.freedesktop.ReserveDevice1" doesn't exist

I don't know how to capture this at the command line, so please see
the d-feet shot of this:

https://picasaweb.google.com/lh/photo/Mnty0Ul3ilCN_pB-ctJoD9MTjNZETYmyPJy0liipFm0?feat=directlink


Ok, I feel a bit stupid for not taking into account that libdbus or the
bus daemon or whatever might generate the error message.


Audio1 is reserved (the service exists), but the object to request a
release for Audio1 doesn't exist. Getting to this state was actually
quite easy:
1. Start into KDE (pulse is set up as normal for Fedora and autostarted).
2. Start d-feet, you may catch the ReserveDevice1 services before they
disappear, but wait till they do.
3. Open the KDE audio setup dialogue and test playback, this causes
pulse to lock the capture device (hw:0 here) and the playback device
(hw:1).
4. Look at the 'reserved' services. Audio1 is reserved, but can't be
released because there's no object to provide the method.



===
--- a/src/modules/reserve.c
+++ b/src/modules/reserve.c
@@ -409,6 +409,11 @@ int rd_acquire(
goto fail;
}

+   if (k == DBUS_REQUEST_NAME_REPLY_ALREADY_OWNER) {
+   // Potential leak?
+   goto success;
+   }
+
if (k == DBUS_REQUEST_NAME_REPLY_PRIMARY_OWNER)
goto success;
===
It seems rd_acquire can get called while pulse still has the service
name (how? don't know. I've tried a return 0 there, but the object
path has already been unregistered at that point). Currently that
means it unregisters the filter handler and the object path for
releasedevice1, turning the service into a zombie until pulse is
killed. I've tried fixing this by changing the way d->owning is used,
but anything but the current setup seems to get stuck in a loop
between rd_callback, the filter_handler in reserve.c and rd_release,
possibly because unregistering the service triggers the filter_handler
with namelost somehow. Anyway, thou shalt check for possible return
values.


Thanks for digging into this. I should really test this myself. I'll try
to do that tomorrow.



Hi

I'm seeing this in virtual box under KDE (also Fedora 18 / pulseaudio 2.1).

On my real desktop, if I configure qjackctl to autostart on logon and in 
turn autostart jack I do not see the problem.


If I stop jack and resume normal desktop use and restart jack after a 
time, the issue does occur.


pulseaudio --kill; pulseaudio --start always fixes the issue.

Is there something I can look out for in the logs, or something I can 
try via pacmd while it is happening to aid in debugging this issue?


We are very close to the release date of the Fedora Audio spin and 
really want to have jack and pulse coexist directly from the install 
media but this issue is holding us back.


Let me know if there is anyway I can help

thanks

Brendan

___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss


Re: [pulseaudio-discuss] strange pulse / jack behaviour

2012-10-30 Thread Brendan Jones


On 10/30/2012 01:46 PM, Patrick Shirkey wrote:


On Tue, October 30, 2012 10:45 pm, Richard Bown wrote:

On Tue, 2012-10-30 at 22:05 +1100, Patrick Shirkey wrote:

On Tue, October 30, 2012 8:17 pm, Richard Bown wrote:

On Tue, 30 Oct 2012 11:16:18 +1100
Patrick Shirkey  wrote:

< a large bit of snipping>


Thanks Richard. In this case there is only one device.

My concern here is that I was expecting pulse and jack to automatically
reconfigure if using the dbus option. Isn't that the point of the
module-jackdbus-detect?

It seems to be asking alot of the user (especially those not initiated
in
the audio system) to expect them to find and then disable the offending
module to get things running.



You are asking a lot to get the developers of dbus, pulseaudio,
portaudio, jack, alsa  all to iron out a few wrinkles.

Also you need to be running the latest version of all the apps to make
sure that they have not already been sorted, so add the OS version
maintainers to the list to keep their packages up to date.
Running Debian will not keep you up to date with package changes.
Studio64 , one of the debian based DAW  distros is very outdated.




Debian Wheezy is keeping pace with latest Fedora. It is the Testing
version of Debian.

I haven't tried testing this with Fedora 17 yet but my impression is that
I'm not the only one who is having a difficult time getting
jackdbus-detect to work as advertised. The last time I seriously checked
was a few years back and at the time module-jackdbus-detect was fairly new
so the auto configuration was still being worked on. It seems reasonable
that by now the kinks would have been ironed out.


FWIW module-jackdbus-detect is working fine with Fedora 17/18 without 
any modification


regards,

Brendan

___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss


Re: [pulseaudio-discuss] restarting pulseaudio

2012-09-22 Thread Brendan Jones

On 09/22/2012 05:31 PM, Richard Bown wrote:

Hi All,
I've managed to write a script so I can use an application that uses jackdmp,
jack2.
it gets the Alsa card number, and then gets the module number for the module
for the card I want to use and unloads the module, starts jackd and loads the
jack-sink and jack-source modules.
jack-dbus sorta works, it doesn't load the jack sink and source modules, but it
does unload them when jackd stops, Hence the manual load of the jack sink and
source modules.
The minor problem I have is unless I reboot I'm left with 3 of the 4 audio
devices available with PA.
restarting PA with --kill and --start does not restore all 4 devices :(
Is there any way I can restart PA so that it finds all four devices
dynamically ?
I'm only running PA V 1.1, which I think is pretty ancient, would it be
worthwhile for me to download the source code and compile the latest release..

Also :Can jack-sink and one of the alsa sinks be combined ??


I believe Rex Dieter has a repo with version 2.0.0 for Fedora 17.

I'm not sure if it will help.

http://repos.fedorapeople.org/repos/rdieter/pulseaudio-backport/


___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss


Re: [pulseaudio-discuss] flushing dynamically loaded modules

2012-09-22 Thread Brendan Jones

On 09/20/2012 07:35 PM, Tanu Kaskinen wrote:

On Thu, 2012-09-20 at 18:10 +0100, Richard Bown wrote:

Hi ,
sorry for the newbie type questions.
I've looked in the FAQs, and probably missed the answer.
If I load a module from CLI  with pactl or with paprefs
is there a CLI command to flush the loaded modules.

I haven't found the config file which is created and added to by paprefs, or
from pactl, its location would help please.


The papref settings are stored in gconf. But since you can undo anything
that you do with papref with papref, papref isn't really a problem here.


I've tried using unload-module, but that requires an index to function.


How is that a problem? I mean, I know that it's a bit cumbersome to dig
out the indexes with "pactl list modules" (the next pulseaudio release
will support giving module name instead of index, yay!), but from your
description I don't get why requiring an index would prevent you from
unloading the modules.


The modules in question are module-jack-sink and module-jack-source, and
pulseaudio wont start if they are loaded and jackd is not running.

Rebooting clears them, so the modified config must be in a tmp file somewhere.


How do you load the jack modules? There's certainly no tmp file storing
the jack module configuration, so if you have loaded them just with
pactl, restarting pulseaudio will clear the configuration.


A simple way to get the index:

pactl load-module module-jack-sink  > ~/.pulse/jack-sink;
pactl load-module module-jack-source > ~/.pulse/jack-source;

and unload:

pactl unload-module `cat ~/.pulse/jack-sink`;
pactl unload-module `cat ~/.pulse/jack-source`;

___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss