Re: [LAU] Focusrite Saffire Pro 40 - reliable?

From: Ben Bell <bjb-linux-audio-user@email-addr-hidden>
Date: Sun Mar 29 2015 - 20:27:47 EEST

Hi Len,

>> Various things like stopping jack also cause a whole bunch of processes just
>> to lock up and I have to go around manually killing manually killing
>> ffado-dbus-server, ffado-mixer, jackd and qjackctl.
> My first thought is: why would you stop jack? I know here, it starts
> on session login and only stops at logout (which around here means

Actually that's a fair point. I wouldn't normally be restarting jack much
and am doing it now mainly because I'm tweaking things to see if it has any
effect on the performance and problems. So, clocking, sample rate, periods
etc. In a real studio context it would of course just stay running most of
the time.

> starts at boot and stop at shutdown) Are you using jackd or
> jackdbus? If you are using jackdbus, you may wish to try chmod -x
Actually I just did the opposite and disabled jackdbus, because jackd I
understand (I think ;).

> Anyway, if you are using qjackctl to turn jack off and on then I
> would suggest using it's run script on start/stop to shut these
Yes, I've done that though it took a while to figure out which order
to kill things in to stop qjackctl hanging.

>> If I switch the Focusrite off then, again, I have clean up work to do before
>> things are usable again.
> I am sure if you powered the d1010 down while the system was running
> you would have similar problems or worse. Don't do that. I think if
Again, that's a fair point and it's partly only because of the problems
I'm having that I find myself doing it. With the Delta 1010 the external
rack boxes could be powered down but of course the cards stayed powered.

I do still think that it ought to be possible to power the Focusrite down
and get an error and a jack shutdown rather than hanging, but if not I'll
just write something that watches kern.log or /dev/fw1 and shoots jackd
in the head if it goes away (and perhaps restarts it when it appears).

On the click side of things, I've found a firewire debug setting and turned
it up and can now see that the clicks correspond perfectly to kernel
messages like this:
Mar 29 18:25:30 rowlf kernel: [2273903.389362] firewire_ohci: AR spd 2 tl 35, ffc0 -> ffc1, ack_pending , QW req, ffffe0000000 = 00000040
Mar 29 18:25:30 rowlf kernel: [2273903.389450] firewire_ohci: AT spd 2 tl 35, ffc1 -> ffc0, ack_complete, W resp
Mar 29 18:25:30 rowlf kernel: [2273903.589363] firewire_ohci: AR spd 2 tl 36, ffc0 -> ffc1, ack_pending , QW req, ffffe0000000 = 00000040
Mar 29 18:25:30 rowlf kernel: [2273903.589451] firewire_ohci: AT spd 2 tl 36, ffc1 -> ffc0, ack_complete, W resp

Of course, it still doesn't really tell me whether it's an unexpected driver
issue or just how the code responds to a hardware glitch, but I'll talk to the
ffado developers and see what it might indicate.

Thanks for the response,

bjb

_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-user
Received on Mon Mar 30 00:15:01 2015

This archive was generated by hypermail 2.1.8 : Mon Mar 30 2015 - 00:15:01 EEST