diff options
author | Takashi Sakamoto <o-takashi@sakamocchi.jp> | 2017-03-31 22:06:08 +0900 |
---|---|---|
committer | Takashi Iwai <tiwai@suse.de> | 2017-04-05 21:31:42 +0200 |
commit | 6fb7db902bbe6358b39f359b917f10e3c923058c (patch) | |
tree | b9b38f4a2bd1b75b26be44d85846de029e5120b9 /drivers/clk | |
parent | 3b196c394dd9f8f34064f5814bb287757c80ee35 (diff) | |
download | linux-stable-6fb7db902bbe6358b39f359b917f10e3c923058c.tar.gz linux-stable-6fb7db902bbe6358b39f359b917f10e3c923058c.tar.bz2 linux-stable-6fb7db902bbe6358b39f359b917f10e3c923058c.zip |
ALSA: fireface: add unique data processing layer
As long as investigating Fireface 400, format of payload of each
isochronous packet is not IEC 61883-1/6, thus its format of data block
is not AM824. The remarkable points of the format are:
* The payload just consists of some data channels of quadlet size without
CIP header.
* Each data channels includes data aligned to little endian order.
* One data channel consists of two parts; 8 bit ancillary field and 24 bit
PCM frame.
Due to lack of CIP headers, rx/tx packets include no CIP headers and
different way to check packet discontinuity. For tx packet, the ancillary
field is used for counter. However, the way of counting is different
depending on positions of data channels. At 44.1 kHz, ancillary field in:
* 1st/6th/9th/10th/14th/17th data channels: not used for this purpose.
* 2nd/18th data channels: incremented every data block (0x00-0xff).
* 3rd/4th/5th/11th/12th/13th data channels: incremented every 256 data
blocks (0x00-0x07).
* 7th/8th/15th/16th data channels: incremented per the number of data
blocks in a packet. The increment can occur per packet (0x00-0xff).
For tx packet, tag of each isochronous packet is used for this purpose.
The value of tag cyclically changes between 0, 1, 2 and 3 in this order.
The interval is different depending on sampling transmission frequency.
At 44.1/48.0 kHz, it's 256 data blocks. At 88.2 kHz, it's 96 data blocks.
The number of data blocks in tx packet is exactly the same as
SYT_INTERVAL. There's no empty packet or no-data packet, thus the
throughput is not 8,000 packets per sec. On the other hand, the one in
rx packet is 8,000 packets per sec, thus the number of data blocks is
different between each packet, depending on sampling transmission
frequency:
* 44.1 kHz: 5 or 6
* 48.0 kHz: 5 or 6 or 7
* 88.2 kHz: 10 or 11 or 12
This commit adds data processing layer to satisfy the above specification
in a policy of 'best effort'. Although PCM frames are handled for
intermediate buffer to user space, the ancillary data is not handled at all
to reduce CPU usage, thus counter is not checked. 0 is always used for tag
of isochronous packet. Furthermore, the packet streaming layer is
responsible for calculation of the number of data blocks for each packet,
thus it's not exactly the same sequence from the above observation.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Diffstat (limited to 'drivers/clk')
0 files changed, 0 insertions, 0 deletions