ALSA firewire kernel branch: snd_dice enhancements

ALSA firewire kernel branch: snd_dice enhancements

[Rolf Anderegg]

[-- Attachment #1: Type: text/plain, Size: 2405 bytes --]


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-kernel-streaming)
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=f29bf150b7ba0624142496c84bb48ddba561c0e2).
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.

[-- Attachment #2: weiss_dice.patch --]
[-- Type: text/plain, Size: 9988 bytes --]

diff --git a/sound/firewire/dice-interface.h b/sound/firewire/dice-interface.h
index af916b9..d1e5086 100644
--- a/sound/firewire/dice-interface.h
+++ b/sound/firewire/dice-interface.h
@@ -94,12 +94,13 @@
 #define  CLOCK_SOURCE_AES4		0x00000003
 #define  CLOCK_SOURCE_AES_ANY		0x00000004
 #define  CLOCK_SOURCE_ADAT		0x00000005
-#define  CLOCK_SOURCE_TDIF		0x00000006
+#define  CLOCK_SOURCE_TDIF		0x00000006	//only on DICE II
+#define  CLOCK_SOURCE_ADATAUX		0x00000006	//only on DICE JR/Mini
 #define  CLOCK_SOURCE_WC		0x00000007
 #define  CLOCK_SOURCE_ARX1		0x00000008
 #define  CLOCK_SOURCE_ARX2		0x00000009
-#define  CLOCK_SOURCE_ARX3		0x0000000a
-#define  CLOCK_SOURCE_ARX4		0x0000000b
+#define  CLOCK_SOURCE_ARX3		0x0000000a	//only on DICE II
+#define  CLOCK_SOURCE_ARX4		0x0000000b	//only on DICE II
 #define  CLOCK_SOURCE_INTERNAL		0x0000000c
 #define  CLOCK_RATE_MASK		0x0000ff00
 #define  CLOCK_RATE_32000		0x00000000
@@ -198,12 +199,13 @@
 #define  CLOCK_CAP_SOURCE_AES4		0x00080000
 #define  CLOCK_CAP_SOURCE_AES_ANY	0x00100000
 #define  CLOCK_CAP_SOURCE_ADAT		0x00200000
-#define  CLOCK_CAP_SOURCE_TDIF		0x00400000
+#define  CLOCK_CAP_SOURCE_TDIF		0x00400000	//only on DICE II
+#define  CLOCK_CAP_SOURCE_ADATAUX	0x00400000	//only on DICE JR/Mini
 #define  CLOCK_CAP_SOURCE_WC		0x00800000
 #define  CLOCK_CAP_SOURCE_ARX1		0x01000000
 #define  CLOCK_CAP_SOURCE_ARX2		0x02000000
-#define  CLOCK_CAP_SOURCE_ARX3		0x04000000
-#define  CLOCK_CAP_SOURCE_ARX4		0x08000000
+#define  CLOCK_CAP_SOURCE_ARX3		0x04000000	//only on DICE II
+#define  CLOCK_CAP_SOURCE_ARX4		0x08000000	//only on DICE II
 #define  CLOCK_CAP_SOURCE_INTERNAL	0x10000000
 
 /*
diff --git a/sound/firewire/dice.c b/sound/firewire/dice.c
index 7a37587..0c7b17b 100644
--- a/sound/firewire/dice.c
+++ b/sound/firewire/dice.c
@@ -35,6 +35,7 @@ struct dice {
 	spinlock_t lock;
 	struct mutex mutex;
 	unsigned int global_offset;
+	unsigned int tx_offset;
 	unsigned int rx_offset;
 	struct fw_address_handler notification_handler;
 	int owner_generation;
@@ -107,6 +108,11 @@ static inline u64 global_address(struct dice *dice, unsigned int offset)
 	return DICE_PRIVATE_SPACE + dice->global_offset + offset;
 }
 
+static inline u64 tx_address(struct dice *dice, unsigned int offset)
+{
+	return DICE_PRIVATE_SPACE + dice->tx_offset + offset;
+}
+
 // TODO: rx index
 static inline u64 rx_address(struct dice *dice, unsigned int offset)
 {
@@ -277,9 +283,35 @@ static void dice_notification(struct fw_card *card, struct fw_request *request,
 	dice->notification_bits |= be32_to_cpup(data);
 	spin_unlock_irqrestore(&dice->lock, flags);
 	fw_send_response(card, request, RCODE_COMPLETE);
+	//snd_printk(KERN_INFO "dice_notification: bits: %#x\n", dice->notification_bits);
 	wake_up(&dice->hwdep_wait);
 }
 
+static unsigned int dice_caps_to_rate_constraints(__be32 const* const caps)
+{
+	unsigned int i;
+	unsigned int rate_constraints = 0;
+	for (i=CLOCK_CAP_RATE_32000; i<=CLOCK_CAP_RATE_192000; i<<=1) {
+		switch(i & be32_to_cpu(*caps)) {
+		case CLOCK_CAP_RATE_32000:
+			rate_constraints|=SNDRV_PCM_RATE_32000; break;
+		case CLOCK_CAP_RATE_44100:
+			rate_constraints|=SNDRV_PCM_RATE_44100; break;
+		case CLOCK_CAP_RATE_48000:
+			rate_constraints|=SNDRV_PCM_RATE_48000; break;
+		case CLOCK_CAP_RATE_88200:
+			rate_constraints|=SNDRV_PCM_RATE_88200; break;
+		case CLOCK_CAP_RATE_96000:
+			rate_constraints|=SNDRV_PCM_RATE_96000; break;
+		case CLOCK_CAP_RATE_176400:
+			rate_constraints|=SNDRV_PCM_RATE_176400; break;
+		case CLOCK_CAP_RATE_192000:
+			rate_constraints|=SNDRV_PCM_RATE_192000; break;
+		}
+	}
+	return rate_constraints;
+}
+
 static int dice_open(struct snd_pcm_substream *substream)
 {
 	static const struct snd_pcm_hardware hardware = {
@@ -298,7 +330,9 @@ static int dice_open(struct snd_pcm_substream *substream)
 	struct dice *dice = substream->private_data;
 	struct snd_pcm_runtime *runtime = substream->runtime;
 	__be32 clock_sel, data[2];
+	__be32 clock_caps;
 	unsigned int rate_index, number_audio, number_midi;
+	unsigned int rate_constraints;
 	int err;
 
 	err = dice_try_lock(dice);
@@ -306,6 +340,13 @@ static int dice_open(struct snd_pcm_substream *substream)
 		goto error;
 
 	err = snd_fw_transaction(dice->unit, TCODE_READ_QUADLET_REQUEST,
+					 global_address(dice, GLOBAL_CLOCK_CAPABILITIES),
+					 &clock_caps, 4, 0);
+	if (err < 0)
+		goto err_lock;
+	rate_constraints = dice_caps_to_rate_constraints(&clock_caps);
+
+	err = snd_fw_transaction(dice->unit, TCODE_READ_QUADLET_REQUEST,
 				 global_address(dice, GLOBAL_CLOCK_SELECT),
 				 &clock_sel, 4, 0);
 	if (err < 0)
@@ -327,25 +368,14 @@ static int dice_open(struct snd_pcm_substream *substream)
 
 	runtime->hw = hardware;
 
-	runtime->hw.rates = snd_pcm_rate_to_rate_bit(dice_rates[rate_index]);
+	runtime->hw.rates = rate_constraints;
 	snd_pcm_limit_hw_rates(runtime);
 
 	runtime->hw.channels_min = number_audio;
 	runtime->hw.channels_max = number_audio;
 
-	amdtp_out_stream_set_parameters(&dice->stream, dice_rates[rate_index],
-					number_audio, number_midi);
-
-	err = snd_pcm_hw_constraint_step(runtime, 0,
-					 SNDRV_PCM_HW_PARAM_PERIOD_SIZE,
-					 amdtp_syt_intervals[rate_index]);
-	if (err < 0)
-		goto err_lock;
-	err = snd_pcm_hw_constraint_step(runtime, 0,
-					 SNDRV_PCM_HW_PARAM_BUFFER_SIZE,
-					 amdtp_syt_intervals[rate_index]);
-	if (err < 0)
-		goto err_lock;
+	/*snd_printk(KERN_INFO "dice_open: clk_caps: %#x -> rate constraints: %#x\n",
+					be32_to_cpu(clock_caps),rate_constraints);*/
 
 	err = snd_pcm_hw_constraint_minmax(runtime,
 					   SNDRV_PCM_HW_PARAM_PERIOD_TIME,
@@ -365,6 +395,94 @@ error:
 	return err;
 }
 
+static int dice_set_rate(struct snd_pcm_substream *substream,
+		struct snd_pcm_hw_params *hw_params, unsigned int clk_src)
+{
+	struct dice *dice = substream->private_data;
+	struct snd_pcm_runtime *runtime = substream->runtime;
+	__be32 clock_sel, data[2];
+	int err;
+	unsigned int rate_index;
+	unsigned int number_audio = params_channels(hw_params);
+	unsigned int number_midi;
+
+	for (rate_index = 0; rate_index < ARRAY_SIZE(dice_rates); rate_index++)
+		if (params_rate(hw_params) == dice_rates[rate_index])
+			break;
+	if (rate_index >= ARRAY_SIZE(dice_rates)) {
+		err = -ENXIO;
+		goto error;
+	}
+
+	err = snd_fw_transaction(dice->unit, TCODE_READ_BLOCK_REQUEST,
+					 rx_address(dice, RX_NUMBER_AUDIO),
+					 data, 2 * 4, 0);
+	if (err < 0)
+		goto error;
+	number_midi = be32_to_cpu(data[1]);
+
+	/*snd_printk(KERN_INFO "dice_set_rate: rate: %i Hz (idx: %i), source: %#x, "\
+			"channels: %i, midi ports: %i\n",
+			params_rate(hw_params),rate_index,clk_src,
+			number_audio,number_midi);*/
+
+	// set rate (DICE clock select & AMDTP & PCM):
+	clock_sel = cpu_to_be32((rate_index << CLOCK_RATE_SHIFT) | clk_src);
+	err = snd_fw_transaction(dice->unit, TCODE_WRITE_QUADLET_REQUEST,
+				 global_address(dice, GLOBAL_CLOCK_SELECT),
+				 &clock_sel, 4, 0);
+
+	// TODO: wait for NOTIFY_CLOCK_ACCEPTED
+#	if 0
+	while(1) {
+		if (hwdep_rd_cnt-- <= 0) {
+			snd_printk(KERN_INFO "dice_set_rate: error: too many hwdep reads.\n");
+			break;
+		}
+		if (dice_hwdep_read(dice->hwdep, (char*)&fw_event, sizeof(fw_event), NULL) <= 0)
+			continue;
+		switch(fw_event.common.type) {
+		case SNDRV_FIREWIRE_EVENT_DICE_NOTIFICATION:
+			snd_printk(KERN_INFO "dice_set_rate: DICE notif event (%i): %#x\n",
+					fw_event.dice_notification.type,fw_event.dice_notification.notification);
+			break;
+		case SNDRV_FIREWIRE_EVENT_LOCK_STATUS:
+			snd_printk(KERN_INFO "dice_set_rate: lock status event (%i): %#x\n",
+					fw_event.lock_status.type,fw_event.lock_status.status);
+			break;
+		default:
+			snd_printk(KERN_INFO "dice_set_rate: unknown event (%i)\n",
+					fw_event.common.type);
+			break;
+		}
+		if (fw_event.common.type == SNDRV_FIREWIRE_EVENT_DICE_NOTIFICATION &&
+			(fw_event.dice_notification.notification & NOTIFY_CLOCK_ACCEPTED))
+			break;
+	}
+#	else
+	msleep(500);
+#	endif
+
+	amdtp_out_stream_set_parameters(&dice->stream, dice_rates[rate_index],
+						number_audio, number_midi);
+
+	err = snd_pcm_hw_constraint_step(runtime, 0,
+					 SNDRV_PCM_HW_PARAM_PERIOD_SIZE,
+					 amdtp_syt_intervals[rate_index]);
+	if (err < 0)
+		goto error;
+	err = snd_pcm_hw_constraint_step(runtime, 0,
+					 SNDRV_PCM_HW_PARAM_BUFFER_SIZE,
+					 amdtp_syt_intervals[rate_index]);
+	if (err < 0)
+		goto error;
+
+	return 0;
+
+error:
+	return err;
+}
+
 static int dice_close(struct snd_pcm_substream *substream)
 {
 	struct dice *dice = substream->private_data;
@@ -466,11 +584,17 @@ static int dice_hw_params(struct snd_pcm_substream *substream,
 	dice_stream_stop(dice);
 	mutex_unlock(&dice->mutex);
 
+	/*snd_printk(KERN_INFO "dice_hw_params: dice stream rate idx: %i, hw_params rate: %i, channels: %i\n",
+			dice->stream.sfc,params_rate(hw_params), params_channels(hw_params));*/
 	err = snd_pcm_lib_alloc_vmalloc_buffer(substream,
 					       params_buffer_bytes(hw_params));
 	if (err < 0)
 		goto error;
 
+	err = dice_set_rate(substream, hw_params, CLOCK_SOURCE_INTERNAL);
+	if (err < 0)
+		return err;
+
 	amdtp_out_stream_set_pcm_format(&dice->stream,
 					params_format(hw_params));
 
@@ -845,6 +969,7 @@ static int __devinit dice_init_offsets(struct dice *dice)
 		return err;
 
 	dice->global_offset = be32_to_cpu(pointers[0]) * 4;
+	dice->tx_offset = be32_to_cpu(pointers[2]) * 4;
 	dice->rx_offset = be32_to_cpu(pointers[4]) * 4;
 
 	return 0;
@@ -947,12 +1072,13 @@ static int __devinit dice_probe(struct device *unit_dev)
 	if (err < 0)
 		goto error;
 	clock_sel &= cpu_to_be32(~CLOCK_SOURCE_MASK);
-	clock_sel |= cpu_to_be32(CLOCK_SOURCE_ARX1);
+	clock_sel |= cpu_to_be32(CLOCK_SOURCE_INTERNAL);
 	err = snd_fw_transaction(unit, TCODE_WRITE_QUADLET_REQUEST,
 				 global_address(dice, GLOBAL_CLOCK_SELECT),
 				 &clock_sel, 4, 0);
 	if (err < 0)
 		goto error;
+	//snd_printk(KERN_INFO "dice_probe: curr. clock_sel: %#x\n",be32_to_cpu(clock_sel));
 
 	err = dice_create_pcm(dice);
 	if (err < 0)

[-- Attachment #3: Type: text/plain, Size: 0 bytes --]

Re: ALSA firewire kernel branch: snd_dice enhancements

[Clemens Ladisch]

Rolf Anderegg wrote:
> I recently stumbled upon your alsa-kernel branch (firewire-kernel-streaming:
> http://git.alsa-project.org/?p=alsa-kprivate.git;a=shortlog;h=firewire-kernel-streaming)
> 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.

This driver is intended to be used with some kind of control panel that
handles device configuration.  As long as such a tool does not exist,
one has to manage with this:
http://www.alsa-project.org/~clemens/not-the-dice-control-panel.c

> 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.

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?

> 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.

> 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,

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

> 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.

> 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)?

The hwdep thing is intended for userspace; I'd add something like
a struct completion to be triggered from dice_notification().

> 2.) support DICE capture streams

I'm working on this right now (modulo the amount of time available).

> 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.


Regards,
Clemens

Re: ALSA firewire kernel branch: snd_dice enhancements

[Rolf Anderegg]

On 02.11.2011, at 21:19, Clemens Ladisch <clemens@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
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: ALSA firewire kernel branch: snd_dice enhancements

[Clemens Ladisch]

Rolf Anderegg wrote:
> On 02.11.2011, at 21:19, Clemens Ladisch <clemens@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