[alsa-devel] [PATCH 05/39] firewire-lib: Add support for AMDTP in-stream and PCM capture

[Takashi Sakamoto]

Clemens,

> In practice, this error means that a packet was dropped.  I guess this
> doesn't actually happen too often, but eventually, we should handle
> this either by inserting some samples or by stopping the stream.

I'm working for this and I realize Fireworks has some quirks.

(I guess that I had experienced this last year then remove codes to 
check it and forget it now...)

Well, in IEC 61883-1, the value of dbc field corresponds to the first 
data block in a packet. And the value of dbc in a first packet is zero. 
So it also means count of transmitted data blocks (described in IEC 
61883-6).

But for Fireworks, the value of dbc field corresponds to the end data 
block in a packet. See two samples below.

BeBoB - M-Audio Firewire Solo:
34 02040010 900234B2
02 02040018 9002FFFF
34 02040018 900248B2
34 02040020 900260B2
34 02040028 900274B2
02 02040030 9002FFFF
34 02040030 900288B2
34 02040038 9002A0B2
34 02040040 9002B4B2
02 02040048 9002FFFF
34 02040048 9002C8B2
34 02040050 9002E0B2
34 02040058 9002F4B2
02 02040060 9002FFFF
34 02040060 900208B2

Fireworks - AudioFire4(firmware 5.21):
Payload CIP0 CIP1
3A 00070028 9001C704
02 00070028 90FFFFFF
3A 00070030 9001E06E
3A 00070038 9001F5D8
3A 00070040 90010B42
02 00070040 90FFFFFF
3A 00070048 900124AC
3A 00070050 90013A16
02 00070050 90FFFFFF
3A 00070058 90015380
3A 00070060 900168EA
02 00070060 90FFFFFF
3A 00070068 90018254

Let us focus on the value of dbc in empty packet. In BeBoB, the value of 
dbc in packets following to empty packet is the same as the value in the 
empty packet. In Fireworks, the value of dbc in packets following to 
empty packet is not the same as the value in the empty packet, however 
the value of dbc in packets followed by empty packet is the same as the 
value in the empty packet. This means dbc corresponds to the end of data 
block in current packet. I can see this quirk on 
AudioFire4/AudioFirePre8 with firmware version 4.8-5.8, so I guess all 
of Fireworks have this quirk. (quirk 1)

Additionally, firmware version 5.5 seems to have a quirk to report fix 
value (0x08) for dbc interval in all sampling rates. I confirm this on 
AudioFire4 and AudioFirePre8, so I guess all of Fireworks with firmware 
version 5.5 have this quirk. (quirk 2)

Furthermore, Firmware named 'AudioFire9' seems to have a quirk to report 
fix value (0x11) for dbs in all sampling rates instead of actual value. 
I confirm this on AudioFirePre8 with firmware version 4.8-5.8. 
AudioFire8 (since July 2009) uses the same firmware so I guess this 
model has also this quirk. (quirk 3)

And as I mentioned before, BeBoB has a quirk not to increment dbc in 
initial state of transmitting. (quirk 4)

If firewire-lib has codes for these quirks, it can check dbc continuity.
So I'll to add some flags for these issue into 'struct amdtp_stream', like:
struct amdtp_stream {
...
	bool tx_dbc_is_end_event;	// for quirk 1
	unsigned int tx_dbc_interval;	// for quirk 2
	bool tx_dbs_is_wrong;		// for quirk 3
	bool skip_initial_tx_packets;	// for quirk 4
...
};

But 'struct amdtp_stream' has 'flag' member. Should I use this member 
instead of adding new members?


Regards

Takashi Sakamoto
o-takashi at sakamocchi.jp