Hi Clemens, hi Stefan,
I recently stumbled upon your alsa-kernel branch (firewire-kernel-streaming: http://git.alsa-project.org/?p=alsa-kprivate.git;a=shortlog;h=firewire-kerne...) and have finally found the time to play around with it. First of all I was impressed to see that it easily worked in conjunction with our DICE-based devices, even in high samplerate mode (>96kHz), provided that the clockselection of the DICE had been done beforehand via TCAT's drivers. To get samplerate switching working via ALSA's driver API I have made a few changes, especially within the dice_hw_params callback method. Plus, I enhanced the rate constraints for the pcm settings. You can find these changes in the attached patch (applicable to http://git.alsa-project.org/?p=alsa-kprivate.git;a=commit;h=f29bf150b7ba0624...). I hope that some of these enhancements will make it to your alsa-kernel branch, if not even to the 3.x kernel tree (is this being considered for the near future?).
I am happy to say that this solution will fit our needs for the time being, while we still have not given up on FFADO as a longterm alternative, provided it is stable at all rates. I noticed that amdtp_out_stream offers support for "dualwire" streaming at high rates, which is applied for dice's stream. Has this already been considered in FFADO? I wasn't able to pinpoint the appropriate entities within the FFADO sources yet.
In order for snd_dice to make it upstream for generic DICE support there appear to remain a few minor issues:
1.) wait for NOTIFY_CLOCK_ACCEPTED notification bit after writing GLOBAL_CLOCK_SELECT within dice_hw_params. For the time being I introduced a "childish" msleep(500) in order for DICE to potentially switch its ratemode before starting the stream. I didn't quite figure out how to wait/poll for a particular notification. Do you have a hint how this would be done (using hwdep)? 2.) support DICE capture streams 3.) DICE clock source (CLOCK_SOURCE_*) selectable via ALSA driver API; how could this be done? I have changed the default clock source to INTERNAL, since I was experiencing "slips" with ARX1; as far as I know ARX1/2 is reasonably applicable only if there is another clock sync master on the Firewire bus.
Thanks again for this cool branch and let us know whether we can be of further assistance.
Cheers,
Rolf Anderegg, Weiss Engineering Ltd.