I do not recall seeing a reply on list regarding this. On Tue, December 27, 2016 6:07 pm, Peter P. wrote: Fernando at CCRMA reported a similar problem on the jackdev list, I think mentioning a similar problem even when changing sample rates. My guess is that the device has a PLL with a long time constant for locking the sampling clock, such that when you send a request for a particular sample rate the device takes many seconds to report that the requested sample rate is achieved and the device is ready to use. The solutions I can think of for a device with such behavior is to make sure the device is running at the desired sample rate before starting jackd (e.g. using an ALSA utility to setup the device first, playing something through alsaplay, etc.), just accept that you have to start jackd twice, or modify the source for jackd to wait longer or have a retry loop when a device does not report quick success for setting the ALSA parameters. -- Chris Caudle