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

[Rolf Anderegg]

On 02.11.2011, at 21:19, Clemens Ladisch <clemens at ladisch.de> wrote:

>> 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.
>
> 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? This 
could be guaranteed by adapting the pcm rate constraints when acquiring 
one or the other stream.

> Do you have a requirement that the sample rate must be selected
> automatically, instead of being configured with a control panel or with
> a CLI tool like amixer?

Yes, this is quite crucial as we are attempting a playback system 
without any local GUI/control panel/CLI interaction, using jackd as 
audio backend I/O plugin. E.g. starting jackd with

jackd -d alsa -d hw1:0 -r <rate>

should incorporate switching the samplerate automatically, as this is 
done with most alsa devices.
Given that the ALSA driver API provides for such functionality 
(snd_xxx_hw_params & snd_xxx_prepare) I thought that such an objective 
was self-evident. I could think of several other usecases where this 
would be desired/required. Why _shouldn't_ the application which 
acquires the DICE device at least be able to dictate the initial 
samplerate and/or syncsource? What do you (and others) think? Any way we 
can reach a mutual consent on this?

>> 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?).
>
> This branch will land in the kernel when it's reasonably complete.

> The plan is for this kernel driver to replace FFADO's streaming
> component.

If this is the case it would appear that automatical samplerate 
switching, as is provided by FFADO, is a crucial requirement that should 
also be transferred to this new kernel driver.

>> 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?
>
> Not by anyone who understands the FFADO internals and has the time.

Ok, I'll have a look at it.

>> 2.) support DICE capture streams
>
> I'm working on this right now (modulo the amount of time available).

Excellent, we're happy to serve as guinea pigs, whenever you're ready ;-)

>> 3.) DICE clock source (CLOCK_SOURCE_*) selectable via ALSA driver API; how could
>> this be done?
>
> If not done by a control panel, this could be done with a mixer control.
> This is not yet implemented because any clock source except ARX*
> requires synchronization from the capture stream.
>
>> 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.
>
> 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.)  It's possible that DICE devices want to use
> a different value for the transfer delay or some other timing parameter;
> a stream whose timing is derived from another DICE's capture stream
> would have whatever timing is required.
>
> 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. After all, the 
DesktopKonnekt6 manual mentions that in standalone setup INTERNAL 
syncsource is selected per default and can not be altered.

Citing from DICE's users guide (chapter 6: AVS (Audio Video System)):
"[...] All nodes on a 1394 network must be synchronized to one clock 
called the cycle timer, which is determined by the master node on the 
network. One cycle of the master nodes‘ cycle timer defines a 1394 
cycle. At the beginning of each 1394 cycle the master node transmits a 
clock sync signal that allows all nodes on the 1394 network to be 
synchronized to the cycle timer. This maintains synchronicity among all 
the 1394 nodes. Each 1394 node receives the clock sync signal and uses 
it to update or correct its local timer. However, this clock correction 
can cause the local timer to jump forward or backward as it is updated 
by the clock sync signal, which can reduce the performance of the system.
The format of a quadlet of audio data passing through the AVS is 
configurable. The AVS can be configured to be transparent for 32-bit 
audio data. In this case the data will not be touched as it passes 
through the AVS. The AVS can also be configured to support the 
IEC61883-6 (AM824) steaming model. This allows the AVS to either source 
AM824 labels from another location, or build its own AM824 labels for 
the 24-bit data. The AVS can take the various label fields (block sync, 
user bits, channel status bits, etc) that make up each AM824 label, from 
different sources, and then pack them together into an AM824 label. [...]"

Still confused... any enlightenment or recommendation, perhaps from 
TCAT, on this?

Regards,
Rolf