[alsa-devel] ALSA firewire kernel branch: snd_dice enhancements

[Clemens Ladisch]

Rolf Anderegg wrote:
> On 02.11.2011, at 21:19, Clemens Ladisch <clemens at ladisch.de> wrote:
>> On the DICE, the playback and capture streams must use a common rate, so
>> I thought I'd avoid handling this in the driver and just use whatever
>> was configured.
> 
> Isn't common rate for playback & capture stream often required?

Yes (but not on consumer chips, where it's normal to have independent
clocks for all I/Os).

> This could be guaranteed by adapting the pcm rate constraints when
> acquiring one or the other stream.

Yes, and many ALSA drivers already do this.  I just wanted to be lazy
and put the sample rate selection into a control panel, where other
similar settings already have to be handled.

Putting rate and clock selection in the driver also has the benefit of
making it mostly usable even without a control panel.

>> The timing of the stream from the computer to the DICE is synthesized
>> according to the rules in the AMDTP spec (I hope); this was originally
>> written for devices based on the OXFW970 chip.  (It's synchronized to
>> the FireWire bus clock.)

This parenthesis is very misleading; what I should have said is that the
driver computes the SYT timestamps so that the stream's sample clock is
effectively synchronized to the bus clock.  These OXFW970-based devices
are playback-only and work the same as DICEs with AVS-SYT clock source,
i.e., they should also be able to be synchronized to any other device.

>> ARX1 appears to work fine with my DesktopKonnekt6, but I've never looked
>> at the error counters.
> 
> Right, hmm, having scanned the AMDTP (IEC 61883-6) in detail raises some
> confusion now. Up till now I was under the impression that using AVS-SYT
> as DICE's clock source is only an option to sync firewire bus slave
> devices to a clock master device on the same bus.

And this clock master could be either another device that generates SYT
timestamps based on its own internal clock, or a computer that just
computes the SYTs.  (AFAICT the Windows/OSX DICE drivers don't implement
the second case.  An 'invented' clock isn't useful except for the
playback-only devices mentioned above where there just isn't any other
clock.)


Regards,
Clemens