Re: [FFADO-devel] [MOTU] some port related problems

[François E. <fra...@pa...>]

Hi Jonathan,

> > More specifically, the bug appears with Jack r3100, the Pieter's fix for
> the
> > RT issue with recent ffado for some people and commented as "clean up
> the
> > firewire backend".
> > The main change seems to be that jack_port_connected replaced a test on
> the
> > existence of the port buffer.
> > So we are still on the same topic.
> >
> > So, to clarify:
> > Latest Jack (svn3100 at last) works with FFADO pre svn1449.
> > Latest FFADO (svn1485) works with Jack pre svn3100.
> > But FFADO svn1449 doesn't works with Jack svn3100.
> 
> Right, so at this stage it appears that we're dealing with side effects
> of a recent change to Jack in the lower level ffado layer.  That helps.
> However, I won't have a chance to look at this until tomorrow night now.
> 
> In the meantime Pieter may have some thoughts as to why the changes in
> ffado-svn1449 causes issues with jack-svn3100.

It could be something not properly set in the MOTU port structure that FFADO
svn1449 could have made Jack aware of, and Jack svn3100 could have used it. 
The fact Jack svn3100 works with FFADO pre svn1449 could be caused by a
working generic value passed by FFADO to Jack, or by another way to
calculate it.
Just an idea...

> 
> > Jack2 doesn't work with FFADO pre svn1449.
> 
> I can't comment on jack2 - I don't know the state of that with respect to
> ffado.
> 
> > If I revert svn1449's mods:
> > svn -r1485 up
> > svn -r1448:1449 diff > Pieter_port_fix.patch
> > patch -R -p0 < Pieter_port_fix.patch
> >
> > It works well with both latest svn Jack1 and latest svn Jack2.
> 
> Right.  I still can't work out why the MOTU driver is so dramatically
> affected by the r1449 change.  Essentially the old behaviour had ports
> being
> disabled when enable() was called, and vice versa - and yet things worked.
> With the disable()/enable() methods fixed, MOTU breaks but nothing else
> does.  That is extremely curious.
> 


Regards,
Francois