headers
Jonathan Woithe | 1 May 2012 02:08

Re: incompatible version of ffado error message

On Mon, Apr 30, 2012 at 03:35:54PM +0200, Adrian Knoth wrote:
> On Mon, Apr 30, 2012 at 11:26:32PM +1000, Allan Klinbail wrote:
> > I've been using jack with ffado as the driver for a few years now.
> > Today, after upgrading ffado to the latest svn , (then tested working).
> > I then upgraded to the latest jack svn version. Following this I started
> > receiving the following incompatible error message. 
> 
> You were doing it in the wrong order.
> 
> FFADO detects the jackd version at compile time. If it's a new jackd
> version supporting the new API, it switches to the new API.

Similarly, if there is no jackd installed at compile time ffado assumes that
the jackd which will ultimately be available will support the new API.

So in Allan's case, he compiled a new FFADO against an old jack, which
resulted in a FFADO which uses the old API.  The old jack was happy with
this and everything worked.

> You've just told FFADO to adjust itself to an old jackd version.
> Simply compile FFADO again.

Yep, that should work.

However, from a development point of view I'm a little surprised that the
latest jackd didn't simply accept FFADO as it was.  The relevant line in
current jack1 is drivers/firewire/ffado_driver.c, line 786 and following.

  if(ffado_get_api_version() < FIREWIRE_REQUIRED_FFADO_API_VERSION) {
    printError("Incompatible libffado version! ...
(Continue reading)

Permalink | Reply | 5 comments |
headers
Jonathan Woithe | 1 May 2012 02:18

Re: incompatible version of ffado error message

Hi Allan

On Mon, Apr 30, 2012 at 11:26:32PM +1000, Allan Klinbail wrote:
> As ffado doesn't seem to put out much by way of releases ...

We're hoping to rectify that soon, now that some of us actually have some
time again.

> ... many of the newer devices are only available by using the svn
> versions. (and some distros don't package them in stages). This could
> cause issues for many users that don't have the option of rolling back to
> the last stable release.
> 
> Is there some way of loosening this rule? 

The rule as it stands in the current git repo really needs to stand for
technical reasons.  However, it is now (as of a month or so ago) somewhat
more forgiving than it used to be.  From here on in, jackd should be much
more flexible as to which versions of libffado it is willing to work with,
which provides a cleaner avenue for future FFADO API updates.

Older versions of jackd are, however, still very picky about what libffado
version they are willing to tolerate.  Obviously we can't retrospectively
fix this so we've just got to accept it.  This is why current libffado
determines whether an old intolerant version of jackd is on the system and
adjusts itself so as to make that jackd version happy.  This, plus the more
flexible approach now taken by jackd, means that users *should* have the
option to upgrade either jackd, FFADO and still have a working system.

This is why I'm puzzled as to why your process broke things.  While the
(Continue reading)

Permalink | Reply | 0 comments |
headers
Stéphane Letz | 1 May 2012 08:38
Picon
Favicon

Re: Intermittent internal crash

> 
> [177/245] cprogram: build/example-clients/midi_latency_test.c.5.o -> 
> build/example-clients/jack_midi_latency_test                                
> /usr/bin/ld: example-clients/midi_latency_test.c.5.o: undefined reference to 
> symbol 'trunc <at>  <at> GLIBC_2.2.5'                                         
> /usr/bin/ld: note: 'trunc <at>  <at> GLIBC_2.2.5' is defined in DSO /usr/lib/gcc/x86_64-
> linux-gnu/4.6.1/../../../x86_64-linux-gnu/libm.so so try adding it to the 
> linker command line
> /usr/lib/gcc/x86_64-linux-gnu/4.6.1/../../../x86_64-linux-gnu/libm.so: could 
> not read symbols: Invalid operation
> collect2: ld returned 1 exit status
> Waf: Leaving directory `/home/me/Source/jack2-git/build'
> Build failed
> -> task in 'jack_midi_latency_test' failed (exit status 1):                                                                                     
>        {task 32119824: cprogram midi_latency_test.c.5.o -> 
> jack_midi_latency_test}                                                              
> ['/usr/bin/gcc', '-lm', '-lstdc++', 'example-clients/midi_latency_test.c.5.o', 
> '-o', '/home/me/Source/jack2-git/build/example-
> clients/jack_midi_latency_test', '-Wl,-Bstatic', '-Wl,-Bdynamic', '-Lcommon', 
> '-ljack', '-lpthread', '-lrt', '-ldl']   
> 

I was not aware of this one...

What is this undefined reference to sombol "'trunc <at>  <at> GLIBC_2.2.5' "  ?? Anybody knows?

Stéphane
Permalink | Reply | 2 comments |
headers
Stéphane Letz | 1 May 2012 08:45
Picon
Favicon

Re: Windows: Problem running Jack Server and Clients with DLLs


Le 30 avr. 2012 à 23:08, Sprague, Christopher M CIV NAVAIR, Code 4.6.2.3 a écrit :

> I Don't think what I am doing is an "In Server" client.

Your are actually creating 2 "in server" clients, since you're linking the code with libjackserver.dll
(and not libjack.dll). But this should not be a problem.

> 
> Attached is a test program where I just threw all the parts of the process into a console app.
> With this test program, the problem is still there.  
> 
> I create the server. Then I create a client and register its ports and process callback with the server. I
sleep for 5 seconds so you can see the process callback happening.
> 
> Then I try to create another client by another name for the purpose of making connections.  After I call
jack_client_open()...the problems arise  
> 
> Because my process callback is printing "." this is what I see:
> 
> .................................................JackWinSemaphore::TimedWait name =
jack_pipe.default_freewheel time_out
> JackFreewheelDriver::ProcessSync SuspendRefNum error
> JackAudioDriver::ProcessGraphSync: ProcessWriteSlaves error, engine may now behave abnormally!!
> 
> And that repeats indefinitely but since the callback isn't being called anymore, no more periods.
> 
> Also, if I create the server and make connections this way, but run my client as a separate process, things
work just fine.  
>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Stéphane Letz | 1 May 2012 09:17
Picon
Favicon

Re: Windows: Problem running Jack Server and Clients with DLLs


Le 1 mai 2012 à 08:45, Stéphane Letz a écrit :

> 
> Le 30 avr. 2012 à 23:08, Sprague, Christopher M CIV NAVAIR, Code 4.6.2.3 a écrit :
> 
>> I Don't think what I am doing is an "In Server" client.
> 
> Your are actually creating 2 "in server" clients, since you're linking the code with libjackserver.dll
(and not libjack.dll). But this should not be a problem.
> 
>> 
>> Attached is a test program where I just threw all the parts of the process into a console app.
>> With this test program, the problem is still there.  
>> 
>> I create the server. Then I create a client and register its ports and process callback with the server. I
sleep for 5 seconds so you can see the process callback happening.
>> 
>> Then I try to create another client by another name for the purpose of making connections.  After I call
jack_client_open()...the problems arise  
>> 
>> Because my process callback is printing "." this is what I see:
>> 
>> .................................................JackWinSemaphore::TimedWait name =
jack_pipe.default_freewheel time_out
>> JackFreewheelDriver::ProcessSync SuspendRefNum error
>> JackAudioDriver::ProcessGraphSync: ProcessWriteSlaves error, engine may now behave abnormally!!
>> 
>> And that repeats indefinitely but since the callback isn't being called anymore, no more periods.
>>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Pedro Alves | 1 May 2012 11:31
Picon

Re: Intermittent internal crash

On 05/01/2012 07:38 AM, Stéphane Letz wrote:

>> > [177/245] cprogram: build/example-clients/midi_latency_test.c.5.o -> 
>> > build/example-clients/jack_midi_latency_test                                
>> > /usr/bin/ld: example-clients/midi_latency_test.c.5.o: undefined reference to 
>> > symbol 'trunc <at>  <at> GLIBC_2.2.5'                                         
>> > /usr/bin/ld: note: 'trunc <at>  <at> GLIBC_2.2.5' is defined in DSO /usr/lib/gcc/x86_64-
>> > linux-gnu/4.6.1/../../../x86_64-linux-gnu/libm.so so try adding it to the 
>> > linker command line
>> > /usr/lib/gcc/x86_64-linux-gnu/4.6.1/../../../x86_64-linux-gnu/libm.so: could 
>> > not read symbols: Invalid operation
>> > collect2: ld returned 1 exit status
>> > Waf: Leaving directory `/home/me/Source/jack2-git/build'
>> > Build failed
>> > -> task in 'jack_midi_latency_test' failed (exit status 1):                                                                                     
>> >        {task 32119824: cprogram midi_latency_test.c.5.o -> 
>> > jack_midi_latency_test}                                                              
>> > ['/usr/bin/gcc', '-lm', '-lstdc++', 'example-clients/midi_latency_test.c.5.o', 
>> > '-o', '/home/me/Source/jack2-git/build/example-
>> > clients/jack_midi_latency_test', '-Wl,-Bstatic', '-Wl,-Bdynamic', '-Lcommon', 
>> > '-ljack', '-lpthread', '-lrt', '-ldl']   
>> > 
> 
> I was not aware of this one...
> 
> What is this undefined reference to sombol "'trunc <at>  <at> GLIBC_2.2.5' "  ?? Anybody knows?

Add or put "-lm" after the input object (.o).

https://fedoraproject.org/wiki/UnderstandingDSOLinkChange
(Continue reading)

Permalink | Reply | 1 comment |
headers
Allan Klinbail | 2 May 2012 00:29
Picon
Picon

Re: incompatible version of ffado error message

On Tue, 2012-05-01 at 09:38 +0930, Jonathan Woithe wrote:
> On Mon, Apr 30, 2012 at 03:35:54PM +0200, Adrian Knoth wrote:
> > On Mon, Apr 30, 2012 at 11:26:32PM +1000, Allan Klinbail wrote:
> > > I've been using jack with ffado as the driver for a few years now.
> > > Today, after upgrading ffado to the latest svn , (then tested working).
> > > I then upgraded to the latest jack svn version. Following this I started
> > > receiving the following incompatible error message. 
> > 
> > You were doing it in the wrong order.
> > 
> > FFADO detects the jackd version at compile time. If it's a new jackd
> > version supporting the new API, it switches to the new API.
> 
> Similarly, if there is no jackd installed at compile time ffado assumes that
> the jackd which will ultimately be available will support the new API.
> 
> So in Allan's case, he compiled a new FFADO against an old jack, which
> resulted in a FFADO which uses the old API.  The old jack was happy with
> this and everything worked.
> 

I tried this in a few different ways in the end .. Same result. 

> > You've just told FFADO to adjust itself to an old jackd version.
> > Simply compile FFADO again.
> 
> Yep, that should work.
> 
> However, from a development point of view I'm a little surprised that the
> latest jackd didn't simply accept FFADO as it was.  The relevant line in
(Continue reading)

Permalink | Reply | 4 comments |
headers
Allan Klinbail | 2 May 2012 00:32
Picon
Picon

Re: incompatible version of ffado error message

On Wed, 2012-05-02 at 08:29 +1000, Allan Klinbail wrote:
> On Tue, 2012-05-01 at 09:38 +0930, Jonathan Woithe wrote:
> > On Mon, Apr 30, 2012 at 03:35:54PM +0200, Adrian Knoth wrote:
> > > On Mon, Apr 30, 2012 at 11:26:32PM +1000, Allan Klinbail wrote:
> > > > I've been using jack with ffado as the driver for a few years now.
> > > > Today, after upgrading ffado to the latest svn , (then tested working).
> > > > I then upgraded to the latest jack svn version. Following this I started
> > > > receiving the following incompatible error message. 
> > > 
> > > You were doing it in the wrong order.
> > > 
> > > FFADO detects the jackd version at compile time. If it's a new jackd
> > > version supporting the new API, it switches to the new API.
> > 
> > Similarly, if there is no jackd installed at compile time ffado assumes that
> > the jackd which will ultimately be available will support the new API.
> > 
> > So in Allan's case, he compiled a new FFADO against an old jack, which
> > resulted in a FFADO which uses the old API.  The old jack was happy with
> > this and everything worked.
> > 
> 
> I tried this in a few different ways in the end .. Same result. 
> 
> 
> 
> > > You've just told FFADO to adjust itself to an old jackd version.
> > > Simply compile FFADO again.
> > 
> > Yep, that should work.
(Continue reading)

Permalink | Reply | 3 comments |
headers
Tim E. Real | 2 May 2012 02:54
Favicon

Re: Intermittent internal crash

On May 1, 2012 10:31:21 AM you wrote:
> On 05/01/2012 07:38 AM, Stéphane Letz wrote:
> >> > [177/245] cprogram: build/example-clients/midi_latency_test.c.5.o
> >> > ->
> >> > build/example-clients/jack_midi_latency_test
> >> > /usr/bin/ld: example-clients/midi_latency_test.c.5.o: undefined
> >> > reference to symbol 'trunc <at>  <at> GLIBC_2.2.5'
> >> > /usr/bin/ld: note: 'trunc <at>  <at> GLIBC_2.2.5' is defined in DSO
> >> > /usr/lib/gcc/x86_64-
> >> > linux-gnu/4.6.1/../../../x86_64-linux-gnu/libm.so so try adding
> >> > it to the linker command line
> >> > /usr/lib/gcc/x86_64-linux-gnu/4.6.1/../../../x86_64-linux-gnu/libm
> >> > .so: could not read symbols: Invalid operation
> >> > collect2: ld returned 1 exit status
> >> > Waf: Leaving directory `/home/me/Source/jack2-git/build'
> >> > Build failed
> >> > 
> >> > -> task in 'jack_midi_latency_test' failed (exit status 1):
> >> >        {task 32119824: cprogram midi_latency_test.c.5.o ->
> >> > 
> >> > jack_midi_latency_test}
> >> > ['/usr/bin/gcc', '-lm', '-lstdc++',
> >> > 'example-clients/midi_latency_test.c.5.o', '-o',
> >> > '/home/me/Source/jack2-git/build/example-
> >> > clients/jack_midi_latency_test', '-Wl,-Bstatic', '-Wl,-Bdynamic',
> >> > '-Lcommon', '-ljack', '-lpthread', '-lrt', '-ldl']
> > 
> > I was not aware of this one...
> > 
> > What is this undefined reference to sombol "'trunc <at>  <at> GLIBC_2.2.5' "  ??
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jonathan Woithe | 2 May 2012 04:51

Re: incompatible version of ffado error message

Hi Allan

On Wed, May 02, 2012 at 08:32:45AM +1000, Allan Klinbail wrote:
> > > Oh hang on: Allan, you said "the latest jack svn version".  Did you
> > > literally use jack's subversion repository?  That is no longer carrying the
> > > latest jackd source as far as I know: if you want the latest jackd you need
> > > to get it using git.  This is described at
> > > 
> > >   http://jackaudio.org/download
> > 
> > Okay, jackd was built from the "live" ebuild in the gentoo pro-audio
> > repository, I would have to look at the ebuild for that to determine if
> > it was taking the older svn version or the git version. 
> 
> and there lies the problem ..
> 
> DESCRIPTION="Jackdmp jack implemention for multi-processor machine"
> HOMEPAGE="http://www.grame.fr/~letz/jackdmp.html"
> 
> ESVN_REPO_URI="http://subversion.jackaudio.org/jack/jack2/trunk/jackmp"
> 
> LICENSE="GPL-2"
> SLOT="0"
> KEYWORDS=""
>
> it's using SVN..

It is indeed.  Using the above URL I just checked out the code tree that
this would result in and it definitely pre-dates the latest round of work on
the JACK firewire driver (which uses libffado, in case that wasn't obvious).
(Continue reading)

Permalink | Reply | 2 comments |

Gmane