Ticket #287 (closed enhancement: fixed)

Opened 10 years ago

Last modified 10 years ago

[Patch] Restart support for DICE based devices.

Reported by: adi Assigned to:
Priority: minor Milestone: FFADO 2.1
Component: devices/dice Version: FFADO SVN (trunk)
Keywords: Cc: nils
The device the bug applies to:



Here's my reworked patch that supports restarting jackd on DICE devices without powercycling the device (or doing a bus reset).

If you want to try it, killall -9 jackd your running jackd and then try to start jackd again.

JFTR, here are some notes I posted to the devel-ML along with the first patch, so you have a documented rationale. I'm not sure about re-allocating the ISO channels in question with the IRM. It works without, and a quick test revealed that get1394Service().allocateFixedIsoChannelGeneric() returns -1 anyway, so this probably means the ISO channel is still registered. Hence, I've commented out the corresponding block. It can probably be stripped once we know that we don't want it.



I was tired of powercycling my DICE device each time it crashed. I noticed that FFADO is complaining about ISO channel registers not being clean (0xFFFFFFFFUL), because they actually contained a sane value. ;) Same holds true for the device owner register, FFADO expects the device to be unoccupied, but that's a little bit too strict, because there's another "good" case: if the current owner is us, because we were running before and just crashed on the software side. No need to abort everything in this case. Last but not least: GLOBAL_ENABLE usually is true when jackd has crashed. In this state, we cannot (or at least the current code says so) switch sample rates and the lot. Consequently, I set GLOBAL_ENABLE to false when restarting the device to re-enable all those functions.


dice-restart.patch (3.8 kB) - added by adi on 06/18/10 02:18:49.

Change History

06/18/10 02:18:49 changed by adi

  • attachment dice-restart.patch added.

06/26/10 03:14:37 changed by ppalmers

The reason for this check is that a non 0xFFFFFFFF value in this register might indicate that another host on the bus is controlling the device.

06/26/10 03:51:32 changed by adi

Yeah, sure, but if the register already contains the value for "us", then we're save to go on. At least that's how I understand it.

06/26/10 03:57:47 changed by adi

Oh, I was referring to the owner register, you probably to the ISO channel register. Since owner check comes first, the value of the ISO channel registers is still our responsibility, IOW, no other host should ever care. Given that we reuse the existing values, even running streams (to snooping hosts) won't be affected.

07/21/10 10:12:39 changed by adi

  • summary changed from Restart support for DICE based devices. to [Patch] Restart support for DICE based devices..

07/31/10 11:26:53 changed by nils

  • cc set to nils.

I've tried adi's patch here and it seems to do what's intended (current git/SVN: libraw1394, ffado, jack2; Fedora packaged kernels and 2.6.35.rc6.git1, Focusrite Saffire Pro 40).

09/16/10 13:15:55 changed by arnonym

  • status changed from new to closed.
  • resolution set to fixed.
  • milestone set to FFADO 2.1.

committed in r1900