gmane.comp.audio.jack.ladish

Re: PS: Re: jack2 jackdbus needs testing

Frank Kober — 2012-10-30T10:16:09

I meanwhile worked around this by using

LINKFLAGS="-lm -lstdc++" ./waf configure --prefix=/usr .......

This may be necessary on some systems, I think mine uses gold as linker.

Just for the archives...
Frank.



----- Mail original -----

PS: Re: jack2 jackdbus needs testing

Frank Kober — 2012-10-27T15:47:14

forgot:

I have gcc-4.7.2 here


----- Mail original -----

Re: jack2 jackdbus needs testing

Frank Kober — 2012-10-27T15:44:24

Hi

I get the following linking error. Is an explicit link to stdc++ missing somewhere?


[223/263] cprogram: build/example-clients/server_control.cpp.2.o -> build/example-clients/jack_server_control
example-clients/server_control.cpp.2.o(.eh_frame+0x1ab): error: undefined reference to '__gxx_personality_v0'
collect2: error: ld returned 1 exit status


Best
Frank



----- Mail original -----

jack2 jackdbus needs testing

Nedko Arnaudov — 2012-10-24T11:54:04

Stephane plans to release jack-1.9.9 soon. He fixed the freeze and
crash on jack server stop bugs that I was able to reproduce on my
machine. I know other jackdbus users are affected by these bugs as
well. So please check if the latest jack2 git fixes the issues for you.

The fixes are commited into the master branch and are merged to the
ladi-experimental branch.

Feel free to report other jackdbus bugs that affect your ladish
workflow.

If no problems are found by the end of the week (Oct 28th), jack-1.9.9
will be released.

test, please ignore

Nedko Arnaudov — 2012-10-27T11:40:47

please ignore this mail

Re: dbus-related start-up failures

Nedko Arnaudov — 2012-09-01T13:27:26


And it suggests that archive is provided by Gmane.


laditray is not part of ladish. It is part of laditools. This is why
there is no ticket on ladish.org.

I have no other pointers.



Have you seen the comment at the begining of xml file? "You probably
don't want to edit this because it will be overwritten next time
jackdbus saves." You should use ladiconf/ladi-control-center,
jack_control or some other tool to configure jackdbus over D-Bus.


What is the error you see in the jackdbus log file?

Re: dbus-related start-up failures

Dan Muresan — 2012-08-31T19:14:47

Ah. So jackdbus saves its most recent settings into
~/.config/jack/conf.xml. By editing this file and replacing hw:1 with
hw:0 I was able to get a little further.

My new problem is that jackdbus sometimes fails to "dislodge" pulse
from hw:0, but I'm not sure when this occurs.

Re: dbus-related start-up failures

Dan Muresan — 2012-08-31T19:10:52

Kind of hard when even http://ladish.org/wiki/mailing_list admits that
the web interface is down (no wonder google doesn't seem to index it).
However I found this:

http://www.digipedia.pl/usenet/thread/11090/231/

(can't find the actual ticket on ladish.org) which ends with Wayne
saying that "laditray: autostart: 'False'" (or '0' or whatever)
doesn't prevent laditray from autostarting jackdbus. Which also is the
case for me. Any other pointers?

Re: dbus-related start-up failures

Dan Muresan — 2012-08-31T17:54:04

Well, I've seen this before in other contexts, but this the issue was
indeed solved by the jackdbus log. The problem was that I'd removed an
external soudcard and was trying to switch over to hw:0.

How does jackdbus determine which ALSA device to take over?

Re: dbus-related start-up failures

Nedko Arnaudov — 2012-08-31T07:29:34


This is python exception because of error reported by jackdbus
(suggested by "org.jackaudio.Error.Generic: Failed to open
server"). "org.jackaudio.Error.Generic" is the error
identification. "Failed to open server" is the human readable message.

You should have more info on the error in the jackdbus log file.

If you want debugger, find a python debugger. Otherwise, logging is what
I'd use for this kind of stuff.

Your laditray is trying to autostart the jack server. This is probably
not a good idea for ladish setups. Check the list archives for info how
to disable it. Also, you may want to contact the laditools maintainer,
Alessio Treglia. He is not subscribed to this list.

If restarting X fixes the issue for you, then you are probably affected
by jack bug in non-jackdbus code. Either reactivate jackdbus (both
laditools and jack_control provide a mean for this) of force kill it,
like falktx already suggested.

Re: dbus-related start-up failures

Filipe Lopes — 2012-08-31T06:21:33

I think this is caused by a jackdbus crash when shutdown (unless this is a
different thing from what happens to me).
usually a simple:
$ killlall -9 jackdbus
does the trick, and jack is able to start again

not sure if this is the case... ?

On Fri, Aug 31, 2012 at 7:09 AM, Dan Muresan <danmbox-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org> wrote:

dbus-related start-up failures

Dan Muresan — 2012-08-31T06:09:11

Hi,

I get this kind of failure once in a while. I don't know how to fix
it, except for restarting X, which (according to Murphy's laws) is
usually a no-no at the time (e.g. I'm running some long backup
procedure):


$ laditray

Traceback (most recent call last):
  File "/usr/bin/laditray", line 120, in <module>
    laditray().run()
  File "/usr/bin/laditray", line 43, in __init__
    laditools.manager.__init__(self,
self.global_config.get_config_section ('ladimenu'), autostart)
  File "/usr/lib/laditools/laditools/ladimenu.py", line 54, in __init__
    self.jack_start ()
  File "/usr/lib/laditools/laditools/ladimenu.py", line 89, in jack_start
    self.get_jack_controller().start()
  File "/usr/lib/laditools/laditools/jack_controller.py", line 64, in start
    self.iface.StartServer ()
  File "/usr/lib/python2.7/dist-packages/dbus/proxies.py", line 70, in __call__
    return self._proxy_method(*args, **keywords)
  File "/usr/lib/python2.7/dist-packages/dbus/proxies.py", line 145, in __call__
    **keywords)

Re: Multi-client processes reusing port names

Dan Muresan — 2012-08-27T15:01:19

OK... So it doesn't seem that it will be easy to fix. which is a pity.

On Mon, Aug 27, 2012 at 4:22 PM, Nedko Arnaudov <nedko-pIwpoS7APZaLwutG50LtGA< at >public.gmane.org> wrote:

Re: Multi-client processes reusing port names

Nedko Arnaudov — 2012-08-27T13:22:58


It is not true. It was how I was thinking it would be.

Re: Multi-client processes reusing port names

Dan Muresan — 2012-08-27T11:27:04

You wrote in that ticket that "when ladish gets support for jack-session,
guitarix (and any other jack-session-able app) will/should work with
ladish". Is that still true? I can't seem to be able to reproduce that.

On Monday, August 27, 2012, Nedko Arnaudov wrote:

Re: Multi-client processes reusing port names

Nedko Arnaudov — 2012-08-27T09:57:10


ATM ladish only manages first client of each app. Check
http://ladish.org/ticket/114 for more info.


These are not naming assumptions, but I agree it can be frustrating.

Multi-client processes reusing port names

Dan Muresan — 2012-08-27T06:34:16

Hi,

it seems that, when a single process starts multiple jack clients (say
C1 and C2), but those clients reuse port names (say C1:in, C2:in,
C1:out, C2:out), ladish only sees one instance for each port.

Non-mixer tends to do this when using multiple strips. In any case...
it was frustrating to be unable to connect a port because of naming
assumptions.

TEST - please ignore

Marc-Olivier Barre — 2012-05-09T15:29:57

Thank you :)

--
Marc-Olivier Barre
XMPP ID : marco-qY6+oKxccOnaOVYouRjCbQ< at >public.gmane.org
www.MarcOChapeau.org

Re: updated ebuild

Wayne — 2012-04-23T23:22:16

Il giorno mar, 17/04/2012 alle 00.58 +0200, Alessio Treglia ha scritto: 



ahoy Alessio,

    thanks for the reply and sorry for me delayed response.  the
requested info is below:




    attached.




    i am using GNOME 2.32.1 on Gentoo, Metacity window manager. with the
Clearlooks theme.

Re: updated ebuild

Nedko Arnaudov — 2012-04-16T11:25:59


I don't get this on my machine


I get this as well


I don't know if this what is the correct behaviour. I'm CCing Alessio
Treglia, he should know.


libappindicator seems to be Unity/Ubuntu specific component. Maybe its
not strictly required. Alessio, please confirm.

Re: updated ebuild

Wayne — 2012-04-11T21:17:04

Il giorno sab, 07/04/2012 alle 18.22 +0300, Nedko Arnaudov ha scritto: 



thanks as always Nedko.  your directions worked great, i re-emerged the
python packages as needed and laditools is installing.  however, when
running ladi-system-tray, i am now getting the following error:

$ ladi-system-tray 
Gtk-Message: Failed to load module "gnomesegvhandler"
ERROR:root:Could not find any typelib for AppIndicator3

the menu still appears in the system tray area, but the
theme/decorations are all different that the other icons, and the actual
laditray icon is missing.

i am currently trying to install dev-libs/libappindicator to remove the
ERROR, but so far that is not installing either.

thanks+peace, w