User:Takaswie

From AlsaProject
Revision as of 03:18, 21 February 2014 by Takaswie (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Simple memo about driver for Firewire devices

1.Status of this document

My memo for developing.

2.Basic Specifications 

- 'IEEE1394' defines 'Phy layer', 'Link layer', 'Transaction layer' and 'Serial Bus Management'.
- 'IEEE1212' defines 'Control ans Status Registers (CSR)', 'Configuration ROM' and 'Transaction set'.
- 'OHCI1394' defined the design of IEEE1394 host controller and its register.
- 'IEC 61883-1' defines 'Common Isochronous Packet (CIP)', 'Isochronous data flow management', 'Connection Management Procedure (CMP)', 'Function Control Protocol (FCP)'.
- 'IEC 61883-6' defines the way to packetize 'Common Isochronous Packet' for 'Audio and Music'. This is so-called 'AMDTP'.
- 'MMA/AMEI RP-027' is a recommendation for 'MIDI conformant data' channel of 'AMDTP'.
- '1394TA' is an associates of industory.
- 'AV/C' is many series of specification defined by '1394TA'.

3.Firewire Sound Devices 

- They typically have:
 - a chipset for 'IEEE1394 Phy layer and Link layer'
 - a firmware for 'Transaction layer', 'Serial Bus Management' and  'IEC 61883-1/6'
 - a chipset for signal processing
 - a chipset for D/A or A/D convertion

4.Firewire Sound Drivers 

- Firewire Sound Drivers Use IEEE1394 host controller to communicate to Firewire Sound Devices
- In Linux, driver of host controller is developed at ieee1394.wiki.kernel.org. This driver has a nick name, 'Juju'. This driver exports some kernel APIs.
- ALSA Firewire Sound Drivers use the kernel APIs.
- 'snd-firewire-lib' exports helper functions for ALSA Firewire Sound Drivers.

5.What to do inner Firewire Sound Drivers 

- Register/unregister myself as module for Linux
- React bus events with Juju
- Register/unregister cards for ALSA Core
- Add interfaces for ALSA components
- Handle Input/Output to/from ALSA applications
- Send/Receive transactions to/from Firewire Sound Devices
- Send/Receive packets to/from Firewire Sound Devices
- Parse/Compose data for Firewire Sound Devices

6.Connections 

- See IEC 61883-1.
- This is for Firewire Sound Devices compliant to IEC 61883-1.
- They manage isochronous resource with 'Connection'.
- This 'Connection' is expressed as a value of 'Plug Control Register'.
- The drivers send/receive transactions to handle 'Plug Control Register'.
- The way to handle 'Connection' is defined in IEC 61883-1.

7.Packets 

- See IEC 61883-1.
- 'Isochronous Packet' has its own header. Its payload has a 'Common Isochronous Packet'.
- 'Common Isochronous Packet' have its own header. Its payload has some data blocks.
- 'AMDTP' uses 'Common Isochronous Packet header with SYT field'.
- In 'AMDTP', data block consists of some data channels.
- For Firewire Sound Devices, the data channel is generally used for PCM samples and MIDI messages.
- 'PCM samples' and 'MIDI messages' can be transferred in the same 'AMDTP' packet.

8.Presentation Timestamp 

- See IEC 61883-1.
- This is in a 'SYT' field in 'Common Isochronous Packet header with SYT field'.
- This field is 16 bit. This field cannot indicate an actual time.
- The value of this field is '0xffff' if the packet has no 'presentation timestamp'.
- The devices can be synchronized with the value of this field.
- Firewire Sound Drivers need to calcurate the value of this field in 'out-stream'.
- Then Firewire Sound Drivers should use the value of this field in 'in-stream' for 'out-stream'.

9.AMDTP and PCM samples 

- See IEC 61883-6.
- The value of 'FDF' in 'Common Isochronous Packet' header includes 'SFC' field for 'sampling rate'.
- 'Common Isochronous Packet' includes some 'event' in its data block.
- The 'event' means 'data in the same timestamp'. So one 'event' includes a set of PCM channels (= one frame).
- There are two ways to decide the number of 'events' in an 'Common Isochronous Packet', 'non-blocking' and 'blocking'.
- In 'non-blocking' mode:
 - In each 'Common Isochronous Packet', the number of 'event' is different.
 - All of 'Common Isochronous Packet' has PCM samples.
 - The value of 'SYT' field is for a certain 'event' in the 'Common Isochronous Packet'.
- In 'blocking' mode:
 - In each 'Common Isochronous Packet', the number of 'event' is the same.
 - Some 'Common Isochronous Packet' has no PCM samples (empty packet or packet with NODATA flag).
 - The value of 'SYT' field is for the first 'event' in the 'Common Isochronous Packet'.
- In both modes, the total number of 'events' with PCM samples are the same as sampling rate.
- Most Firewire Sound Devies use 'blocking mode'.

10.MIDI Conformant Data Channel 

- See IEC 61883-6 and MMA/AMEI RP-027.
- 'MIDI Conformant Data Channel' is for transfer of MIDI messages.
- Each 'MIDI Conformant Data Channel' includes 8 'MPX-MIDI Data Stream'.
- Each 'MPX-MIDI Data Stream' includes one data stream from/to MIDI ports.
- 'MIDI1.0-1x-SPEED' mode is major.
- 'MIDI1.0-2x/3x-SPEED' mode are described with 'negotiation procedure' and 'encapsulation details' but there is no specifications to define them.

11.Function Control Protocol 

- See IEC 61883-1.
- 'Function Control Protocol' is an application of 'Asynchronous Transaction' in IEEE1394.
- 'Function Control Protocol' is done by command/response.
- Command is sent to '0xffff f000 0b00'
- Response is sent to '0xffff f000 0d00'
- To receive response from device, drivers need to listen this address (so-called allocation).

12.AV/C commands 

- 'AV/C commands' is an application of 'Function Cotrol Protocol'.
- The maximum size of command is 512 bytes.
- There are much variations, vendor-specific extensions.
- Basically, see 'AV/C Digital Interface Command Set General Specification Version 4.2 (Sept 2004, 1394TA)'.
- For Audio Subunit, see 'AV/C Audio Subunit Specification 1.0 (Oct 2000, 1394TA)'.
- For Music Subunit, see 'AV/C Music Subunit Specification 1.0 (I don't have)'.
- For Stream Format, see 'AV/C Stream Format Information Specification 1.0 (I don't have)'
- For Descriptor Mechanism, see 'Enhancements to the AV/C General Specification 3.0 Version 1.1 (Oct 2000, 1394TA)'.

13.Sampling Clock Source 

- This is device-dependent issue.
- Usually Firewire Sound Devices use internal clock.
- But some devices can switch its source of sampling clock. 
- There is Coaxial, Optical and XLR interface for this purpose.
- And there is 'Synchronization Stream'. In this stream, the value of 'SYT' field can be used for sampling clock.
- When source of clock is given by external, available sampling rate is limited at current one.

14.Quirks 

- Fireworks:
 - 1.Fireworks transmits packets with both TAG0 and TAG1. In IEC 61883-1, each common isochronous packet (CIP) has 'tag' field in its packet header. The value is generally 0x01 ('CIP header is included' = TAG1). But Fireworks in 'IEC 61883 compliant mode' transmits 'no data' packet with 0x00 ('No CIP header is included' = TAG0) but actually the packet includes CIP structure. To handle 'presentation timestamp' for duplex streams synchronization, this packets must be handled.

 - 2.Fireworks transmits 'no data' packet out of specification. Fireworks transmits 'no data' packet with 'NO-DATA' FDF and no dummy data. It includes CIP headers only. In IEC 61883-6, 'no data' packet is generated by two ways. One is empty CIP packet defined in IEC 61883-1. Another is 'special non-empty packet' defined in IEC 61883-6. Fireworks uses strange combination of them.

 - 3.Fireworks can handle MIDI messages in the first 8 data blocks of out-packet, Fireworks ignores MIDI messages in other data blocks.

 - 4.AudioFirePre8 transmits packets with wrong data block size. One of Fireworks device, AudioFirePre8, always reports 8 data block size in transmitted packets and increments the data block counter by 8. But this is not actual value.

 - 5.Fireworks transmits packets with a bit disorder. See:

Index	Payload	CIP header 1CIP header 2
023	210	3F1100F8	900478E9
024	002	3F1100F8	90FFFFFF
025	210	3F110000	900490E9
026	210	3F110008	9004A4E9
027	210	3F110010	9004B8E9
028	002	3F110010	90FFFFFF
029	210	3F110020	9004E4E8 <-
030	210	3F110018	9004D0E8 <-
031	210	3F110028	9004F8E8
032	002	3F110028	90FFFFFF
033	210	3F110030	900410E8
034	210	3F110038	900424E8
035	210	3F110040	900438E8
036	002	3F110040	90FFFFFF
037	210	3F110050	900464E8 <-
038	210	3F110048	900450E8 <-
039	210	3F110058	900478E8
040	002	3F110058	90FFFFFF
041	210	3F110068	9004A4E8 <-
042	210	3F110060	900490E8 <-
043	210	3F110070	9004B8E8
044	002	3F110070	90FFFFFF
045	210	3F110080	9004E4E7 <-
046	210	3F110078	9004D0E8 <-

- BeBoB
 - BeBoB has its own AV/C extension command

- OXFW970/971
 - OXFW970/971 transmit packets with invalid value of 'SYT' field. See:

When driver gives no out-stream:
Index	Payload	CIP_Header_0	CIP_Header_1
38	14	00020092	900103D1
39	12	00020098	900102FF
40	12	0002009D	9001027F
41	14	000200A2	90010396
42	14	000200A8	900102E8
43	12	000200AE	90010219
44	14	000200B3	90010331
45	12	000200B9	9001025F
46	14	000200BE	90010376
47	12	000200C4	900102A1
00	12	000200C9	9001023E
01	14	000200CE	90010358
02	12	000200D4	90010289
03	16	000200D9	900103A3
04	12	000200E0	900102DD
05	14	000200E5	900103F1
06	12	000200EB	90010335
07	12	000200F0	90010263
08	14	000200F5	9001037C
09	12	000200FB	900102AE

When driver gives out-stream:
Index	Payload	CIP_Header_0	CIP_Header_1
38	12	000200BD	900104A8
39	14	000200C2	900104A8
40	12	000200C8	900104AC
41	14	000200CD	900104A9
42	12	000200D3	900104B1
43	14	000200D8	900104A8
44	12	000200DE	900104AA
45	14	000200E3	900104A9
46	14	000200E9	900104AE
47	12	000200EF	900104A8
00	14	000200F4	900104AD
01	12	000200FA	900104A7
02	14	000200FF	900104A9
03	12	00020005	900104A9
04	14	0002000A	900104B1
05	12	00020010	900104AA
06	14	00020015	900104AD
07	12	0002001B	900104A7
08	14	00020020	900104AC
09	12	00020026	900104A7

End

Retrieved from "https://www.alsa-project.org/main/index.php?title=User:Takaswie&oldid=6700"