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@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/listinfo/linux-audio-user
