linux-stable/sound/firewire/motu/amdtp-motu.c

490 lines
12 KiB
C
Raw Normal View History

// SPDX-License-Identifier: GPL-2.0-only
ALSA: firewire-motu: add MOTU specific protocol layer MOTU FireWire series uses blocking transmission for AMDTP packet streaming. They transmit/receive 8,000 packets per second, to handle the same number of data blocks as current sampling transmission frequency. Thus, IEC 61883-1/6 packet streaming engine of ALSA firewire stack is available for them. However, the sequence of packet and data blocks includes some quirks. Below sample is a sequence of CIP headers of packets received by 828mk2, at 44.1kHz of sampling transmission frequency. quads CIP1 CIP2 488 0x020F04E8 0x8222FFFF 8 0x020F04F8 0x8222FFFF 488 0x020F0400 0x8222FFFF 488 0x020F0408 0x8222FFFF 8 0x020F04E8 0x8222FFFF 488 0x020F04F0 0x8222FFFF 488 0x020F04F8 0x8222FFFF The SID (source node ID), DBS (data block size), SPH (source packet header), FMT (format ID), FDF (format dependent field) and SYT (time stamp) fields are in IEC 61883-1. Especially, FMT is 0x02, FDF is 0x22 and SYT is 0xffff to define MOTU specific protocol. In an aspect of dbc field, the value represents accumulated number of data blocks included the packet. This is against IEC 61883-1, because according to the specification this value should be the number of data blocks already transferred. In ALSA IEC 61883-1/6 engine, this quirk is already supported by CIP_DBC_IS_END_EVENT flag, because Echo Audio Fireworks has. Each data block includes SPH as its first quadlet field, to represent its presentation time stamp. Actual value of SPH is compliant to IEC 61883-1; lower 25 bits of 32 bits width consists of 13 bits cycle count and 12 bits cycle offset. The rest of each data block consists of 24 bit chunks. All of PCM samples, MIDI messages, status and control messages are transferred by the chunks. This is similar to '24-bit * 4 Audio Pack' in IEC 61883-6. The position of each kind of data depends on generations of each model. The number of whole chunks in a data block is a multiple of 4, to consists of quadlet-aligned packets. This commit adds data block processing layer specific for the MOTU protocol. The remarkable point is the way to generate SPH header. Time stamps for each data blocks are generated by below calculation: * Using pre-computed table for the number of ticks per event * 44,1kHz: (557 + 123/441) * 48.0kHz: (512 + 0/441) * 88.2kHz: (278 + 282/441) * 96.0kHz: (256 + 0/441) * 176.4kHz: (139 + 141/441) * 192.0kHz: (128 + 0/441) * Accumulate the ticks and set the value to SPH for every events. * This way makes sense only for blocking transmission because this mode transfers fixed number or none of events. This calculation assumes that each data block has a PCM frame which is sampled according to event timing clock. Current packet streaming layer has the same assumption. Although this sequence works fine for MOTU FireWire series at sampling transmission frequency based on 48.0kHz, it is not enough at the frequency based on 44.1kHz. The units generate choppy noise every few seconds. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2017-03-22 12:30:18 +00:00
/*
* amdtp-motu.c - a part of driver for MOTU FireWire series
*
* Copyright (c) 2015-2017 Takashi Sakamoto <o-takashi@sakamocchi.jp>
*/
#include <linux/slab.h>
#include <sound/pcm.h>
#include "motu.h"
#define CREATE_TRACE_POINTS
#include "amdtp-motu-trace.h"
ALSA: firewire-motu: add MOTU specific protocol layer MOTU FireWire series uses blocking transmission for AMDTP packet streaming. They transmit/receive 8,000 packets per second, to handle the same number of data blocks as current sampling transmission frequency. Thus, IEC 61883-1/6 packet streaming engine of ALSA firewire stack is available for them. However, the sequence of packet and data blocks includes some quirks. Below sample is a sequence of CIP headers of packets received by 828mk2, at 44.1kHz of sampling transmission frequency. quads CIP1 CIP2 488 0x020F04E8 0x8222FFFF 8 0x020F04F8 0x8222FFFF 488 0x020F0400 0x8222FFFF 488 0x020F0408 0x8222FFFF 8 0x020F04E8 0x8222FFFF 488 0x020F04F0 0x8222FFFF 488 0x020F04F8 0x8222FFFF The SID (source node ID), DBS (data block size), SPH (source packet header), FMT (format ID), FDF (format dependent field) and SYT (time stamp) fields are in IEC 61883-1. Especially, FMT is 0x02, FDF is 0x22 and SYT is 0xffff to define MOTU specific protocol. In an aspect of dbc field, the value represents accumulated number of data blocks included the packet. This is against IEC 61883-1, because according to the specification this value should be the number of data blocks already transferred. In ALSA IEC 61883-1/6 engine, this quirk is already supported by CIP_DBC_IS_END_EVENT flag, because Echo Audio Fireworks has. Each data block includes SPH as its first quadlet field, to represent its presentation time stamp. Actual value of SPH is compliant to IEC 61883-1; lower 25 bits of 32 bits width consists of 13 bits cycle count and 12 bits cycle offset. The rest of each data block consists of 24 bit chunks. All of PCM samples, MIDI messages, status and control messages are transferred by the chunks. This is similar to '24-bit * 4 Audio Pack' in IEC 61883-6. The position of each kind of data depends on generations of each model. The number of whole chunks in a data block is a multiple of 4, to consists of quadlet-aligned packets. This commit adds data block processing layer specific for the MOTU protocol. The remarkable point is the way to generate SPH header. Time stamps for each data blocks are generated by below calculation: * Using pre-computed table for the number of ticks per event * 44,1kHz: (557 + 123/441) * 48.0kHz: (512 + 0/441) * 88.2kHz: (278 + 282/441) * 96.0kHz: (256 + 0/441) * 176.4kHz: (139 + 141/441) * 192.0kHz: (128 + 0/441) * Accumulate the ticks and set the value to SPH for every events. * This way makes sense only for blocking transmission because this mode transfers fixed number or none of events. This calculation assumes that each data block has a PCM frame which is sampled according to event timing clock. Current packet streaming layer has the same assumption. Although this sequence works fine for MOTU FireWire series at sampling transmission frequency based on 48.0kHz, it is not enough at the frequency based on 44.1kHz. The units generate choppy noise every few seconds. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2017-03-22 12:30:18 +00:00
#define CIP_FMT_MOTU 0x02
ALSA: firewire-motu: add support for MOTU 828mk3 (FireWire/Hybrid) as a model with protocol version 3 MOTU 828mk3 (FireWire/Hybrid) is one of third generation in MOTU FireWire series, produced in 2008/2014. This model consists of three chips for functionality on IEEE 1394 bus: * TI TSB41AB2 (Physical layer for IEEE 1394 bus) * Xilinx Spartan-3E FPGA Family (Link layer for IEEE 1394 bus, packet processing and data block processing layer) * TI TMS320C6722 (Digital signal processing) This commit adds a support for this model, with its unique protocol as version 3. This protocol has some additional features to protocol version 2. * Support several optical interfaces. * Support a data chunk for return of reverb effect. * Have a quirk of tx packets. * Support heartbeat asynchronous transaction. In this protocol, series of transferred packets has some quirks. Below fields in CIP headers of the packets are out of IEC 61883-1: - SID (source node id): always 0x0d - DBS (data block size): always 0x04 - DBC (data block counter): always 0x00 - EOH (End of header): always 0x00 Below is an actual sample of transferred packets. quads CIP1 CIP2 520 0x0D040400 0x22FFFFFF 8 0x0D040400 0x22FFFFFF 520 0x0D040400 0x22FFFFFF 520 0x0D040400 0x22FFFFFF 8 0x0D040400 0x22FFFFFF Status of clock is configured by write transactions to 0x'ffff'f000'0b14, as well as version 2, while meanings of fields are different from the former protocols. Modes of optical interfaces are configured by write transactions to 0x'ffff'f000'0c94. Drivers can register its address to receive heatbeat transactions from the unit. 0x'ffff'f000'0b0c is for the higher part and 0x'ffff'f000'0b10 is for the lower part. Nevertheless, this feature is not useless for this driver and this commit omits it. Each data block consists of two parts in a point of the number of included data chunks. In both of 'fixed' and 'differed' parts, the number of included data blocks are a multiple of 4, thus depending on models there's some empty data chunks. For example, 828mk3 includes one pair of empty data chunks in its fixed part. When optical interface is configured to S/PDIF, 828mk3 includes one pair of empty data chunks in its differed part. To reduce consumption of CPU cycles with additional conditions/loops, this commit just exposes these empty chunks to user space as PCM channels. Additionally, 828mk3 has a non-negligible overhead to change its sampling transfer frequency. When softwares send asynchronous transaction to perform it, LED on the unit starts to blink. In a worst case, it continues blink during several seconds; e.g. 10 seconds. When stopping blinking, the unit seems to be prepared for the requested sampling transfer frequency. To wait for the preparation, this commit forces the driver to call task scheduler and applications sleeps for 4 seconds. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2017-03-22 12:30:28 +00:00
#define CIP_FMT_MOTU_TX_V3 0x22
ALSA: firewire-motu: add MOTU specific protocol layer MOTU FireWire series uses blocking transmission for AMDTP packet streaming. They transmit/receive 8,000 packets per second, to handle the same number of data blocks as current sampling transmission frequency. Thus, IEC 61883-1/6 packet streaming engine of ALSA firewire stack is available for them. However, the sequence of packet and data blocks includes some quirks. Below sample is a sequence of CIP headers of packets received by 828mk2, at 44.1kHz of sampling transmission frequency. quads CIP1 CIP2 488 0x020F04E8 0x8222FFFF 8 0x020F04F8 0x8222FFFF 488 0x020F0400 0x8222FFFF 488 0x020F0408 0x8222FFFF 8 0x020F04E8 0x8222FFFF 488 0x020F04F0 0x8222FFFF 488 0x020F04F8 0x8222FFFF The SID (source node ID), DBS (data block size), SPH (source packet header), FMT (format ID), FDF (format dependent field) and SYT (time stamp) fields are in IEC 61883-1. Especially, FMT is 0x02, FDF is 0x22 and SYT is 0xffff to define MOTU specific protocol. In an aspect of dbc field, the value represents accumulated number of data blocks included the packet. This is against IEC 61883-1, because according to the specification this value should be the number of data blocks already transferred. In ALSA IEC 61883-1/6 engine, this quirk is already supported by CIP_DBC_IS_END_EVENT flag, because Echo Audio Fireworks has. Each data block includes SPH as its first quadlet field, to represent its presentation time stamp. Actual value of SPH is compliant to IEC 61883-1; lower 25 bits of 32 bits width consists of 13 bits cycle count and 12 bits cycle offset. The rest of each data block consists of 24 bit chunks. All of PCM samples, MIDI messages, status and control messages are transferred by the chunks. This is similar to '24-bit * 4 Audio Pack' in IEC 61883-6. The position of each kind of data depends on generations of each model. The number of whole chunks in a data block is a multiple of 4, to consists of quadlet-aligned packets. This commit adds data block processing layer specific for the MOTU protocol. The remarkable point is the way to generate SPH header. Time stamps for each data blocks are generated by below calculation: * Using pre-computed table for the number of ticks per event * 44,1kHz: (557 + 123/441) * 48.0kHz: (512 + 0/441) * 88.2kHz: (278 + 282/441) * 96.0kHz: (256 + 0/441) * 176.4kHz: (139 + 141/441) * 192.0kHz: (128 + 0/441) * Accumulate the ticks and set the value to SPH for every events. * This way makes sense only for blocking transmission because this mode transfers fixed number or none of events. This calculation assumes that each data block has a PCM frame which is sampled according to event timing clock. Current packet streaming layer has the same assumption. Although this sequence works fine for MOTU FireWire series at sampling transmission frequency based on 48.0kHz, it is not enough at the frequency based on 44.1kHz. The units generate choppy noise every few seconds. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2017-03-22 12:30:18 +00:00
#define MOTU_FDF_AM824 0x22
#define TICKS_PER_CYCLE 3072
#define CYCLES_PER_SECOND 8000
#define TICKS_PER_SECOND (TICKS_PER_CYCLE * CYCLES_PER_SECOND)
#define CIP_SPH_CYCLE_SHIFT 12
#define CIP_SPH_CYCLE_MASK 0x01fff000
#define CIP_SPH_OFFSET_MASK 0x00000fff
/*
* Nominally 3125 bytes/second, but the MIDI port's clock might be
* 1% too slow, and the bus clock 100 ppm too fast.
*/
#define MIDI_BYTES_PER_SECOND 3093
ALSA: firewire-motu: add MOTU specific protocol layer MOTU FireWire series uses blocking transmission for AMDTP packet streaming. They transmit/receive 8,000 packets per second, to handle the same number of data blocks as current sampling transmission frequency. Thus, IEC 61883-1/6 packet streaming engine of ALSA firewire stack is available for them. However, the sequence of packet and data blocks includes some quirks. Below sample is a sequence of CIP headers of packets received by 828mk2, at 44.1kHz of sampling transmission frequency. quads CIP1 CIP2 488 0x020F04E8 0x8222FFFF 8 0x020F04F8 0x8222FFFF 488 0x020F0400 0x8222FFFF 488 0x020F0408 0x8222FFFF 8 0x020F04E8 0x8222FFFF 488 0x020F04F0 0x8222FFFF 488 0x020F04F8 0x8222FFFF The SID (source node ID), DBS (data block size), SPH (source packet header), FMT (format ID), FDF (format dependent field) and SYT (time stamp) fields are in IEC 61883-1. Especially, FMT is 0x02, FDF is 0x22 and SYT is 0xffff to define MOTU specific protocol. In an aspect of dbc field, the value represents accumulated number of data blocks included the packet. This is against IEC 61883-1, because according to the specification this value should be the number of data blocks already transferred. In ALSA IEC 61883-1/6 engine, this quirk is already supported by CIP_DBC_IS_END_EVENT flag, because Echo Audio Fireworks has. Each data block includes SPH as its first quadlet field, to represent its presentation time stamp. Actual value of SPH is compliant to IEC 61883-1; lower 25 bits of 32 bits width consists of 13 bits cycle count and 12 bits cycle offset. The rest of each data block consists of 24 bit chunks. All of PCM samples, MIDI messages, status and control messages are transferred by the chunks. This is similar to '24-bit * 4 Audio Pack' in IEC 61883-6. The position of each kind of data depends on generations of each model. The number of whole chunks in a data block is a multiple of 4, to consists of quadlet-aligned packets. This commit adds data block processing layer specific for the MOTU protocol. The remarkable point is the way to generate SPH header. Time stamps for each data blocks are generated by below calculation: * Using pre-computed table for the number of ticks per event * 44,1kHz: (557 + 123/441) * 48.0kHz: (512 + 0/441) * 88.2kHz: (278 + 282/441) * 96.0kHz: (256 + 0/441) * 176.4kHz: (139 + 141/441) * 192.0kHz: (128 + 0/441) * Accumulate the ticks and set the value to SPH for every events. * This way makes sense only for blocking transmission because this mode transfers fixed number or none of events. This calculation assumes that each data block has a PCM frame which is sampled according to event timing clock. Current packet streaming layer has the same assumption. Although this sequence works fine for MOTU FireWire series at sampling transmission frequency based on 48.0kHz, it is not enough at the frequency based on 44.1kHz. The units generate choppy noise every few seconds. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2017-03-22 12:30:18 +00:00
struct amdtp_motu {
unsigned int pcm_chunks;
unsigned int pcm_byte_offset;
struct snd_rawmidi_substream *midi;
unsigned int midi_ports;
unsigned int midi_flag_offset;
unsigned int midi_byte_offset;
int midi_db_count;
unsigned int midi_db_interval;
struct amdtp_motu_cache *cache;
ALSA: firewire-motu: add MOTU specific protocol layer MOTU FireWire series uses blocking transmission for AMDTP packet streaming. They transmit/receive 8,000 packets per second, to handle the same number of data blocks as current sampling transmission frequency. Thus, IEC 61883-1/6 packet streaming engine of ALSA firewire stack is available for them. However, the sequence of packet and data blocks includes some quirks. Below sample is a sequence of CIP headers of packets received by 828mk2, at 44.1kHz of sampling transmission frequency. quads CIP1 CIP2 488 0x020F04E8 0x8222FFFF 8 0x020F04F8 0x8222FFFF 488 0x020F0400 0x8222FFFF 488 0x020F0408 0x8222FFFF 8 0x020F04E8 0x8222FFFF 488 0x020F04F0 0x8222FFFF 488 0x020F04F8 0x8222FFFF The SID (source node ID), DBS (data block size), SPH (source packet header), FMT (format ID), FDF (format dependent field) and SYT (time stamp) fields are in IEC 61883-1. Especially, FMT is 0x02, FDF is 0x22 and SYT is 0xffff to define MOTU specific protocol. In an aspect of dbc field, the value represents accumulated number of data blocks included the packet. This is against IEC 61883-1, because according to the specification this value should be the number of data blocks already transferred. In ALSA IEC 61883-1/6 engine, this quirk is already supported by CIP_DBC_IS_END_EVENT flag, because Echo Audio Fireworks has. Each data block includes SPH as its first quadlet field, to represent its presentation time stamp. Actual value of SPH is compliant to IEC 61883-1; lower 25 bits of 32 bits width consists of 13 bits cycle count and 12 bits cycle offset. The rest of each data block consists of 24 bit chunks. All of PCM samples, MIDI messages, status and control messages are transferred by the chunks. This is similar to '24-bit * 4 Audio Pack' in IEC 61883-6. The position of each kind of data depends on generations of each model. The number of whole chunks in a data block is a multiple of 4, to consists of quadlet-aligned packets. This commit adds data block processing layer specific for the MOTU protocol. The remarkable point is the way to generate SPH header. Time stamps for each data blocks are generated by below calculation: * Using pre-computed table for the number of ticks per event * 44,1kHz: (557 + 123/441) * 48.0kHz: (512 + 0/441) * 88.2kHz: (278 + 282/441) * 96.0kHz: (256 + 0/441) * 176.4kHz: (139 + 141/441) * 192.0kHz: (128 + 0/441) * Accumulate the ticks and set the value to SPH for every events. * This way makes sense only for blocking transmission because this mode transfers fixed number or none of events. This calculation assumes that each data block has a PCM frame which is sampled according to event timing clock. Current packet streaming layer has the same assumption. Although this sequence works fine for MOTU FireWire series at sampling transmission frequency based on 48.0kHz, it is not enough at the frequency based on 44.1kHz. The units generate choppy noise every few seconds. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2017-03-22 12:30:18 +00:00
};
int amdtp_motu_set_parameters(struct amdtp_stream *s, unsigned int rate,
unsigned int midi_ports,
ALSA: firewire-motu: add MOTU specific protocol layer MOTU FireWire series uses blocking transmission for AMDTP packet streaming. They transmit/receive 8,000 packets per second, to handle the same number of data blocks as current sampling transmission frequency. Thus, IEC 61883-1/6 packet streaming engine of ALSA firewire stack is available for them. However, the sequence of packet and data blocks includes some quirks. Below sample is a sequence of CIP headers of packets received by 828mk2, at 44.1kHz of sampling transmission frequency. quads CIP1 CIP2 488 0x020F04E8 0x8222FFFF 8 0x020F04F8 0x8222FFFF 488 0x020F0400 0x8222FFFF 488 0x020F0408 0x8222FFFF 8 0x020F04E8 0x8222FFFF 488 0x020F04F0 0x8222FFFF 488 0x020F04F8 0x8222FFFF The SID (source node ID), DBS (data block size), SPH (source packet header), FMT (format ID), FDF (format dependent field) and SYT (time stamp) fields are in IEC 61883-1. Especially, FMT is 0x02, FDF is 0x22 and SYT is 0xffff to define MOTU specific protocol. In an aspect of dbc field, the value represents accumulated number of data blocks included the packet. This is against IEC 61883-1, because according to the specification this value should be the number of data blocks already transferred. In ALSA IEC 61883-1/6 engine, this quirk is already supported by CIP_DBC_IS_END_EVENT flag, because Echo Audio Fireworks has. Each data block includes SPH as its first quadlet field, to represent its presentation time stamp. Actual value of SPH is compliant to IEC 61883-1; lower 25 bits of 32 bits width consists of 13 bits cycle count and 12 bits cycle offset. The rest of each data block consists of 24 bit chunks. All of PCM samples, MIDI messages, status and control messages are transferred by the chunks. This is similar to '24-bit * 4 Audio Pack' in IEC 61883-6. The position of each kind of data depends on generations of each model. The number of whole chunks in a data block is a multiple of 4, to consists of quadlet-aligned packets. This commit adds data block processing layer specific for the MOTU protocol. The remarkable point is the way to generate SPH header. Time stamps for each data blocks are generated by below calculation: * Using pre-computed table for the number of ticks per event * 44,1kHz: (557 + 123/441) * 48.0kHz: (512 + 0/441) * 88.2kHz: (278 + 282/441) * 96.0kHz: (256 + 0/441) * 176.4kHz: (139 + 141/441) * 192.0kHz: (128 + 0/441) * Accumulate the ticks and set the value to SPH for every events. * This way makes sense only for blocking transmission because this mode transfers fixed number or none of events. This calculation assumes that each data block has a PCM frame which is sampled according to event timing clock. Current packet streaming layer has the same assumption. Although this sequence works fine for MOTU FireWire series at sampling transmission frequency based on 48.0kHz, it is not enough at the frequency based on 44.1kHz. The units generate choppy noise every few seconds. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2017-03-22 12:30:18 +00:00
struct snd_motu_packet_format *formats)
{
struct amdtp_motu *p = s->protocol;
unsigned int pcm_chunks, data_chunks, data_block_quadlets;
unsigned int mode;
int i, err;
if (amdtp_stream_running(s))
return -EBUSY;
for (i = 0; i < ARRAY_SIZE(snd_motu_clock_rates); ++i) {
if (snd_motu_clock_rates[i] == rate) {
mode = i >> 1;
break;
}
}
if (i == ARRAY_SIZE(snd_motu_clock_rates))
return -EINVAL;
// Each data block includes SPH in its head. Data chunks follow with
// 3 byte alignment. Padding follows with zero to conform to quadlet
// alignment.
pcm_chunks = formats->pcm_chunks[mode];
ALSA: firewire-motu: add MOTU specific protocol layer MOTU FireWire series uses blocking transmission for AMDTP packet streaming. They transmit/receive 8,000 packets per second, to handle the same number of data blocks as current sampling transmission frequency. Thus, IEC 61883-1/6 packet streaming engine of ALSA firewire stack is available for them. However, the sequence of packet and data blocks includes some quirks. Below sample is a sequence of CIP headers of packets received by 828mk2, at 44.1kHz of sampling transmission frequency. quads CIP1 CIP2 488 0x020F04E8 0x8222FFFF 8 0x020F04F8 0x8222FFFF 488 0x020F0400 0x8222FFFF 488 0x020F0408 0x8222FFFF 8 0x020F04E8 0x8222FFFF 488 0x020F04F0 0x8222FFFF 488 0x020F04F8 0x8222FFFF The SID (source node ID), DBS (data block size), SPH (source packet header), FMT (format ID), FDF (format dependent field) and SYT (time stamp) fields are in IEC 61883-1. Especially, FMT is 0x02, FDF is 0x22 and SYT is 0xffff to define MOTU specific protocol. In an aspect of dbc field, the value represents accumulated number of data blocks included the packet. This is against IEC 61883-1, because according to the specification this value should be the number of data blocks already transferred. In ALSA IEC 61883-1/6 engine, this quirk is already supported by CIP_DBC_IS_END_EVENT flag, because Echo Audio Fireworks has. Each data block includes SPH as its first quadlet field, to represent its presentation time stamp. Actual value of SPH is compliant to IEC 61883-1; lower 25 bits of 32 bits width consists of 13 bits cycle count and 12 bits cycle offset. The rest of each data block consists of 24 bit chunks. All of PCM samples, MIDI messages, status and control messages are transferred by the chunks. This is similar to '24-bit * 4 Audio Pack' in IEC 61883-6. The position of each kind of data depends on generations of each model. The number of whole chunks in a data block is a multiple of 4, to consists of quadlet-aligned packets. This commit adds data block processing layer specific for the MOTU protocol. The remarkable point is the way to generate SPH header. Time stamps for each data blocks are generated by below calculation: * Using pre-computed table for the number of ticks per event * 44,1kHz: (557 + 123/441) * 48.0kHz: (512 + 0/441) * 88.2kHz: (278 + 282/441) * 96.0kHz: (256 + 0/441) * 176.4kHz: (139 + 141/441) * 192.0kHz: (128 + 0/441) * Accumulate the ticks and set the value to SPH for every events. * This way makes sense only for blocking transmission because this mode transfers fixed number or none of events. This calculation assumes that each data block has a PCM frame which is sampled according to event timing clock. Current packet streaming layer has the same assumption. Although this sequence works fine for MOTU FireWire series at sampling transmission frequency based on 48.0kHz, it is not enough at the frequency based on 44.1kHz. The units generate choppy noise every few seconds. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2017-03-22 12:30:18 +00:00
data_chunks = formats->msg_chunks + pcm_chunks;
data_block_quadlets = 1 + DIV_ROUND_UP(data_chunks * 3, 4);
err = amdtp_stream_set_parameters(s, rate, data_block_quadlets);
if (err < 0)
return err;
p->pcm_chunks = pcm_chunks;
p->pcm_byte_offset = formats->pcm_byte_offset;
p->midi_ports = midi_ports;
p->midi_flag_offset = formats->midi_flag_offset;
p->midi_byte_offset = formats->midi_byte_offset;
p->midi_db_count = 0;
p->midi_db_interval = rate / MIDI_BYTES_PER_SECOND;
ALSA: firewire-motu: add MOTU specific protocol layer MOTU FireWire series uses blocking transmission for AMDTP packet streaming. They transmit/receive 8,000 packets per second, to handle the same number of data blocks as current sampling transmission frequency. Thus, IEC 61883-1/6 packet streaming engine of ALSA firewire stack is available for them. However, the sequence of packet and data blocks includes some quirks. Below sample is a sequence of CIP headers of packets received by 828mk2, at 44.1kHz of sampling transmission frequency. quads CIP1 CIP2 488 0x020F04E8 0x8222FFFF 8 0x020F04F8 0x8222FFFF 488 0x020F0400 0x8222FFFF 488 0x020F0408 0x8222FFFF 8 0x020F04E8 0x8222FFFF 488 0x020F04F0 0x8222FFFF 488 0x020F04F8 0x8222FFFF The SID (source node ID), DBS (data block size), SPH (source packet header), FMT (format ID), FDF (format dependent field) and SYT (time stamp) fields are in IEC 61883-1. Especially, FMT is 0x02, FDF is 0x22 and SYT is 0xffff to define MOTU specific protocol. In an aspect of dbc field, the value represents accumulated number of data blocks included the packet. This is against IEC 61883-1, because according to the specification this value should be the number of data blocks already transferred. In ALSA IEC 61883-1/6 engine, this quirk is already supported by CIP_DBC_IS_END_EVENT flag, because Echo Audio Fireworks has. Each data block includes SPH as its first quadlet field, to represent its presentation time stamp. Actual value of SPH is compliant to IEC 61883-1; lower 25 bits of 32 bits width consists of 13 bits cycle count and 12 bits cycle offset. The rest of each data block consists of 24 bit chunks. All of PCM samples, MIDI messages, status and control messages are transferred by the chunks. This is similar to '24-bit * 4 Audio Pack' in IEC 61883-6. The position of each kind of data depends on generations of each model. The number of whole chunks in a data block is a multiple of 4, to consists of quadlet-aligned packets. This commit adds data block processing layer specific for the MOTU protocol. The remarkable point is the way to generate SPH header. Time stamps for each data blocks are generated by below calculation: * Using pre-computed table for the number of ticks per event * 44,1kHz: (557 + 123/441) * 48.0kHz: (512 + 0/441) * 88.2kHz: (278 + 282/441) * 96.0kHz: (256 + 0/441) * 176.4kHz: (139 + 141/441) * 192.0kHz: (128 + 0/441) * Accumulate the ticks and set the value to SPH for every events. * This way makes sense only for blocking transmission because this mode transfers fixed number or none of events. This calculation assumes that each data block has a PCM frame which is sampled according to event timing clock. Current packet streaming layer has the same assumption. Although this sequence works fine for MOTU FireWire series at sampling transmission frequency based on 48.0kHz, it is not enough at the frequency based on 44.1kHz. The units generate choppy noise every few seconds. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2017-03-22 12:30:18 +00:00
return 0;
}
static void read_pcm_s32(struct amdtp_stream *s, struct snd_pcm_substream *pcm,
__be32 *buffer, unsigned int data_blocks,
unsigned int pcm_frames)
ALSA: firewire-motu: add MOTU specific protocol layer MOTU FireWire series uses blocking transmission for AMDTP packet streaming. They transmit/receive 8,000 packets per second, to handle the same number of data blocks as current sampling transmission frequency. Thus, IEC 61883-1/6 packet streaming engine of ALSA firewire stack is available for them. However, the sequence of packet and data blocks includes some quirks. Below sample is a sequence of CIP headers of packets received by 828mk2, at 44.1kHz of sampling transmission frequency. quads CIP1 CIP2 488 0x020F04E8 0x8222FFFF 8 0x020F04F8 0x8222FFFF 488 0x020F0400 0x8222FFFF 488 0x020F0408 0x8222FFFF 8 0x020F04E8 0x8222FFFF 488 0x020F04F0 0x8222FFFF 488 0x020F04F8 0x8222FFFF The SID (source node ID), DBS (data block size), SPH (source packet header), FMT (format ID), FDF (format dependent field) and SYT (time stamp) fields are in IEC 61883-1. Especially, FMT is 0x02, FDF is 0x22 and SYT is 0xffff to define MOTU specific protocol. In an aspect of dbc field, the value represents accumulated number of data blocks included the packet. This is against IEC 61883-1, because according to the specification this value should be the number of data blocks already transferred. In ALSA IEC 61883-1/6 engine, this quirk is already supported by CIP_DBC_IS_END_EVENT flag, because Echo Audio Fireworks has. Each data block includes SPH as its first quadlet field, to represent its presentation time stamp. Actual value of SPH is compliant to IEC 61883-1; lower 25 bits of 32 bits width consists of 13 bits cycle count and 12 bits cycle offset. The rest of each data block consists of 24 bit chunks. All of PCM samples, MIDI messages, status and control messages are transferred by the chunks. This is similar to '24-bit * 4 Audio Pack' in IEC 61883-6. The position of each kind of data depends on generations of each model. The number of whole chunks in a data block is a multiple of 4, to consists of quadlet-aligned packets. This commit adds data block processing layer specific for the MOTU protocol. The remarkable point is the way to generate SPH header. Time stamps for each data blocks are generated by below calculation: * Using pre-computed table for the number of ticks per event * 44,1kHz: (557 + 123/441) * 48.0kHz: (512 + 0/441) * 88.2kHz: (278 + 282/441) * 96.0kHz: (256 + 0/441) * 176.4kHz: (139 + 141/441) * 192.0kHz: (128 + 0/441) * Accumulate the ticks and set the value to SPH for every events. * This way makes sense only for blocking transmission because this mode transfers fixed number or none of events. This calculation assumes that each data block has a PCM frame which is sampled according to event timing clock. Current packet streaming layer has the same assumption. Although this sequence works fine for MOTU FireWire series at sampling transmission frequency based on 48.0kHz, it is not enough at the frequency based on 44.1kHz. The units generate choppy noise every few seconds. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2017-03-22 12:30:18 +00:00
{
struct amdtp_motu *p = s->protocol;
unsigned int channels = p->pcm_chunks;
struct snd_pcm_runtime *runtime = pcm->runtime;
unsigned int pcm_buffer_pointer;
int remaining_frames;
ALSA: firewire-motu: add MOTU specific protocol layer MOTU FireWire series uses blocking transmission for AMDTP packet streaming. They transmit/receive 8,000 packets per second, to handle the same number of data blocks as current sampling transmission frequency. Thus, IEC 61883-1/6 packet streaming engine of ALSA firewire stack is available for them. However, the sequence of packet and data blocks includes some quirks. Below sample is a sequence of CIP headers of packets received by 828mk2, at 44.1kHz of sampling transmission frequency. quads CIP1 CIP2 488 0x020F04E8 0x8222FFFF 8 0x020F04F8 0x8222FFFF 488 0x020F0400 0x8222FFFF 488 0x020F0408 0x8222FFFF 8 0x020F04E8 0x8222FFFF 488 0x020F04F0 0x8222FFFF 488 0x020F04F8 0x8222FFFF The SID (source node ID), DBS (data block size), SPH (source packet header), FMT (format ID), FDF (format dependent field) and SYT (time stamp) fields are in IEC 61883-1. Especially, FMT is 0x02, FDF is 0x22 and SYT is 0xffff to define MOTU specific protocol. In an aspect of dbc field, the value represents accumulated number of data blocks included the packet. This is against IEC 61883-1, because according to the specification this value should be the number of data blocks already transferred. In ALSA IEC 61883-1/6 engine, this quirk is already supported by CIP_DBC_IS_END_EVENT flag, because Echo Audio Fireworks has. Each data block includes SPH as its first quadlet field, to represent its presentation time stamp. Actual value of SPH is compliant to IEC 61883-1; lower 25 bits of 32 bits width consists of 13 bits cycle count and 12 bits cycle offset. The rest of each data block consists of 24 bit chunks. All of PCM samples, MIDI messages, status and control messages are transferred by the chunks. This is similar to '24-bit * 4 Audio Pack' in IEC 61883-6. The position of each kind of data depends on generations of each model. The number of whole chunks in a data block is a multiple of 4, to consists of quadlet-aligned packets. This commit adds data block processing layer specific for the MOTU protocol. The remarkable point is the way to generate SPH header. Time stamps for each data blocks are generated by below calculation: * Using pre-computed table for the number of ticks per event * 44,1kHz: (557 + 123/441) * 48.0kHz: (512 + 0/441) * 88.2kHz: (278 + 282/441) * 96.0kHz: (256 + 0/441) * 176.4kHz: (139 + 141/441) * 192.0kHz: (128 + 0/441) * Accumulate the ticks and set the value to SPH for every events. * This way makes sense only for blocking transmission because this mode transfers fixed number or none of events. This calculation assumes that each data block has a PCM frame which is sampled according to event timing clock. Current packet streaming layer has the same assumption. Although this sequence works fine for MOTU FireWire series at sampling transmission frequency based on 48.0kHz, it is not enough at the frequency based on 44.1kHz. The units generate choppy noise every few seconds. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2017-03-22 12:30:18 +00:00
u8 *byte;
u32 *dst;
int i, c;
pcm_buffer_pointer = s->pcm_buffer_pointer + pcm_frames;
pcm_buffer_pointer %= runtime->buffer_size;
ALSA: firewire-motu: add MOTU specific protocol layer MOTU FireWire series uses blocking transmission for AMDTP packet streaming. They transmit/receive 8,000 packets per second, to handle the same number of data blocks as current sampling transmission frequency. Thus, IEC 61883-1/6 packet streaming engine of ALSA firewire stack is available for them. However, the sequence of packet and data blocks includes some quirks. Below sample is a sequence of CIP headers of packets received by 828mk2, at 44.1kHz of sampling transmission frequency. quads CIP1 CIP2 488 0x020F04E8 0x8222FFFF 8 0x020F04F8 0x8222FFFF 488 0x020F0400 0x8222FFFF 488 0x020F0408 0x8222FFFF 8 0x020F04E8 0x8222FFFF 488 0x020F04F0 0x8222FFFF 488 0x020F04F8 0x8222FFFF The SID (source node ID), DBS (data block size), SPH (source packet header), FMT (format ID), FDF (format dependent field) and SYT (time stamp) fields are in IEC 61883-1. Especially, FMT is 0x02, FDF is 0x22 and SYT is 0xffff to define MOTU specific protocol. In an aspect of dbc field, the value represents accumulated number of data blocks included the packet. This is against IEC 61883-1, because according to the specification this value should be the number of data blocks already transferred. In ALSA IEC 61883-1/6 engine, this quirk is already supported by CIP_DBC_IS_END_EVENT flag, because Echo Audio Fireworks has. Each data block includes SPH as its first quadlet field, to represent its presentation time stamp. Actual value of SPH is compliant to IEC 61883-1; lower 25 bits of 32 bits width consists of 13 bits cycle count and 12 bits cycle offset. The rest of each data block consists of 24 bit chunks. All of PCM samples, MIDI messages, status and control messages are transferred by the chunks. This is similar to '24-bit * 4 Audio Pack' in IEC 61883-6. The position of each kind of data depends on generations of each model. The number of whole chunks in a data block is a multiple of 4, to consists of quadlet-aligned packets. This commit adds data block processing layer specific for the MOTU protocol. The remarkable point is the way to generate SPH header. Time stamps for each data blocks are generated by below calculation: * Using pre-computed table for the number of ticks per event * 44,1kHz: (557 + 123/441) * 48.0kHz: (512 + 0/441) * 88.2kHz: (278 + 282/441) * 96.0kHz: (256 + 0/441) * 176.4kHz: (139 + 141/441) * 192.0kHz: (128 + 0/441) * Accumulate the ticks and set the value to SPH for every events. * This way makes sense only for blocking transmission because this mode transfers fixed number or none of events. This calculation assumes that each data block has a PCM frame which is sampled according to event timing clock. Current packet streaming layer has the same assumption. Although this sequence works fine for MOTU FireWire series at sampling transmission frequency based on 48.0kHz, it is not enough at the frequency based on 44.1kHz. The units generate choppy noise every few seconds. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2017-03-22 12:30:18 +00:00
dst = (void *)runtime->dma_area +
frames_to_bytes(runtime, pcm_buffer_pointer);
remaining_frames = runtime->buffer_size - pcm_buffer_pointer;
ALSA: firewire-motu: add MOTU specific protocol layer MOTU FireWire series uses blocking transmission for AMDTP packet streaming. They transmit/receive 8,000 packets per second, to handle the same number of data blocks as current sampling transmission frequency. Thus, IEC 61883-1/6 packet streaming engine of ALSA firewire stack is available for them. However, the sequence of packet and data blocks includes some quirks. Below sample is a sequence of CIP headers of packets received by 828mk2, at 44.1kHz of sampling transmission frequency. quads CIP1 CIP2 488 0x020F04E8 0x8222FFFF 8 0x020F04F8 0x8222FFFF 488 0x020F0400 0x8222FFFF 488 0x020F0408 0x8222FFFF 8 0x020F04E8 0x8222FFFF 488 0x020F04F0 0x8222FFFF 488 0x020F04F8 0x8222FFFF The SID (source node ID), DBS (data block size), SPH (source packet header), FMT (format ID), FDF (format dependent field) and SYT (time stamp) fields are in IEC 61883-1. Especially, FMT is 0x02, FDF is 0x22 and SYT is 0xffff to define MOTU specific protocol. In an aspect of dbc field, the value represents accumulated number of data blocks included the packet. This is against IEC 61883-1, because according to the specification this value should be the number of data blocks already transferred. In ALSA IEC 61883-1/6 engine, this quirk is already supported by CIP_DBC_IS_END_EVENT flag, because Echo Audio Fireworks has. Each data block includes SPH as its first quadlet field, to represent its presentation time stamp. Actual value of SPH is compliant to IEC 61883-1; lower 25 bits of 32 bits width consists of 13 bits cycle count and 12 bits cycle offset. The rest of each data block consists of 24 bit chunks. All of PCM samples, MIDI messages, status and control messages are transferred by the chunks. This is similar to '24-bit * 4 Audio Pack' in IEC 61883-6. The position of each kind of data depends on generations of each model. The number of whole chunks in a data block is a multiple of 4, to consists of quadlet-aligned packets. This commit adds data block processing layer specific for the MOTU protocol. The remarkable point is the way to generate SPH header. Time stamps for each data blocks are generated by below calculation: * Using pre-computed table for the number of ticks per event * 44,1kHz: (557 + 123/441) * 48.0kHz: (512 + 0/441) * 88.2kHz: (278 + 282/441) * 96.0kHz: (256 + 0/441) * 176.4kHz: (139 + 141/441) * 192.0kHz: (128 + 0/441) * Accumulate the ticks and set the value to SPH for every events. * This way makes sense only for blocking transmission because this mode transfers fixed number or none of events. This calculation assumes that each data block has a PCM frame which is sampled according to event timing clock. Current packet streaming layer has the same assumption. Although this sequence works fine for MOTU FireWire series at sampling transmission frequency based on 48.0kHz, it is not enough at the frequency based on 44.1kHz. The units generate choppy noise every few seconds. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2017-03-22 12:30:18 +00:00
for (i = 0; i < data_blocks; ++i) {
byte = (u8 *)buffer + p->pcm_byte_offset;
for (c = 0; c < channels; ++c) {
*dst = (byte[0] << 24) |
(byte[1] << 16) |
(byte[2] << 8);
ALSA: firewire-motu: add MOTU specific protocol layer MOTU FireWire series uses blocking transmission for AMDTP packet streaming. They transmit/receive 8,000 packets per second, to handle the same number of data blocks as current sampling transmission frequency. Thus, IEC 61883-1/6 packet streaming engine of ALSA firewire stack is available for them. However, the sequence of packet and data blocks includes some quirks. Below sample is a sequence of CIP headers of packets received by 828mk2, at 44.1kHz of sampling transmission frequency. quads CIP1 CIP2 488 0x020F04E8 0x8222FFFF 8 0x020F04F8 0x8222FFFF 488 0x020F0400 0x8222FFFF 488 0x020F0408 0x8222FFFF 8 0x020F04E8 0x8222FFFF 488 0x020F04F0 0x8222FFFF 488 0x020F04F8 0x8222FFFF The SID (source node ID), DBS (data block size), SPH (source packet header), FMT (format ID), FDF (format dependent field) and SYT (time stamp) fields are in IEC 61883-1. Especially, FMT is 0x02, FDF is 0x22 and SYT is 0xffff to define MOTU specific protocol. In an aspect of dbc field, the value represents accumulated number of data blocks included the packet. This is against IEC 61883-1, because according to the specification this value should be the number of data blocks already transferred. In ALSA IEC 61883-1/6 engine, this quirk is already supported by CIP_DBC_IS_END_EVENT flag, because Echo Audio Fireworks has. Each data block includes SPH as its first quadlet field, to represent its presentation time stamp. Actual value of SPH is compliant to IEC 61883-1; lower 25 bits of 32 bits width consists of 13 bits cycle count and 12 bits cycle offset. The rest of each data block consists of 24 bit chunks. All of PCM samples, MIDI messages, status and control messages are transferred by the chunks. This is similar to '24-bit * 4 Audio Pack' in IEC 61883-6. The position of each kind of data depends on generations of each model. The number of whole chunks in a data block is a multiple of 4, to consists of quadlet-aligned packets. This commit adds data block processing layer specific for the MOTU protocol. The remarkable point is the way to generate SPH header. Time stamps for each data blocks are generated by below calculation: * Using pre-computed table for the number of ticks per event * 44,1kHz: (557 + 123/441) * 48.0kHz: (512 + 0/441) * 88.2kHz: (278 + 282/441) * 96.0kHz: (256 + 0/441) * 176.4kHz: (139 + 141/441) * 192.0kHz: (128 + 0/441) * Accumulate the ticks and set the value to SPH for every events. * This way makes sense only for blocking transmission because this mode transfers fixed number or none of events. This calculation assumes that each data block has a PCM frame which is sampled according to event timing clock. Current packet streaming layer has the same assumption. Although this sequence works fine for MOTU FireWire series at sampling transmission frequency based on 48.0kHz, it is not enough at the frequency based on 44.1kHz. The units generate choppy noise every few seconds. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2017-03-22 12:30:18 +00:00
byte += 3;
dst++;
}
buffer += s->data_block_quadlets;
if (--remaining_frames == 0)
dst = (void *)runtime->dma_area;
}
}
static void write_pcm_s32(struct amdtp_stream *s, struct snd_pcm_substream *pcm,
__be32 *buffer, unsigned int data_blocks,
unsigned int pcm_frames)
ALSA: firewire-motu: add MOTU specific protocol layer MOTU FireWire series uses blocking transmission for AMDTP packet streaming. They transmit/receive 8,000 packets per second, to handle the same number of data blocks as current sampling transmission frequency. Thus, IEC 61883-1/6 packet streaming engine of ALSA firewire stack is available for them. However, the sequence of packet and data blocks includes some quirks. Below sample is a sequence of CIP headers of packets received by 828mk2, at 44.1kHz of sampling transmission frequency. quads CIP1 CIP2 488 0x020F04E8 0x8222FFFF 8 0x020F04F8 0x8222FFFF 488 0x020F0400 0x8222FFFF 488 0x020F0408 0x8222FFFF 8 0x020F04E8 0x8222FFFF 488 0x020F04F0 0x8222FFFF 488 0x020F04F8 0x8222FFFF The SID (source node ID), DBS (data block size), SPH (source packet header), FMT (format ID), FDF (format dependent field) and SYT (time stamp) fields are in IEC 61883-1. Especially, FMT is 0x02, FDF is 0x22 and SYT is 0xffff to define MOTU specific protocol. In an aspect of dbc field, the value represents accumulated number of data blocks included the packet. This is against IEC 61883-1, because according to the specification this value should be the number of data blocks already transferred. In ALSA IEC 61883-1/6 engine, this quirk is already supported by CIP_DBC_IS_END_EVENT flag, because Echo Audio Fireworks has. Each data block includes SPH as its first quadlet field, to represent its presentation time stamp. Actual value of SPH is compliant to IEC 61883-1; lower 25 bits of 32 bits width consists of 13 bits cycle count and 12 bits cycle offset. The rest of each data block consists of 24 bit chunks. All of PCM samples, MIDI messages, status and control messages are transferred by the chunks. This is similar to '24-bit * 4 Audio Pack' in IEC 61883-6. The position of each kind of data depends on generations of each model. The number of whole chunks in a data block is a multiple of 4, to consists of quadlet-aligned packets. This commit adds data block processing layer specific for the MOTU protocol. The remarkable point is the way to generate SPH header. Time stamps for each data blocks are generated by below calculation: * Using pre-computed table for the number of ticks per event * 44,1kHz: (557 + 123/441) * 48.0kHz: (512 + 0/441) * 88.2kHz: (278 + 282/441) * 96.0kHz: (256 + 0/441) * 176.4kHz: (139 + 141/441) * 192.0kHz: (128 + 0/441) * Accumulate the ticks and set the value to SPH for every events. * This way makes sense only for blocking transmission because this mode transfers fixed number or none of events. This calculation assumes that each data block has a PCM frame which is sampled according to event timing clock. Current packet streaming layer has the same assumption. Although this sequence works fine for MOTU FireWire series at sampling transmission frequency based on 48.0kHz, it is not enough at the frequency based on 44.1kHz. The units generate choppy noise every few seconds. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2017-03-22 12:30:18 +00:00
{
struct amdtp_motu *p = s->protocol;
unsigned int channels = p->pcm_chunks;
struct snd_pcm_runtime *runtime = pcm->runtime;
unsigned int pcm_buffer_pointer;
int remaining_frames;
ALSA: firewire-motu: add MOTU specific protocol layer MOTU FireWire series uses blocking transmission for AMDTP packet streaming. They transmit/receive 8,000 packets per second, to handle the same number of data blocks as current sampling transmission frequency. Thus, IEC 61883-1/6 packet streaming engine of ALSA firewire stack is available for them. However, the sequence of packet and data blocks includes some quirks. Below sample is a sequence of CIP headers of packets received by 828mk2, at 44.1kHz of sampling transmission frequency. quads CIP1 CIP2 488 0x020F04E8 0x8222FFFF 8 0x020F04F8 0x8222FFFF 488 0x020F0400 0x8222FFFF 488 0x020F0408 0x8222FFFF 8 0x020F04E8 0x8222FFFF 488 0x020F04F0 0x8222FFFF 488 0x020F04F8 0x8222FFFF The SID (source node ID), DBS (data block size), SPH (source packet header), FMT (format ID), FDF (format dependent field) and SYT (time stamp) fields are in IEC 61883-1. Especially, FMT is 0x02, FDF is 0x22 and SYT is 0xffff to define MOTU specific protocol. In an aspect of dbc field, the value represents accumulated number of data blocks included the packet. This is against IEC 61883-1, because according to the specification this value should be the number of data blocks already transferred. In ALSA IEC 61883-1/6 engine, this quirk is already supported by CIP_DBC_IS_END_EVENT flag, because Echo Audio Fireworks has. Each data block includes SPH as its first quadlet field, to represent its presentation time stamp. Actual value of SPH is compliant to IEC 61883-1; lower 25 bits of 32 bits width consists of 13 bits cycle count and 12 bits cycle offset. The rest of each data block consists of 24 bit chunks. All of PCM samples, MIDI messages, status and control messages are transferred by the chunks. This is similar to '24-bit * 4 Audio Pack' in IEC 61883-6. The position of each kind of data depends on generations of each model. The number of whole chunks in a data block is a multiple of 4, to consists of quadlet-aligned packets. This commit adds data block processing layer specific for the MOTU protocol. The remarkable point is the way to generate SPH header. Time stamps for each data blocks are generated by below calculation: * Using pre-computed table for the number of ticks per event * 44,1kHz: (557 + 123/441) * 48.0kHz: (512 + 0/441) * 88.2kHz: (278 + 282/441) * 96.0kHz: (256 + 0/441) * 176.4kHz: (139 + 141/441) * 192.0kHz: (128 + 0/441) * Accumulate the ticks and set the value to SPH for every events. * This way makes sense only for blocking transmission because this mode transfers fixed number or none of events. This calculation assumes that each data block has a PCM frame which is sampled according to event timing clock. Current packet streaming layer has the same assumption. Although this sequence works fine for MOTU FireWire series at sampling transmission frequency based on 48.0kHz, it is not enough at the frequency based on 44.1kHz. The units generate choppy noise every few seconds. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2017-03-22 12:30:18 +00:00
u8 *byte;
const u32 *src;
int i, c;
pcm_buffer_pointer = s->pcm_buffer_pointer + pcm_frames;
pcm_buffer_pointer %= runtime->buffer_size;
ALSA: firewire-motu: add MOTU specific protocol layer MOTU FireWire series uses blocking transmission for AMDTP packet streaming. They transmit/receive 8,000 packets per second, to handle the same number of data blocks as current sampling transmission frequency. Thus, IEC 61883-1/6 packet streaming engine of ALSA firewire stack is available for them. However, the sequence of packet and data blocks includes some quirks. Below sample is a sequence of CIP headers of packets received by 828mk2, at 44.1kHz of sampling transmission frequency. quads CIP1 CIP2 488 0x020F04E8 0x8222FFFF 8 0x020F04F8 0x8222FFFF 488 0x020F0400 0x8222FFFF 488 0x020F0408 0x8222FFFF 8 0x020F04E8 0x8222FFFF 488 0x020F04F0 0x8222FFFF 488 0x020F04F8 0x8222FFFF The SID (source node ID), DBS (data block size), SPH (source packet header), FMT (format ID), FDF (format dependent field) and SYT (time stamp) fields are in IEC 61883-1. Especially, FMT is 0x02, FDF is 0x22 and SYT is 0xffff to define MOTU specific protocol. In an aspect of dbc field, the value represents accumulated number of data blocks included the packet. This is against IEC 61883-1, because according to the specification this value should be the number of data blocks already transferred. In ALSA IEC 61883-1/6 engine, this quirk is already supported by CIP_DBC_IS_END_EVENT flag, because Echo Audio Fireworks has. Each data block includes SPH as its first quadlet field, to represent its presentation time stamp. Actual value of SPH is compliant to IEC 61883-1; lower 25 bits of 32 bits width consists of 13 bits cycle count and 12 bits cycle offset. The rest of each data block consists of 24 bit chunks. All of PCM samples, MIDI messages, status and control messages are transferred by the chunks. This is similar to '24-bit * 4 Audio Pack' in IEC 61883-6. The position of each kind of data depends on generations of each model. The number of whole chunks in a data block is a multiple of 4, to consists of quadlet-aligned packets. This commit adds data block processing layer specific for the MOTU protocol. The remarkable point is the way to generate SPH header. Time stamps for each data blocks are generated by below calculation: * Using pre-computed table for the number of ticks per event * 44,1kHz: (557 + 123/441) * 48.0kHz: (512 + 0/441) * 88.2kHz: (278 + 282/441) * 96.0kHz: (256 + 0/441) * 176.4kHz: (139 + 141/441) * 192.0kHz: (128 + 0/441) * Accumulate the ticks and set the value to SPH for every events. * This way makes sense only for blocking transmission because this mode transfers fixed number or none of events. This calculation assumes that each data block has a PCM frame which is sampled according to event timing clock. Current packet streaming layer has the same assumption. Although this sequence works fine for MOTU FireWire series at sampling transmission frequency based on 48.0kHz, it is not enough at the frequency based on 44.1kHz. The units generate choppy noise every few seconds. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2017-03-22 12:30:18 +00:00
src = (void *)runtime->dma_area +
frames_to_bytes(runtime, pcm_buffer_pointer);
remaining_frames = runtime->buffer_size - pcm_buffer_pointer;
ALSA: firewire-motu: add MOTU specific protocol layer MOTU FireWire series uses blocking transmission for AMDTP packet streaming. They transmit/receive 8,000 packets per second, to handle the same number of data blocks as current sampling transmission frequency. Thus, IEC 61883-1/6 packet streaming engine of ALSA firewire stack is available for them. However, the sequence of packet and data blocks includes some quirks. Below sample is a sequence of CIP headers of packets received by 828mk2, at 44.1kHz of sampling transmission frequency. quads CIP1 CIP2 488 0x020F04E8 0x8222FFFF 8 0x020F04F8 0x8222FFFF 488 0x020F0400 0x8222FFFF 488 0x020F0408 0x8222FFFF 8 0x020F04E8 0x8222FFFF 488 0x020F04F0 0x8222FFFF 488 0x020F04F8 0x8222FFFF The SID (source node ID), DBS (data block size), SPH (source packet header), FMT (format ID), FDF (format dependent field) and SYT (time stamp) fields are in IEC 61883-1. Especially, FMT is 0x02, FDF is 0x22 and SYT is 0xffff to define MOTU specific protocol. In an aspect of dbc field, the value represents accumulated number of data blocks included the packet. This is against IEC 61883-1, because according to the specification this value should be the number of data blocks already transferred. In ALSA IEC 61883-1/6 engine, this quirk is already supported by CIP_DBC_IS_END_EVENT flag, because Echo Audio Fireworks has. Each data block includes SPH as its first quadlet field, to represent its presentation time stamp. Actual value of SPH is compliant to IEC 61883-1; lower 25 bits of 32 bits width consists of 13 bits cycle count and 12 bits cycle offset. The rest of each data block consists of 24 bit chunks. All of PCM samples, MIDI messages, status and control messages are transferred by the chunks. This is similar to '24-bit * 4 Audio Pack' in IEC 61883-6. The position of each kind of data depends on generations of each model. The number of whole chunks in a data block is a multiple of 4, to consists of quadlet-aligned packets. This commit adds data block processing layer specific for the MOTU protocol. The remarkable point is the way to generate SPH header. Time stamps for each data blocks are generated by below calculation: * Using pre-computed table for the number of ticks per event * 44,1kHz: (557 + 123/441) * 48.0kHz: (512 + 0/441) * 88.2kHz: (278 + 282/441) * 96.0kHz: (256 + 0/441) * 176.4kHz: (139 + 141/441) * 192.0kHz: (128 + 0/441) * Accumulate the ticks and set the value to SPH for every events. * This way makes sense only for blocking transmission because this mode transfers fixed number or none of events. This calculation assumes that each data block has a PCM frame which is sampled according to event timing clock. Current packet streaming layer has the same assumption. Although this sequence works fine for MOTU FireWire series at sampling transmission frequency based on 48.0kHz, it is not enough at the frequency based on 44.1kHz. The units generate choppy noise every few seconds. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2017-03-22 12:30:18 +00:00
for (i = 0; i < data_blocks; ++i) {
byte = (u8 *)buffer + p->pcm_byte_offset;
for (c = 0; c < channels; ++c) {
byte[0] = (*src >> 24) & 0xff;
byte[1] = (*src >> 16) & 0xff;
byte[2] = (*src >> 8) & 0xff;
byte += 3;
src++;
}
buffer += s->data_block_quadlets;
if (--remaining_frames == 0)
src = (void *)runtime->dma_area;
}
}
static void write_pcm_silence(struct amdtp_stream *s, __be32 *buffer,
unsigned int data_blocks)
{
struct amdtp_motu *p = s->protocol;
unsigned int channels, i, c;
u8 *byte;
channels = p->pcm_chunks;
for (i = 0; i < data_blocks; ++i) {
byte = (u8 *)buffer + p->pcm_byte_offset;
for (c = 0; c < channels; ++c) {
byte[0] = 0;
byte[1] = 0;
byte[2] = 0;
byte += 3;
}
buffer += s->data_block_quadlets;
}
}
int amdtp_motu_add_pcm_hw_constraints(struct amdtp_stream *s,
struct snd_pcm_runtime *runtime)
{
int err;
/* TODO: how to set an constraint for exactly 24bit PCM sample? */
err = snd_pcm_hw_constraint_msbits(runtime, 0, 32, 24);
if (err < 0)
return err;
return amdtp_stream_add_pcm_hw_constraints(s, runtime);
}
void amdtp_motu_midi_trigger(struct amdtp_stream *s, unsigned int port,
struct snd_rawmidi_substream *midi)
{
struct amdtp_motu *p = s->protocol;
if (port < p->midi_ports)
WRITE_ONCE(p->midi, midi);
}
static void write_midi_messages(struct amdtp_stream *s, __be32 *buffer,
unsigned int data_blocks)
{
struct amdtp_motu *p = s->protocol;
struct snd_rawmidi_substream *midi = READ_ONCE(p->midi);
u8 *b;
int i;
for (i = 0; i < data_blocks; i++) {
b = (u8 *)buffer;
if (midi && p->midi_db_count == 0 &&
snd_rawmidi_transmit(midi, b + p->midi_byte_offset, 1) == 1) {
b[p->midi_flag_offset] = 0x01;
} else {
b[p->midi_byte_offset] = 0x00;
b[p->midi_flag_offset] = 0x00;
}
buffer += s->data_block_quadlets;
if (--p->midi_db_count < 0)
p->midi_db_count = p->midi_db_interval;
}
}
static void read_midi_messages(struct amdtp_stream *s, __be32 *buffer,
unsigned int data_blocks)
{
struct amdtp_motu *p = s->protocol;
struct snd_rawmidi_substream *midi;
u8 *b;
int i;
for (i = 0; i < data_blocks; i++) {
b = (u8 *)buffer;
midi = READ_ONCE(p->midi);
if (midi && (b[p->midi_flag_offset] & 0x01))
snd_rawmidi_receive(midi, b + p->midi_byte_offset, 1);
buffer += s->data_block_quadlets;
}
}
/* For tracepoints. */
static void __maybe_unused copy_sph(u32 *frames, __be32 *buffer,
unsigned int data_blocks,
unsigned int data_block_quadlets)
{
unsigned int i;
for (i = 0; i < data_blocks; ++i) {
*frames = be32_to_cpu(*buffer);
buffer += data_block_quadlets;
frames++;
}
}
/* For tracepoints. */
static void __maybe_unused copy_message(u64 *frames, __be32 *buffer,
unsigned int data_blocks,
unsigned int data_block_quadlets)
{
unsigned int i;
/* This is just for v2/v3 protocol. */
for (i = 0; i < data_blocks; ++i) {
*frames = be32_to_cpu(buffer[1]);
*frames <<= 16;
*frames |= be32_to_cpu(buffer[2]) >> 16;
++frames;
buffer += data_block_quadlets;
}
}
static void probe_tracepoints_events(struct amdtp_stream *s,
const struct pkt_desc *descs,
unsigned int packets)
{
int i;
for (i = 0; i < packets; ++i) {
const struct pkt_desc *desc = descs + i;
__be32 *buf = desc->ctx_payload;
unsigned int data_blocks = desc->data_blocks;
trace_data_block_sph(s, data_blocks, buf);
trace_data_block_message(s, data_blocks, buf);
}
}
static void cache_event_offsets(struct amdtp_motu_cache *cache, const __be32 *buf,
unsigned int data_blocks, unsigned int data_block_quadlets)
{
unsigned int *event_offsets = cache->event_offsets;
const unsigned int cache_size = cache->size;
unsigned int cache_tail = cache->tail;
unsigned int base_tick = cache->tx_cycle_count * TICKS_PER_CYCLE;
int i;
for (i = 0; i < data_blocks; ++i) {
u32 sph = be32_to_cpu(*buf);
unsigned int tick;
tick = ((sph & CIP_SPH_CYCLE_MASK) >> CIP_SPH_CYCLE_SHIFT) * TICKS_PER_CYCLE +
(sph & CIP_SPH_OFFSET_MASK);
if (tick < base_tick)
tick += TICKS_PER_SECOND;
event_offsets[cache_tail] = tick - base_tick;
cache_tail = (cache_tail + 1) % cache_size;
buf += data_block_quadlets;
}
cache->tail = cache_tail;
cache->tx_cycle_count = (cache->tx_cycle_count + 1) % CYCLES_PER_SECOND;
}
static unsigned int process_ir_ctx_payloads(struct amdtp_stream *s,
const struct pkt_desc *descs,
unsigned int packets,
struct snd_pcm_substream *pcm)
ALSA: firewire-motu: add MOTU specific protocol layer MOTU FireWire series uses blocking transmission for AMDTP packet streaming. They transmit/receive 8,000 packets per second, to handle the same number of data blocks as current sampling transmission frequency. Thus, IEC 61883-1/6 packet streaming engine of ALSA firewire stack is available for them. However, the sequence of packet and data blocks includes some quirks. Below sample is a sequence of CIP headers of packets received by 828mk2, at 44.1kHz of sampling transmission frequency. quads CIP1 CIP2 488 0x020F04E8 0x8222FFFF 8 0x020F04F8 0x8222FFFF 488 0x020F0400 0x8222FFFF 488 0x020F0408 0x8222FFFF 8 0x020F04E8 0x8222FFFF 488 0x020F04F0 0x8222FFFF 488 0x020F04F8 0x8222FFFF The SID (source node ID), DBS (data block size), SPH (source packet header), FMT (format ID), FDF (format dependent field) and SYT (time stamp) fields are in IEC 61883-1. Especially, FMT is 0x02, FDF is 0x22 and SYT is 0xffff to define MOTU specific protocol. In an aspect of dbc field, the value represents accumulated number of data blocks included the packet. This is against IEC 61883-1, because according to the specification this value should be the number of data blocks already transferred. In ALSA IEC 61883-1/6 engine, this quirk is already supported by CIP_DBC_IS_END_EVENT flag, because Echo Audio Fireworks has. Each data block includes SPH as its first quadlet field, to represent its presentation time stamp. Actual value of SPH is compliant to IEC 61883-1; lower 25 bits of 32 bits width consists of 13 bits cycle count and 12 bits cycle offset. The rest of each data block consists of 24 bit chunks. All of PCM samples, MIDI messages, status and control messages are transferred by the chunks. This is similar to '24-bit * 4 Audio Pack' in IEC 61883-6. The position of each kind of data depends on generations of each model. The number of whole chunks in a data block is a multiple of 4, to consists of quadlet-aligned packets. This commit adds data block processing layer specific for the MOTU protocol. The remarkable point is the way to generate SPH header. Time stamps for each data blocks are generated by below calculation: * Using pre-computed table for the number of ticks per event * 44,1kHz: (557 + 123/441) * 48.0kHz: (512 + 0/441) * 88.2kHz: (278 + 282/441) * 96.0kHz: (256 + 0/441) * 176.4kHz: (139 + 141/441) * 192.0kHz: (128 + 0/441) * Accumulate the ticks and set the value to SPH for every events. * This way makes sense only for blocking transmission because this mode transfers fixed number or none of events. This calculation assumes that each data block has a PCM frame which is sampled according to event timing clock. Current packet streaming layer has the same assumption. Although this sequence works fine for MOTU FireWire series at sampling transmission frequency based on 48.0kHz, it is not enough at the frequency based on 44.1kHz. The units generate choppy noise every few seconds. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2017-03-22 12:30:18 +00:00
{
struct snd_motu *motu = container_of(s, struct snd_motu, tx_stream);
struct amdtp_motu *p = s->protocol;
unsigned int pcm_frames = 0;
int i;
if (p->cache->tx_cycle_count == UINT_MAX)
p->cache->tx_cycle_count = (s->domain->processing_cycle.tx_start % CYCLES_PER_SECOND);
// For data block processing.
for (i = 0; i < packets; ++i) {
const struct pkt_desc *desc = descs + i;
__be32 *buf = desc->ctx_payload;
unsigned int data_blocks = desc->data_blocks;
ALSA: firewire-motu: add MOTU specific protocol layer MOTU FireWire series uses blocking transmission for AMDTP packet streaming. They transmit/receive 8,000 packets per second, to handle the same number of data blocks as current sampling transmission frequency. Thus, IEC 61883-1/6 packet streaming engine of ALSA firewire stack is available for them. However, the sequence of packet and data blocks includes some quirks. Below sample is a sequence of CIP headers of packets received by 828mk2, at 44.1kHz of sampling transmission frequency. quads CIP1 CIP2 488 0x020F04E8 0x8222FFFF 8 0x020F04F8 0x8222FFFF 488 0x020F0400 0x8222FFFF 488 0x020F0408 0x8222FFFF 8 0x020F04E8 0x8222FFFF 488 0x020F04F0 0x8222FFFF 488 0x020F04F8 0x8222FFFF The SID (source node ID), DBS (data block size), SPH (source packet header), FMT (format ID), FDF (format dependent field) and SYT (time stamp) fields are in IEC 61883-1. Especially, FMT is 0x02, FDF is 0x22 and SYT is 0xffff to define MOTU specific protocol. In an aspect of dbc field, the value represents accumulated number of data blocks included the packet. This is against IEC 61883-1, because according to the specification this value should be the number of data blocks already transferred. In ALSA IEC 61883-1/6 engine, this quirk is already supported by CIP_DBC_IS_END_EVENT flag, because Echo Audio Fireworks has. Each data block includes SPH as its first quadlet field, to represent its presentation time stamp. Actual value of SPH is compliant to IEC 61883-1; lower 25 bits of 32 bits width consists of 13 bits cycle count and 12 bits cycle offset. The rest of each data block consists of 24 bit chunks. All of PCM samples, MIDI messages, status and control messages are transferred by the chunks. This is similar to '24-bit * 4 Audio Pack' in IEC 61883-6. The position of each kind of data depends on generations of each model. The number of whole chunks in a data block is a multiple of 4, to consists of quadlet-aligned packets. This commit adds data block processing layer specific for the MOTU protocol. The remarkable point is the way to generate SPH header. Time stamps for each data blocks are generated by below calculation: * Using pre-computed table for the number of ticks per event * 44,1kHz: (557 + 123/441) * 48.0kHz: (512 + 0/441) * 88.2kHz: (278 + 282/441) * 96.0kHz: (256 + 0/441) * 176.4kHz: (139 + 141/441) * 192.0kHz: (128 + 0/441) * Accumulate the ticks and set the value to SPH for every events. * This way makes sense only for blocking transmission because this mode transfers fixed number or none of events. This calculation assumes that each data block has a PCM frame which is sampled according to event timing clock. Current packet streaming layer has the same assumption. Although this sequence works fine for MOTU FireWire series at sampling transmission frequency based on 48.0kHz, it is not enough at the frequency based on 44.1kHz. The units generate choppy noise every few seconds. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2017-03-22 12:30:18 +00:00
cache_event_offsets(p->cache, buf, data_blocks, s->data_block_quadlets);
if (pcm) {
read_pcm_s32(s, pcm, buf, data_blocks, pcm_frames);
pcm_frames += data_blocks;
}
if (p->midi_ports)
read_midi_messages(s, buf, data_blocks);
}
ALSA: firewire-motu: add MOTU specific protocol layer MOTU FireWire series uses blocking transmission for AMDTP packet streaming. They transmit/receive 8,000 packets per second, to handle the same number of data blocks as current sampling transmission frequency. Thus, IEC 61883-1/6 packet streaming engine of ALSA firewire stack is available for them. However, the sequence of packet and data blocks includes some quirks. Below sample is a sequence of CIP headers of packets received by 828mk2, at 44.1kHz of sampling transmission frequency. quads CIP1 CIP2 488 0x020F04E8 0x8222FFFF 8 0x020F04F8 0x8222FFFF 488 0x020F0400 0x8222FFFF 488 0x020F0408 0x8222FFFF 8 0x020F04E8 0x8222FFFF 488 0x020F04F0 0x8222FFFF 488 0x020F04F8 0x8222FFFF The SID (source node ID), DBS (data block size), SPH (source packet header), FMT (format ID), FDF (format dependent field) and SYT (time stamp) fields are in IEC 61883-1. Especially, FMT is 0x02, FDF is 0x22 and SYT is 0xffff to define MOTU specific protocol. In an aspect of dbc field, the value represents accumulated number of data blocks included the packet. This is against IEC 61883-1, because according to the specification this value should be the number of data blocks already transferred. In ALSA IEC 61883-1/6 engine, this quirk is already supported by CIP_DBC_IS_END_EVENT flag, because Echo Audio Fireworks has. Each data block includes SPH as its first quadlet field, to represent its presentation time stamp. Actual value of SPH is compliant to IEC 61883-1; lower 25 bits of 32 bits width consists of 13 bits cycle count and 12 bits cycle offset. The rest of each data block consists of 24 bit chunks. All of PCM samples, MIDI messages, status and control messages are transferred by the chunks. This is similar to '24-bit * 4 Audio Pack' in IEC 61883-6. The position of each kind of data depends on generations of each model. The number of whole chunks in a data block is a multiple of 4, to consists of quadlet-aligned packets. This commit adds data block processing layer specific for the MOTU protocol. The remarkable point is the way to generate SPH header. Time stamps for each data blocks are generated by below calculation: * Using pre-computed table for the number of ticks per event * 44,1kHz: (557 + 123/441) * 48.0kHz: (512 + 0/441) * 88.2kHz: (278 + 282/441) * 96.0kHz: (256 + 0/441) * 176.4kHz: (139 + 141/441) * 192.0kHz: (128 + 0/441) * Accumulate the ticks and set the value to SPH for every events. * This way makes sense only for blocking transmission because this mode transfers fixed number or none of events. This calculation assumes that each data block has a PCM frame which is sampled according to event timing clock. Current packet streaming layer has the same assumption. Although this sequence works fine for MOTU FireWire series at sampling transmission frequency based on 48.0kHz, it is not enough at the frequency based on 44.1kHz. The units generate choppy noise every few seconds. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2017-03-22 12:30:18 +00:00
if (motu->spec->flags & SND_MOTU_SPEC_REGISTER_DSP) {
snd_motu_register_dsp_message_parser_parse(motu, descs, packets,
s->data_block_quadlets);
} else if (motu->spec->flags & SND_MOTU_SPEC_COMMAND_DSP) {
snd_motu_command_dsp_message_parser_parse(motu, descs, packets,
s->data_block_quadlets);
}
// For tracepoints.
if (trace_data_block_sph_enabled() ||
trace_data_block_message_enabled())
probe_tracepoints_events(s, descs, packets);
return pcm_frames;
ALSA: firewire-motu: add MOTU specific protocol layer MOTU FireWire series uses blocking transmission for AMDTP packet streaming. They transmit/receive 8,000 packets per second, to handle the same number of data blocks as current sampling transmission frequency. Thus, IEC 61883-1/6 packet streaming engine of ALSA firewire stack is available for them. However, the sequence of packet and data blocks includes some quirks. Below sample is a sequence of CIP headers of packets received by 828mk2, at 44.1kHz of sampling transmission frequency. quads CIP1 CIP2 488 0x020F04E8 0x8222FFFF 8 0x020F04F8 0x8222FFFF 488 0x020F0400 0x8222FFFF 488 0x020F0408 0x8222FFFF 8 0x020F04E8 0x8222FFFF 488 0x020F04F0 0x8222FFFF 488 0x020F04F8 0x8222FFFF The SID (source node ID), DBS (data block size), SPH (source packet header), FMT (format ID), FDF (format dependent field) and SYT (time stamp) fields are in IEC 61883-1. Especially, FMT is 0x02, FDF is 0x22 and SYT is 0xffff to define MOTU specific protocol. In an aspect of dbc field, the value represents accumulated number of data blocks included the packet. This is against IEC 61883-1, because according to the specification this value should be the number of data blocks already transferred. In ALSA IEC 61883-1/6 engine, this quirk is already supported by CIP_DBC_IS_END_EVENT flag, because Echo Audio Fireworks has. Each data block includes SPH as its first quadlet field, to represent its presentation time stamp. Actual value of SPH is compliant to IEC 61883-1; lower 25 bits of 32 bits width consists of 13 bits cycle count and 12 bits cycle offset. The rest of each data block consists of 24 bit chunks. All of PCM samples, MIDI messages, status and control messages are transferred by the chunks. This is similar to '24-bit * 4 Audio Pack' in IEC 61883-6. The position of each kind of data depends on generations of each model. The number of whole chunks in a data block is a multiple of 4, to consists of quadlet-aligned packets. This commit adds data block processing layer specific for the MOTU protocol. The remarkable point is the way to generate SPH header. Time stamps for each data blocks are generated by below calculation: * Using pre-computed table for the number of ticks per event * 44,1kHz: (557 + 123/441) * 48.0kHz: (512 + 0/441) * 88.2kHz: (278 + 282/441) * 96.0kHz: (256 + 0/441) * 176.4kHz: (139 + 141/441) * 192.0kHz: (128 + 0/441) * Accumulate the ticks and set the value to SPH for every events. * This way makes sense only for blocking transmission because this mode transfers fixed number or none of events. This calculation assumes that each data block has a PCM frame which is sampled according to event timing clock. Current packet streaming layer has the same assumption. Although this sequence works fine for MOTU FireWire series at sampling transmission frequency based on 48.0kHz, it is not enough at the frequency based on 44.1kHz. The units generate choppy noise every few seconds. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2017-03-22 12:30:18 +00:00
}
static void write_sph(struct amdtp_motu_cache *cache, __be32 *buffer, unsigned int data_blocks,
unsigned int data_block_quadlets)
ALSA: firewire-motu: add MOTU specific protocol layer MOTU FireWire series uses blocking transmission for AMDTP packet streaming. They transmit/receive 8,000 packets per second, to handle the same number of data blocks as current sampling transmission frequency. Thus, IEC 61883-1/6 packet streaming engine of ALSA firewire stack is available for them. However, the sequence of packet and data blocks includes some quirks. Below sample is a sequence of CIP headers of packets received by 828mk2, at 44.1kHz of sampling transmission frequency. quads CIP1 CIP2 488 0x020F04E8 0x8222FFFF 8 0x020F04F8 0x8222FFFF 488 0x020F0400 0x8222FFFF 488 0x020F0408 0x8222FFFF 8 0x020F04E8 0x8222FFFF 488 0x020F04F0 0x8222FFFF 488 0x020F04F8 0x8222FFFF The SID (source node ID), DBS (data block size), SPH (source packet header), FMT (format ID), FDF (format dependent field) and SYT (time stamp) fields are in IEC 61883-1. Especially, FMT is 0x02, FDF is 0x22 and SYT is 0xffff to define MOTU specific protocol. In an aspect of dbc field, the value represents accumulated number of data blocks included the packet. This is against IEC 61883-1, because according to the specification this value should be the number of data blocks already transferred. In ALSA IEC 61883-1/6 engine, this quirk is already supported by CIP_DBC_IS_END_EVENT flag, because Echo Audio Fireworks has. Each data block includes SPH as its first quadlet field, to represent its presentation time stamp. Actual value of SPH is compliant to IEC 61883-1; lower 25 bits of 32 bits width consists of 13 bits cycle count and 12 bits cycle offset. The rest of each data block consists of 24 bit chunks. All of PCM samples, MIDI messages, status and control messages are transferred by the chunks. This is similar to '24-bit * 4 Audio Pack' in IEC 61883-6. The position of each kind of data depends on generations of each model. The number of whole chunks in a data block is a multiple of 4, to consists of quadlet-aligned packets. This commit adds data block processing layer specific for the MOTU protocol. The remarkable point is the way to generate SPH header. Time stamps for each data blocks are generated by below calculation: * Using pre-computed table for the number of ticks per event * 44,1kHz: (557 + 123/441) * 48.0kHz: (512 + 0/441) * 88.2kHz: (278 + 282/441) * 96.0kHz: (256 + 0/441) * 176.4kHz: (139 + 141/441) * 192.0kHz: (128 + 0/441) * Accumulate the ticks and set the value to SPH for every events. * This way makes sense only for blocking transmission because this mode transfers fixed number or none of events. This calculation assumes that each data block has a PCM frame which is sampled according to event timing clock. Current packet streaming layer has the same assumption. Although this sequence works fine for MOTU FireWire series at sampling transmission frequency based on 48.0kHz, it is not enough at the frequency based on 44.1kHz. The units generate choppy noise every few seconds. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2017-03-22 12:30:18 +00:00
{
unsigned int *event_offsets = cache->event_offsets;
const unsigned int cache_size = cache->size;
unsigned int cache_head = cache->head;
unsigned int base_tick = cache->rx_cycle_count * TICKS_PER_CYCLE;
int i;
ALSA: firewire-motu: add MOTU specific protocol layer MOTU FireWire series uses blocking transmission for AMDTP packet streaming. They transmit/receive 8,000 packets per second, to handle the same number of data blocks as current sampling transmission frequency. Thus, IEC 61883-1/6 packet streaming engine of ALSA firewire stack is available for them. However, the sequence of packet and data blocks includes some quirks. Below sample is a sequence of CIP headers of packets received by 828mk2, at 44.1kHz of sampling transmission frequency. quads CIP1 CIP2 488 0x020F04E8 0x8222FFFF 8 0x020F04F8 0x8222FFFF 488 0x020F0400 0x8222FFFF 488 0x020F0408 0x8222FFFF 8 0x020F04E8 0x8222FFFF 488 0x020F04F0 0x8222FFFF 488 0x020F04F8 0x8222FFFF The SID (source node ID), DBS (data block size), SPH (source packet header), FMT (format ID), FDF (format dependent field) and SYT (time stamp) fields are in IEC 61883-1. Especially, FMT is 0x02, FDF is 0x22 and SYT is 0xffff to define MOTU specific protocol. In an aspect of dbc field, the value represents accumulated number of data blocks included the packet. This is against IEC 61883-1, because according to the specification this value should be the number of data blocks already transferred. In ALSA IEC 61883-1/6 engine, this quirk is already supported by CIP_DBC_IS_END_EVENT flag, because Echo Audio Fireworks has. Each data block includes SPH as its first quadlet field, to represent its presentation time stamp. Actual value of SPH is compliant to IEC 61883-1; lower 25 bits of 32 bits width consists of 13 bits cycle count and 12 bits cycle offset. The rest of each data block consists of 24 bit chunks. All of PCM samples, MIDI messages, status and control messages are transferred by the chunks. This is similar to '24-bit * 4 Audio Pack' in IEC 61883-6. The position of each kind of data depends on generations of each model. The number of whole chunks in a data block is a multiple of 4, to consists of quadlet-aligned packets. This commit adds data block processing layer specific for the MOTU protocol. The remarkable point is the way to generate SPH header. Time stamps for each data blocks are generated by below calculation: * Using pre-computed table for the number of ticks per event * 44,1kHz: (557 + 123/441) * 48.0kHz: (512 + 0/441) * 88.2kHz: (278 + 282/441) * 96.0kHz: (256 + 0/441) * 176.4kHz: (139 + 141/441) * 192.0kHz: (128 + 0/441) * Accumulate the ticks and set the value to SPH for every events. * This way makes sense only for blocking transmission because this mode transfers fixed number or none of events. This calculation assumes that each data block has a PCM frame which is sampled according to event timing clock. Current packet streaming layer has the same assumption. Although this sequence works fine for MOTU FireWire series at sampling transmission frequency based on 48.0kHz, it is not enough at the frequency based on 44.1kHz. The units generate choppy noise every few seconds. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2017-03-22 12:30:18 +00:00
for (i = 0; i < data_blocks; i++) {
unsigned int tick = (base_tick + event_offsets[cache_head]) % TICKS_PER_SECOND;
u32 sph = ((tick / TICKS_PER_CYCLE) << CIP_SPH_CYCLE_SHIFT) | (tick % TICKS_PER_CYCLE);
ALSA: firewire-motu: add MOTU specific protocol layer MOTU FireWire series uses blocking transmission for AMDTP packet streaming. They transmit/receive 8,000 packets per second, to handle the same number of data blocks as current sampling transmission frequency. Thus, IEC 61883-1/6 packet streaming engine of ALSA firewire stack is available for them. However, the sequence of packet and data blocks includes some quirks. Below sample is a sequence of CIP headers of packets received by 828mk2, at 44.1kHz of sampling transmission frequency. quads CIP1 CIP2 488 0x020F04E8 0x8222FFFF 8 0x020F04F8 0x8222FFFF 488 0x020F0400 0x8222FFFF 488 0x020F0408 0x8222FFFF 8 0x020F04E8 0x8222FFFF 488 0x020F04F0 0x8222FFFF 488 0x020F04F8 0x8222FFFF The SID (source node ID), DBS (data block size), SPH (source packet header), FMT (format ID), FDF (format dependent field) and SYT (time stamp) fields are in IEC 61883-1. Especially, FMT is 0x02, FDF is 0x22 and SYT is 0xffff to define MOTU specific protocol. In an aspect of dbc field, the value represents accumulated number of data blocks included the packet. This is against IEC 61883-1, because according to the specification this value should be the number of data blocks already transferred. In ALSA IEC 61883-1/6 engine, this quirk is already supported by CIP_DBC_IS_END_EVENT flag, because Echo Audio Fireworks has. Each data block includes SPH as its first quadlet field, to represent its presentation time stamp. Actual value of SPH is compliant to IEC 61883-1; lower 25 bits of 32 bits width consists of 13 bits cycle count and 12 bits cycle offset. The rest of each data block consists of 24 bit chunks. All of PCM samples, MIDI messages, status and control messages are transferred by the chunks. This is similar to '24-bit * 4 Audio Pack' in IEC 61883-6. The position of each kind of data depends on generations of each model. The number of whole chunks in a data block is a multiple of 4, to consists of quadlet-aligned packets. This commit adds data block processing layer specific for the MOTU protocol. The remarkable point is the way to generate SPH header. Time stamps for each data blocks are generated by below calculation: * Using pre-computed table for the number of ticks per event * 44,1kHz: (557 + 123/441) * 48.0kHz: (512 + 0/441) * 88.2kHz: (278 + 282/441) * 96.0kHz: (256 + 0/441) * 176.4kHz: (139 + 141/441) * 192.0kHz: (128 + 0/441) * Accumulate the ticks and set the value to SPH for every events. * This way makes sense only for blocking transmission because this mode transfers fixed number or none of events. This calculation assumes that each data block has a PCM frame which is sampled according to event timing clock. Current packet streaming layer has the same assumption. Although this sequence works fine for MOTU FireWire series at sampling transmission frequency based on 48.0kHz, it is not enough at the frequency based on 44.1kHz. The units generate choppy noise every few seconds. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2017-03-22 12:30:18 +00:00
*buffer = cpu_to_be32(sph);
cache_head = (cache_head + 1) % cache_size;
buffer += data_block_quadlets;
ALSA: firewire-motu: add MOTU specific protocol layer MOTU FireWire series uses blocking transmission for AMDTP packet streaming. They transmit/receive 8,000 packets per second, to handle the same number of data blocks as current sampling transmission frequency. Thus, IEC 61883-1/6 packet streaming engine of ALSA firewire stack is available for them. However, the sequence of packet and data blocks includes some quirks. Below sample is a sequence of CIP headers of packets received by 828mk2, at 44.1kHz of sampling transmission frequency. quads CIP1 CIP2 488 0x020F04E8 0x8222FFFF 8 0x020F04F8 0x8222FFFF 488 0x020F0400 0x8222FFFF 488 0x020F0408 0x8222FFFF 8 0x020F04E8 0x8222FFFF 488 0x020F04F0 0x8222FFFF 488 0x020F04F8 0x8222FFFF The SID (source node ID), DBS (data block size), SPH (source packet header), FMT (format ID), FDF (format dependent field) and SYT (time stamp) fields are in IEC 61883-1. Especially, FMT is 0x02, FDF is 0x22 and SYT is 0xffff to define MOTU specific protocol. In an aspect of dbc field, the value represents accumulated number of data blocks included the packet. This is against IEC 61883-1, because according to the specification this value should be the number of data blocks already transferred. In ALSA IEC 61883-1/6 engine, this quirk is already supported by CIP_DBC_IS_END_EVENT flag, because Echo Audio Fireworks has. Each data block includes SPH as its first quadlet field, to represent its presentation time stamp. Actual value of SPH is compliant to IEC 61883-1; lower 25 bits of 32 bits width consists of 13 bits cycle count and 12 bits cycle offset. The rest of each data block consists of 24 bit chunks. All of PCM samples, MIDI messages, status and control messages are transferred by the chunks. This is similar to '24-bit * 4 Audio Pack' in IEC 61883-6. The position of each kind of data depends on generations of each model. The number of whole chunks in a data block is a multiple of 4, to consists of quadlet-aligned packets. This commit adds data block processing layer specific for the MOTU protocol. The remarkable point is the way to generate SPH header. Time stamps for each data blocks are generated by below calculation: * Using pre-computed table for the number of ticks per event * 44,1kHz: (557 + 123/441) * 48.0kHz: (512 + 0/441) * 88.2kHz: (278 + 282/441) * 96.0kHz: (256 + 0/441) * 176.4kHz: (139 + 141/441) * 192.0kHz: (128 + 0/441) * Accumulate the ticks and set the value to SPH for every events. * This way makes sense only for blocking transmission because this mode transfers fixed number or none of events. This calculation assumes that each data block has a PCM frame which is sampled according to event timing clock. Current packet streaming layer has the same assumption. Although this sequence works fine for MOTU FireWire series at sampling transmission frequency based on 48.0kHz, it is not enough at the frequency based on 44.1kHz. The units generate choppy noise every few seconds. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2017-03-22 12:30:18 +00:00
}
cache->head = cache_head;
cache->rx_cycle_count = (cache->rx_cycle_count + 1) % CYCLES_PER_SECOND;
ALSA: firewire-motu: add MOTU specific protocol layer MOTU FireWire series uses blocking transmission for AMDTP packet streaming. They transmit/receive 8,000 packets per second, to handle the same number of data blocks as current sampling transmission frequency. Thus, IEC 61883-1/6 packet streaming engine of ALSA firewire stack is available for them. However, the sequence of packet and data blocks includes some quirks. Below sample is a sequence of CIP headers of packets received by 828mk2, at 44.1kHz of sampling transmission frequency. quads CIP1 CIP2 488 0x020F04E8 0x8222FFFF 8 0x020F04F8 0x8222FFFF 488 0x020F0400 0x8222FFFF 488 0x020F0408 0x8222FFFF 8 0x020F04E8 0x8222FFFF 488 0x020F04F0 0x8222FFFF 488 0x020F04F8 0x8222FFFF The SID (source node ID), DBS (data block size), SPH (source packet header), FMT (format ID), FDF (format dependent field) and SYT (time stamp) fields are in IEC 61883-1. Especially, FMT is 0x02, FDF is 0x22 and SYT is 0xffff to define MOTU specific protocol. In an aspect of dbc field, the value represents accumulated number of data blocks included the packet. This is against IEC 61883-1, because according to the specification this value should be the number of data blocks already transferred. In ALSA IEC 61883-1/6 engine, this quirk is already supported by CIP_DBC_IS_END_EVENT flag, because Echo Audio Fireworks has. Each data block includes SPH as its first quadlet field, to represent its presentation time stamp. Actual value of SPH is compliant to IEC 61883-1; lower 25 bits of 32 bits width consists of 13 bits cycle count and 12 bits cycle offset. The rest of each data block consists of 24 bit chunks. All of PCM samples, MIDI messages, status and control messages are transferred by the chunks. This is similar to '24-bit * 4 Audio Pack' in IEC 61883-6. The position of each kind of data depends on generations of each model. The number of whole chunks in a data block is a multiple of 4, to consists of quadlet-aligned packets. This commit adds data block processing layer specific for the MOTU protocol. The remarkable point is the way to generate SPH header. Time stamps for each data blocks are generated by below calculation: * Using pre-computed table for the number of ticks per event * 44,1kHz: (557 + 123/441) * 48.0kHz: (512 + 0/441) * 88.2kHz: (278 + 282/441) * 96.0kHz: (256 + 0/441) * 176.4kHz: (139 + 141/441) * 192.0kHz: (128 + 0/441) * Accumulate the ticks and set the value to SPH for every events. * This way makes sense only for blocking transmission because this mode transfers fixed number or none of events. This calculation assumes that each data block has a PCM frame which is sampled according to event timing clock. Current packet streaming layer has the same assumption. Although this sequence works fine for MOTU FireWire series at sampling transmission frequency based on 48.0kHz, it is not enough at the frequency based on 44.1kHz. The units generate choppy noise every few seconds. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2017-03-22 12:30:18 +00:00
}
static unsigned int process_it_ctx_payloads(struct amdtp_stream *s,
const struct pkt_desc *descs,
unsigned int packets,
struct snd_pcm_substream *pcm)
ALSA: firewire-motu: add MOTU specific protocol layer MOTU FireWire series uses blocking transmission for AMDTP packet streaming. They transmit/receive 8,000 packets per second, to handle the same number of data blocks as current sampling transmission frequency. Thus, IEC 61883-1/6 packet streaming engine of ALSA firewire stack is available for them. However, the sequence of packet and data blocks includes some quirks. Below sample is a sequence of CIP headers of packets received by 828mk2, at 44.1kHz of sampling transmission frequency. quads CIP1 CIP2 488 0x020F04E8 0x8222FFFF 8 0x020F04F8 0x8222FFFF 488 0x020F0400 0x8222FFFF 488 0x020F0408 0x8222FFFF 8 0x020F04E8 0x8222FFFF 488 0x020F04F0 0x8222FFFF 488 0x020F04F8 0x8222FFFF The SID (source node ID), DBS (data block size), SPH (source packet header), FMT (format ID), FDF (format dependent field) and SYT (time stamp) fields are in IEC 61883-1. Especially, FMT is 0x02, FDF is 0x22 and SYT is 0xffff to define MOTU specific protocol. In an aspect of dbc field, the value represents accumulated number of data blocks included the packet. This is against IEC 61883-1, because according to the specification this value should be the number of data blocks already transferred. In ALSA IEC 61883-1/6 engine, this quirk is already supported by CIP_DBC_IS_END_EVENT flag, because Echo Audio Fireworks has. Each data block includes SPH as its first quadlet field, to represent its presentation time stamp. Actual value of SPH is compliant to IEC 61883-1; lower 25 bits of 32 bits width consists of 13 bits cycle count and 12 bits cycle offset. The rest of each data block consists of 24 bit chunks. All of PCM samples, MIDI messages, status and control messages are transferred by the chunks. This is similar to '24-bit * 4 Audio Pack' in IEC 61883-6. The position of each kind of data depends on generations of each model. The number of whole chunks in a data block is a multiple of 4, to consists of quadlet-aligned packets. This commit adds data block processing layer specific for the MOTU protocol. The remarkable point is the way to generate SPH header. Time stamps for each data blocks are generated by below calculation: * Using pre-computed table for the number of ticks per event * 44,1kHz: (557 + 123/441) * 48.0kHz: (512 + 0/441) * 88.2kHz: (278 + 282/441) * 96.0kHz: (256 + 0/441) * 176.4kHz: (139 + 141/441) * 192.0kHz: (128 + 0/441) * Accumulate the ticks and set the value to SPH for every events. * This way makes sense only for blocking transmission because this mode transfers fixed number or none of events. This calculation assumes that each data block has a PCM frame which is sampled according to event timing clock. Current packet streaming layer has the same assumption. Although this sequence works fine for MOTU FireWire series at sampling transmission frequency based on 48.0kHz, it is not enough at the frequency based on 44.1kHz. The units generate choppy noise every few seconds. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2017-03-22 12:30:18 +00:00
{
struct amdtp_motu *p = s->protocol;
unsigned int pcm_frames = 0;
int i;
ALSA: firewire-motu: add MOTU specific protocol layer MOTU FireWire series uses blocking transmission for AMDTP packet streaming. They transmit/receive 8,000 packets per second, to handle the same number of data blocks as current sampling transmission frequency. Thus, IEC 61883-1/6 packet streaming engine of ALSA firewire stack is available for them. However, the sequence of packet and data blocks includes some quirks. Below sample is a sequence of CIP headers of packets received by 828mk2, at 44.1kHz of sampling transmission frequency. quads CIP1 CIP2 488 0x020F04E8 0x8222FFFF 8 0x020F04F8 0x8222FFFF 488 0x020F0400 0x8222FFFF 488 0x020F0408 0x8222FFFF 8 0x020F04E8 0x8222FFFF 488 0x020F04F0 0x8222FFFF 488 0x020F04F8 0x8222FFFF The SID (source node ID), DBS (data block size), SPH (source packet header), FMT (format ID), FDF (format dependent field) and SYT (time stamp) fields are in IEC 61883-1. Especially, FMT is 0x02, FDF is 0x22 and SYT is 0xffff to define MOTU specific protocol. In an aspect of dbc field, the value represents accumulated number of data blocks included the packet. This is against IEC 61883-1, because according to the specification this value should be the number of data blocks already transferred. In ALSA IEC 61883-1/6 engine, this quirk is already supported by CIP_DBC_IS_END_EVENT flag, because Echo Audio Fireworks has. Each data block includes SPH as its first quadlet field, to represent its presentation time stamp. Actual value of SPH is compliant to IEC 61883-1; lower 25 bits of 32 bits width consists of 13 bits cycle count and 12 bits cycle offset. The rest of each data block consists of 24 bit chunks. All of PCM samples, MIDI messages, status and control messages are transferred by the chunks. This is similar to '24-bit * 4 Audio Pack' in IEC 61883-6. The position of each kind of data depends on generations of each model. The number of whole chunks in a data block is a multiple of 4, to consists of quadlet-aligned packets. This commit adds data block processing layer specific for the MOTU protocol. The remarkable point is the way to generate SPH header. Time stamps for each data blocks are generated by below calculation: * Using pre-computed table for the number of ticks per event * 44,1kHz: (557 + 123/441) * 48.0kHz: (512 + 0/441) * 88.2kHz: (278 + 282/441) * 96.0kHz: (256 + 0/441) * 176.4kHz: (139 + 141/441) * 192.0kHz: (128 + 0/441) * Accumulate the ticks and set the value to SPH for every events. * This way makes sense only for blocking transmission because this mode transfers fixed number or none of events. This calculation assumes that each data block has a PCM frame which is sampled according to event timing clock. Current packet streaming layer has the same assumption. Although this sequence works fine for MOTU FireWire series at sampling transmission frequency based on 48.0kHz, it is not enough at the frequency based on 44.1kHz. The units generate choppy noise every few seconds. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2017-03-22 12:30:18 +00:00
if (p->cache->rx_cycle_count == UINT_MAX)
p->cache->rx_cycle_count = (s->domain->processing_cycle.rx_start % CYCLES_PER_SECOND);
// For data block processing.
for (i = 0; i < packets; ++i) {
const struct pkt_desc *desc = descs + i;
__be32 *buf = desc->ctx_payload;
unsigned int data_blocks = desc->data_blocks;
ALSA: firewire-motu: add MOTU specific protocol layer MOTU FireWire series uses blocking transmission for AMDTP packet streaming. They transmit/receive 8,000 packets per second, to handle the same number of data blocks as current sampling transmission frequency. Thus, IEC 61883-1/6 packet streaming engine of ALSA firewire stack is available for them. However, the sequence of packet and data blocks includes some quirks. Below sample is a sequence of CIP headers of packets received by 828mk2, at 44.1kHz of sampling transmission frequency. quads CIP1 CIP2 488 0x020F04E8 0x8222FFFF 8 0x020F04F8 0x8222FFFF 488 0x020F0400 0x8222FFFF 488 0x020F0408 0x8222FFFF 8 0x020F04E8 0x8222FFFF 488 0x020F04F0 0x8222FFFF 488 0x020F04F8 0x8222FFFF The SID (source node ID), DBS (data block size), SPH (source packet header), FMT (format ID), FDF (format dependent field) and SYT (time stamp) fields are in IEC 61883-1. Especially, FMT is 0x02, FDF is 0x22 and SYT is 0xffff to define MOTU specific protocol. In an aspect of dbc field, the value represents accumulated number of data blocks included the packet. This is against IEC 61883-1, because according to the specification this value should be the number of data blocks already transferred. In ALSA IEC 61883-1/6 engine, this quirk is already supported by CIP_DBC_IS_END_EVENT flag, because Echo Audio Fireworks has. Each data block includes SPH as its first quadlet field, to represent its presentation time stamp. Actual value of SPH is compliant to IEC 61883-1; lower 25 bits of 32 bits width consists of 13 bits cycle count and 12 bits cycle offset. The rest of each data block consists of 24 bit chunks. All of PCM samples, MIDI messages, status and control messages are transferred by the chunks. This is similar to '24-bit * 4 Audio Pack' in IEC 61883-6. The position of each kind of data depends on generations of each model. The number of whole chunks in a data block is a multiple of 4, to consists of quadlet-aligned packets. This commit adds data block processing layer specific for the MOTU protocol. The remarkable point is the way to generate SPH header. Time stamps for each data blocks are generated by below calculation: * Using pre-computed table for the number of ticks per event * 44,1kHz: (557 + 123/441) * 48.0kHz: (512 + 0/441) * 88.2kHz: (278 + 282/441) * 96.0kHz: (256 + 0/441) * 176.4kHz: (139 + 141/441) * 192.0kHz: (128 + 0/441) * Accumulate the ticks and set the value to SPH for every events. * This way makes sense only for blocking transmission because this mode transfers fixed number or none of events. This calculation assumes that each data block has a PCM frame which is sampled according to event timing clock. Current packet streaming layer has the same assumption. Although this sequence works fine for MOTU FireWire series at sampling transmission frequency based on 48.0kHz, it is not enough at the frequency based on 44.1kHz. The units generate choppy noise every few seconds. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2017-03-22 12:30:18 +00:00
if (pcm) {
write_pcm_s32(s, pcm, buf, data_blocks, pcm_frames);
pcm_frames += data_blocks;
} else {
write_pcm_silence(s, buf, data_blocks);
}
ALSA: firewire-motu: add MOTU specific protocol layer MOTU FireWire series uses blocking transmission for AMDTP packet streaming. They transmit/receive 8,000 packets per second, to handle the same number of data blocks as current sampling transmission frequency. Thus, IEC 61883-1/6 packet streaming engine of ALSA firewire stack is available for them. However, the sequence of packet and data blocks includes some quirks. Below sample is a sequence of CIP headers of packets received by 828mk2, at 44.1kHz of sampling transmission frequency. quads CIP1 CIP2 488 0x020F04E8 0x8222FFFF 8 0x020F04F8 0x8222FFFF 488 0x020F0400 0x8222FFFF 488 0x020F0408 0x8222FFFF 8 0x020F04E8 0x8222FFFF 488 0x020F04F0 0x8222FFFF 488 0x020F04F8 0x8222FFFF The SID (source node ID), DBS (data block size), SPH (source packet header), FMT (format ID), FDF (format dependent field) and SYT (time stamp) fields are in IEC 61883-1. Especially, FMT is 0x02, FDF is 0x22 and SYT is 0xffff to define MOTU specific protocol. In an aspect of dbc field, the value represents accumulated number of data blocks included the packet. This is against IEC 61883-1, because according to the specification this value should be the number of data blocks already transferred. In ALSA IEC 61883-1/6 engine, this quirk is already supported by CIP_DBC_IS_END_EVENT flag, because Echo Audio Fireworks has. Each data block includes SPH as its first quadlet field, to represent its presentation time stamp. Actual value of SPH is compliant to IEC 61883-1; lower 25 bits of 32 bits width consists of 13 bits cycle count and 12 bits cycle offset. The rest of each data block consists of 24 bit chunks. All of PCM samples, MIDI messages, status and control messages are transferred by the chunks. This is similar to '24-bit * 4 Audio Pack' in IEC 61883-6. The position of each kind of data depends on generations of each model. The number of whole chunks in a data block is a multiple of 4, to consists of quadlet-aligned packets. This commit adds data block processing layer specific for the MOTU protocol. The remarkable point is the way to generate SPH header. Time stamps for each data blocks are generated by below calculation: * Using pre-computed table for the number of ticks per event * 44,1kHz: (557 + 123/441) * 48.0kHz: (512 + 0/441) * 88.2kHz: (278 + 282/441) * 96.0kHz: (256 + 0/441) * 176.4kHz: (139 + 141/441) * 192.0kHz: (128 + 0/441) * Accumulate the ticks and set the value to SPH for every events. * This way makes sense only for blocking transmission because this mode transfers fixed number or none of events. This calculation assumes that each data block has a PCM frame which is sampled according to event timing clock. Current packet streaming layer has the same assumption. Although this sequence works fine for MOTU FireWire series at sampling transmission frequency based on 48.0kHz, it is not enough at the frequency based on 44.1kHz. The units generate choppy noise every few seconds. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2017-03-22 12:30:18 +00:00
if (p->midi_ports)
write_midi_messages(s, buf, data_blocks);
write_sph(p->cache, buf, data_blocks, s->data_block_quadlets);
}
// For tracepoints.
if (trace_data_block_sph_enabled() ||
trace_data_block_message_enabled())
probe_tracepoints_events(s, descs, packets);
return pcm_frames;
ALSA: firewire-motu: add MOTU specific protocol layer MOTU FireWire series uses blocking transmission for AMDTP packet streaming. They transmit/receive 8,000 packets per second, to handle the same number of data blocks as current sampling transmission frequency. Thus, IEC 61883-1/6 packet streaming engine of ALSA firewire stack is available for them. However, the sequence of packet and data blocks includes some quirks. Below sample is a sequence of CIP headers of packets received by 828mk2, at 44.1kHz of sampling transmission frequency. quads CIP1 CIP2 488 0x020F04E8 0x8222FFFF 8 0x020F04F8 0x8222FFFF 488 0x020F0400 0x8222FFFF 488 0x020F0408 0x8222FFFF 8 0x020F04E8 0x8222FFFF 488 0x020F04F0 0x8222FFFF 488 0x020F04F8 0x8222FFFF The SID (source node ID), DBS (data block size), SPH (source packet header), FMT (format ID), FDF (format dependent field) and SYT (time stamp) fields are in IEC 61883-1. Especially, FMT is 0x02, FDF is 0x22 and SYT is 0xffff to define MOTU specific protocol. In an aspect of dbc field, the value represents accumulated number of data blocks included the packet. This is against IEC 61883-1, because according to the specification this value should be the number of data blocks already transferred. In ALSA IEC 61883-1/6 engine, this quirk is already supported by CIP_DBC_IS_END_EVENT flag, because Echo Audio Fireworks has. Each data block includes SPH as its first quadlet field, to represent its presentation time stamp. Actual value of SPH is compliant to IEC 61883-1; lower 25 bits of 32 bits width consists of 13 bits cycle count and 12 bits cycle offset. The rest of each data block consists of 24 bit chunks. All of PCM samples, MIDI messages, status and control messages are transferred by the chunks. This is similar to '24-bit * 4 Audio Pack' in IEC 61883-6. The position of each kind of data depends on generations of each model. The number of whole chunks in a data block is a multiple of 4, to consists of quadlet-aligned packets. This commit adds data block processing layer specific for the MOTU protocol. The remarkable point is the way to generate SPH header. Time stamps for each data blocks are generated by below calculation: * Using pre-computed table for the number of ticks per event * 44,1kHz: (557 + 123/441) * 48.0kHz: (512 + 0/441) * 88.2kHz: (278 + 282/441) * 96.0kHz: (256 + 0/441) * 176.4kHz: (139 + 141/441) * 192.0kHz: (128 + 0/441) * Accumulate the ticks and set the value to SPH for every events. * This way makes sense only for blocking transmission because this mode transfers fixed number or none of events. This calculation assumes that each data block has a PCM frame which is sampled according to event timing clock. Current packet streaming layer has the same assumption. Although this sequence works fine for MOTU FireWire series at sampling transmission frequency based on 48.0kHz, it is not enough at the frequency based on 44.1kHz. The units generate choppy noise every few seconds. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2017-03-22 12:30:18 +00:00
}
int amdtp_motu_init(struct amdtp_stream *s, struct fw_unit *unit,
enum amdtp_stream_direction dir,
const struct snd_motu_spec *spec, struct amdtp_motu_cache *cache)
ALSA: firewire-motu: add MOTU specific protocol layer MOTU FireWire series uses blocking transmission for AMDTP packet streaming. They transmit/receive 8,000 packets per second, to handle the same number of data blocks as current sampling transmission frequency. Thus, IEC 61883-1/6 packet streaming engine of ALSA firewire stack is available for them. However, the sequence of packet and data blocks includes some quirks. Below sample is a sequence of CIP headers of packets received by 828mk2, at 44.1kHz of sampling transmission frequency. quads CIP1 CIP2 488 0x020F04E8 0x8222FFFF 8 0x020F04F8 0x8222FFFF 488 0x020F0400 0x8222FFFF 488 0x020F0408 0x8222FFFF 8 0x020F04E8 0x8222FFFF 488 0x020F04F0 0x8222FFFF 488 0x020F04F8 0x8222FFFF The SID (source node ID), DBS (data block size), SPH (source packet header), FMT (format ID), FDF (format dependent field) and SYT (time stamp) fields are in IEC 61883-1. Especially, FMT is 0x02, FDF is 0x22 and SYT is 0xffff to define MOTU specific protocol. In an aspect of dbc field, the value represents accumulated number of data blocks included the packet. This is against IEC 61883-1, because according to the specification this value should be the number of data blocks already transferred. In ALSA IEC 61883-1/6 engine, this quirk is already supported by CIP_DBC_IS_END_EVENT flag, because Echo Audio Fireworks has. Each data block includes SPH as its first quadlet field, to represent its presentation time stamp. Actual value of SPH is compliant to IEC 61883-1; lower 25 bits of 32 bits width consists of 13 bits cycle count and 12 bits cycle offset. The rest of each data block consists of 24 bit chunks. All of PCM samples, MIDI messages, status and control messages are transferred by the chunks. This is similar to '24-bit * 4 Audio Pack' in IEC 61883-6. The position of each kind of data depends on generations of each model. The number of whole chunks in a data block is a multiple of 4, to consists of quadlet-aligned packets. This commit adds data block processing layer specific for the MOTU protocol. The remarkable point is the way to generate SPH header. Time stamps for each data blocks are generated by below calculation: * Using pre-computed table for the number of ticks per event * 44,1kHz: (557 + 123/441) * 48.0kHz: (512 + 0/441) * 88.2kHz: (278 + 282/441) * 96.0kHz: (256 + 0/441) * 176.4kHz: (139 + 141/441) * 192.0kHz: (128 + 0/441) * Accumulate the ticks and set the value to SPH for every events. * This way makes sense only for blocking transmission because this mode transfers fixed number or none of events. This calculation assumes that each data block has a PCM frame which is sampled according to event timing clock. Current packet streaming layer has the same assumption. Although this sequence works fine for MOTU FireWire series at sampling transmission frequency based on 48.0kHz, it is not enough at the frequency based on 44.1kHz. The units generate choppy noise every few seconds. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2017-03-22 12:30:18 +00:00
{
amdtp_stream_process_ctx_payloads_t process_ctx_payloads;
ALSA: firewire-motu: add MOTU specific protocol layer MOTU FireWire series uses blocking transmission for AMDTP packet streaming. They transmit/receive 8,000 packets per second, to handle the same number of data blocks as current sampling transmission frequency. Thus, IEC 61883-1/6 packet streaming engine of ALSA firewire stack is available for them. However, the sequence of packet and data blocks includes some quirks. Below sample is a sequence of CIP headers of packets received by 828mk2, at 44.1kHz of sampling transmission frequency. quads CIP1 CIP2 488 0x020F04E8 0x8222FFFF 8 0x020F04F8 0x8222FFFF 488 0x020F0400 0x8222FFFF 488 0x020F0408 0x8222FFFF 8 0x020F04E8 0x8222FFFF 488 0x020F04F0 0x8222FFFF 488 0x020F04F8 0x8222FFFF The SID (source node ID), DBS (data block size), SPH (source packet header), FMT (format ID), FDF (format dependent field) and SYT (time stamp) fields are in IEC 61883-1. Especially, FMT is 0x02, FDF is 0x22 and SYT is 0xffff to define MOTU specific protocol. In an aspect of dbc field, the value represents accumulated number of data blocks included the packet. This is against IEC 61883-1, because according to the specification this value should be the number of data blocks already transferred. In ALSA IEC 61883-1/6 engine, this quirk is already supported by CIP_DBC_IS_END_EVENT flag, because Echo Audio Fireworks has. Each data block includes SPH as its first quadlet field, to represent its presentation time stamp. Actual value of SPH is compliant to IEC 61883-1; lower 25 bits of 32 bits width consists of 13 bits cycle count and 12 bits cycle offset. The rest of each data block consists of 24 bit chunks. All of PCM samples, MIDI messages, status and control messages are transferred by the chunks. This is similar to '24-bit * 4 Audio Pack' in IEC 61883-6. The position of each kind of data depends on generations of each model. The number of whole chunks in a data block is a multiple of 4, to consists of quadlet-aligned packets. This commit adds data block processing layer specific for the MOTU protocol. The remarkable point is the way to generate SPH header. Time stamps for each data blocks are generated by below calculation: * Using pre-computed table for the number of ticks per event * 44,1kHz: (557 + 123/441) * 48.0kHz: (512 + 0/441) * 88.2kHz: (278 + 282/441) * 96.0kHz: (256 + 0/441) * 176.4kHz: (139 + 141/441) * 192.0kHz: (128 + 0/441) * Accumulate the ticks and set the value to SPH for every events. * This way makes sense only for blocking transmission because this mode transfers fixed number or none of events. This calculation assumes that each data block has a PCM frame which is sampled according to event timing clock. Current packet streaming layer has the same assumption. Although this sequence works fine for MOTU FireWire series at sampling transmission frequency based on 48.0kHz, it is not enough at the frequency based on 44.1kHz. The units generate choppy noise every few seconds. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2017-03-22 12:30:18 +00:00
int fmt = CIP_FMT_MOTU;
unsigned int flags = CIP_BLOCKING | CIP_UNAWARE_SYT;
struct amdtp_motu *p;
ALSA: firewire-motu: add MOTU specific protocol layer MOTU FireWire series uses blocking transmission for AMDTP packet streaming. They transmit/receive 8,000 packets per second, to handle the same number of data blocks as current sampling transmission frequency. Thus, IEC 61883-1/6 packet streaming engine of ALSA firewire stack is available for them. However, the sequence of packet and data blocks includes some quirks. Below sample is a sequence of CIP headers of packets received by 828mk2, at 44.1kHz of sampling transmission frequency. quads CIP1 CIP2 488 0x020F04E8 0x8222FFFF 8 0x020F04F8 0x8222FFFF 488 0x020F0400 0x8222FFFF 488 0x020F0408 0x8222FFFF 8 0x020F04E8 0x8222FFFF 488 0x020F04F0 0x8222FFFF 488 0x020F04F8 0x8222FFFF The SID (source node ID), DBS (data block size), SPH (source packet header), FMT (format ID), FDF (format dependent field) and SYT (time stamp) fields are in IEC 61883-1. Especially, FMT is 0x02, FDF is 0x22 and SYT is 0xffff to define MOTU specific protocol. In an aspect of dbc field, the value represents accumulated number of data blocks included the packet. This is against IEC 61883-1, because according to the specification this value should be the number of data blocks already transferred. In ALSA IEC 61883-1/6 engine, this quirk is already supported by CIP_DBC_IS_END_EVENT flag, because Echo Audio Fireworks has. Each data block includes SPH as its first quadlet field, to represent its presentation time stamp. Actual value of SPH is compliant to IEC 61883-1; lower 25 bits of 32 bits width consists of 13 bits cycle count and 12 bits cycle offset. The rest of each data block consists of 24 bit chunks. All of PCM samples, MIDI messages, status and control messages are transferred by the chunks. This is similar to '24-bit * 4 Audio Pack' in IEC 61883-6. The position of each kind of data depends on generations of each model. The number of whole chunks in a data block is a multiple of 4, to consists of quadlet-aligned packets. This commit adds data block processing layer specific for the MOTU protocol. The remarkable point is the way to generate SPH header. Time stamps for each data blocks are generated by below calculation: * Using pre-computed table for the number of ticks per event * 44,1kHz: (557 + 123/441) * 48.0kHz: (512 + 0/441) * 88.2kHz: (278 + 282/441) * 96.0kHz: (256 + 0/441) * 176.4kHz: (139 + 141/441) * 192.0kHz: (128 + 0/441) * Accumulate the ticks and set the value to SPH for every events. * This way makes sense only for blocking transmission because this mode transfers fixed number or none of events. This calculation assumes that each data block has a PCM frame which is sampled according to event timing clock. Current packet streaming layer has the same assumption. Although this sequence works fine for MOTU FireWire series at sampling transmission frequency based on 48.0kHz, it is not enough at the frequency based on 44.1kHz. The units generate choppy noise every few seconds. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2017-03-22 12:30:18 +00:00
int err;
if (dir == AMDTP_IN_STREAM) {
process_ctx_payloads = process_ir_ctx_payloads;
ALSA: firewire-motu: add support for MOTU 828mk3 (FireWire/Hybrid) as a model with protocol version 3 MOTU 828mk3 (FireWire/Hybrid) is one of third generation in MOTU FireWire series, produced in 2008/2014. This model consists of three chips for functionality on IEEE 1394 bus: * TI TSB41AB2 (Physical layer for IEEE 1394 bus) * Xilinx Spartan-3E FPGA Family (Link layer for IEEE 1394 bus, packet processing and data block processing layer) * TI TMS320C6722 (Digital signal processing) This commit adds a support for this model, with its unique protocol as version 3. This protocol has some additional features to protocol version 2. * Support several optical interfaces. * Support a data chunk for return of reverb effect. * Have a quirk of tx packets. * Support heartbeat asynchronous transaction. In this protocol, series of transferred packets has some quirks. Below fields in CIP headers of the packets are out of IEC 61883-1: - SID (source node id): always 0x0d - DBS (data block size): always 0x04 - DBC (data block counter): always 0x00 - EOH (End of header): always 0x00 Below is an actual sample of transferred packets. quads CIP1 CIP2 520 0x0D040400 0x22FFFFFF 8 0x0D040400 0x22FFFFFF 520 0x0D040400 0x22FFFFFF 520 0x0D040400 0x22FFFFFF 8 0x0D040400 0x22FFFFFF Status of clock is configured by write transactions to 0x'ffff'f000'0b14, as well as version 2, while meanings of fields are different from the former protocols. Modes of optical interfaces are configured by write transactions to 0x'ffff'f000'0c94. Drivers can register its address to receive heatbeat transactions from the unit. 0x'ffff'f000'0b0c is for the higher part and 0x'ffff'f000'0b10 is for the lower part. Nevertheless, this feature is not useless for this driver and this commit omits it. Each data block consists of two parts in a point of the number of included data chunks. In both of 'fixed' and 'differed' parts, the number of included data blocks are a multiple of 4, thus depending on models there's some empty data chunks. For example, 828mk3 includes one pair of empty data chunks in its fixed part. When optical interface is configured to S/PDIF, 828mk3 includes one pair of empty data chunks in its differed part. To reduce consumption of CPU cycles with additional conditions/loops, this commit just exposes these empty chunks to user space as PCM channels. Additionally, 828mk3 has a non-negligible overhead to change its sampling transfer frequency. When softwares send asynchronous transaction to perform it, LED on the unit starts to blink. In a worst case, it continues blink during several seconds; e.g. 10 seconds. When stopping blinking, the unit seems to be prepared for the requested sampling transfer frequency. To wait for the preparation, this commit forces the driver to call task scheduler and applications sleeps for 4 seconds. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2017-03-22 12:30:28 +00:00
/*
* Units of version 3 transmits packets with invalid CIP header
* against IEC 61883-1.
*/
if (spec->protocol_version == SND_MOTU_PROTOCOL_V3) {
ALSA: firewire-motu: add support for MOTU 828mk3 (FireWire/Hybrid) as a model with protocol version 3 MOTU 828mk3 (FireWire/Hybrid) is one of third generation in MOTU FireWire series, produced in 2008/2014. This model consists of three chips for functionality on IEEE 1394 bus: * TI TSB41AB2 (Physical layer for IEEE 1394 bus) * Xilinx Spartan-3E FPGA Family (Link layer for IEEE 1394 bus, packet processing and data block processing layer) * TI TMS320C6722 (Digital signal processing) This commit adds a support for this model, with its unique protocol as version 3. This protocol has some additional features to protocol version 2. * Support several optical interfaces. * Support a data chunk for return of reverb effect. * Have a quirk of tx packets. * Support heartbeat asynchronous transaction. In this protocol, series of transferred packets has some quirks. Below fields in CIP headers of the packets are out of IEC 61883-1: - SID (source node id): always 0x0d - DBS (data block size): always 0x04 - DBC (data block counter): always 0x00 - EOH (End of header): always 0x00 Below is an actual sample of transferred packets. quads CIP1 CIP2 520 0x0D040400 0x22FFFFFF 8 0x0D040400 0x22FFFFFF 520 0x0D040400 0x22FFFFFF 520 0x0D040400 0x22FFFFFF 8 0x0D040400 0x22FFFFFF Status of clock is configured by write transactions to 0x'ffff'f000'0b14, as well as version 2, while meanings of fields are different from the former protocols. Modes of optical interfaces are configured by write transactions to 0x'ffff'f000'0c94. Drivers can register its address to receive heatbeat transactions from the unit. 0x'ffff'f000'0b0c is for the higher part and 0x'ffff'f000'0b10 is for the lower part. Nevertheless, this feature is not useless for this driver and this commit omits it. Each data block consists of two parts in a point of the number of included data chunks. In both of 'fixed' and 'differed' parts, the number of included data blocks are a multiple of 4, thus depending on models there's some empty data chunks. For example, 828mk3 includes one pair of empty data chunks in its fixed part. When optical interface is configured to S/PDIF, 828mk3 includes one pair of empty data chunks in its differed part. To reduce consumption of CPU cycles with additional conditions/loops, this commit just exposes these empty chunks to user space as PCM channels. Additionally, 828mk3 has a non-negligible overhead to change its sampling transfer frequency. When softwares send asynchronous transaction to perform it, LED on the unit starts to blink. In a worst case, it continues blink during several seconds; e.g. 10 seconds. When stopping blinking, the unit seems to be prepared for the requested sampling transfer frequency. To wait for the preparation, this commit forces the driver to call task scheduler and applications sleeps for 4 seconds. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2017-03-22 12:30:28 +00:00
flags |= CIP_WRONG_DBS |
CIP_SKIP_DBC_ZERO_CHECK |
CIP_HEADER_WITHOUT_EOH;
fmt = CIP_FMT_MOTU_TX_V3;
}
ALSA: firewire-motu: add support MOTU 8pre FireWire This commit adds support for MOTU 8pre FireWire, which was shipped 2007 and nowadays already discontinued. Userspace applications can transmit and receive PCM frames and MIDI messages for this model via ALSA PCM interface and RawMidi/Sequencer interfaces. Like the other models of MOTU FireWire series, this model has many quirks in its CIP. At first, data channels for two pairs of optical interfaces. At lower sampling transmission frequency, i.e. 44.1 and 48.0 kHz, one pair is available for ADAT data, thus 8 data chunks are transferred by CIP. At middle sampling transmission frequency, i.e. 88.2 and 96.0 kHz, two pairs are available to keep 8 chunks for ADAT data, thus CIP still includes 8 data chunks. Apart from data chunks for optical interface, CIP includes fixed number of data chunks. In tx stream, two chunks for status message, eight chunks for samples from analog 1-8 input, two chunks for mix-return. In rx stream, two chunks for control message, two chunks for main 1-2 output, two chunks for phone 1-2 output, two chunks for dummy 1-2. CIP header in tx stream includes quirks for its dbs and dbc fields. The value of dbs field is fixed to 0x13, against its actual size. The value of dbc field is firstly updated to 0x07 from zero, then it's incremented continuously according to actual number of data h blocks. Finally, the model has own bits to disable frame fetch. This commit uses several options to absorb the above quirks. $ python2 crpp < /sys/bus/firewire/devices/fw1/config_rom ROM header and bus information block ----------------------------------------------------------------- 400 0410b57d bus_info_length 4, crc_length 16, crc 46461 404 31333934 bus_name "1394" 408 20001000 irmc 0, cmc 0, isc 1, bmc 0, cyc_clk_acc 0, max_rec 1 (4) 40c 0001f200 company_id 0001f2 | 410 00083dfb device_id 0000083dfb | EUI-64 0001f20000083dfb root directory ----------------------------------------------------------------- 414 0004c65c directory_length 4, crc 50780 418 030001f2 vendor 41c 0c0083c0 node capabilities per IEEE 1394 420 8d000006 --> eui-64 leaf at 438 424 d1000001 --> unit directory at 428 unit directory at 428 ----------------------------------------------------------------- 428 0003991c directory_length 3, crc 39196 42c 120001f2 specifier id 430 1300000f version 434 17103800 model eui-64 leaf at 438 ----------------------------------------------------------------- 438 00022681 leaf_length 2, crc 9857 43c 0001f200 company_id 0001f2 | 440 00083dfb device_id 0000083dfb | EUI-64 0001f20000083dfb Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-03-17 07:50:24 +00:00
if (spec == &snd_motu_spec_8pre ||
spec == &snd_motu_spec_ultralite) {
ALSA: firewire-motu: add support MOTU 8pre FireWire This commit adds support for MOTU 8pre FireWire, which was shipped 2007 and nowadays already discontinued. Userspace applications can transmit and receive PCM frames and MIDI messages for this model via ALSA PCM interface and RawMidi/Sequencer interfaces. Like the other models of MOTU FireWire series, this model has many quirks in its CIP. At first, data channels for two pairs of optical interfaces. At lower sampling transmission frequency, i.e. 44.1 and 48.0 kHz, one pair is available for ADAT data, thus 8 data chunks are transferred by CIP. At middle sampling transmission frequency, i.e. 88.2 and 96.0 kHz, two pairs are available to keep 8 chunks for ADAT data, thus CIP still includes 8 data chunks. Apart from data chunks for optical interface, CIP includes fixed number of data chunks. In tx stream, two chunks for status message, eight chunks for samples from analog 1-8 input, two chunks for mix-return. In rx stream, two chunks for control message, two chunks for main 1-2 output, two chunks for phone 1-2 output, two chunks for dummy 1-2. CIP header in tx stream includes quirks for its dbs and dbc fields. The value of dbs field is fixed to 0x13, against its actual size. The value of dbc field is firstly updated to 0x07 from zero, then it's incremented continuously according to actual number of data h blocks. Finally, the model has own bits to disable frame fetch. This commit uses several options to absorb the above quirks. $ python2 crpp < /sys/bus/firewire/devices/fw1/config_rom ROM header and bus information block ----------------------------------------------------------------- 400 0410b57d bus_info_length 4, crc_length 16, crc 46461 404 31333934 bus_name "1394" 408 20001000 irmc 0, cmc 0, isc 1, bmc 0, cyc_clk_acc 0, max_rec 1 (4) 40c 0001f200 company_id 0001f2 | 410 00083dfb device_id 0000083dfb | EUI-64 0001f20000083dfb root directory ----------------------------------------------------------------- 414 0004c65c directory_length 4, crc 50780 418 030001f2 vendor 41c 0c0083c0 node capabilities per IEEE 1394 420 8d000006 --> eui-64 leaf at 438 424 d1000001 --> unit directory at 428 unit directory at 428 ----------------------------------------------------------------- 428 0003991c directory_length 3, crc 39196 42c 120001f2 specifier id 430 1300000f version 434 17103800 model eui-64 leaf at 438 ----------------------------------------------------------------- 438 00022681 leaf_length 2, crc 9857 43c 0001f200 company_id 0001f2 | 440 00083dfb device_id 0000083dfb | EUI-64 0001f20000083dfb Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-03-17 07:50:24 +00:00
// 8pre has some quirks.
flags |= CIP_WRONG_DBS |
CIP_SKIP_DBC_ZERO_CHECK;
}
ALSA: firewire-motu: add MOTU specific protocol layer MOTU FireWire series uses blocking transmission for AMDTP packet streaming. They transmit/receive 8,000 packets per second, to handle the same number of data blocks as current sampling transmission frequency. Thus, IEC 61883-1/6 packet streaming engine of ALSA firewire stack is available for them. However, the sequence of packet and data blocks includes some quirks. Below sample is a sequence of CIP headers of packets received by 828mk2, at 44.1kHz of sampling transmission frequency. quads CIP1 CIP2 488 0x020F04E8 0x8222FFFF 8 0x020F04F8 0x8222FFFF 488 0x020F0400 0x8222FFFF 488 0x020F0408 0x8222FFFF 8 0x020F04E8 0x8222FFFF 488 0x020F04F0 0x8222FFFF 488 0x020F04F8 0x8222FFFF The SID (source node ID), DBS (data block size), SPH (source packet header), FMT (format ID), FDF (format dependent field) and SYT (time stamp) fields are in IEC 61883-1. Especially, FMT is 0x02, FDF is 0x22 and SYT is 0xffff to define MOTU specific protocol. In an aspect of dbc field, the value represents accumulated number of data blocks included the packet. This is against IEC 61883-1, because according to the specification this value should be the number of data blocks already transferred. In ALSA IEC 61883-1/6 engine, this quirk is already supported by CIP_DBC_IS_END_EVENT flag, because Echo Audio Fireworks has. Each data block includes SPH as its first quadlet field, to represent its presentation time stamp. Actual value of SPH is compliant to IEC 61883-1; lower 25 bits of 32 bits width consists of 13 bits cycle count and 12 bits cycle offset. The rest of each data block consists of 24 bit chunks. All of PCM samples, MIDI messages, status and control messages are transferred by the chunks. This is similar to '24-bit * 4 Audio Pack' in IEC 61883-6. The position of each kind of data depends on generations of each model. The number of whole chunks in a data block is a multiple of 4, to consists of quadlet-aligned packets. This commit adds data block processing layer specific for the MOTU protocol. The remarkable point is the way to generate SPH header. Time stamps for each data blocks are generated by below calculation: * Using pre-computed table for the number of ticks per event * 44,1kHz: (557 + 123/441) * 48.0kHz: (512 + 0/441) * 88.2kHz: (278 + 282/441) * 96.0kHz: (256 + 0/441) * 176.4kHz: (139 + 141/441) * 192.0kHz: (128 + 0/441) * Accumulate the ticks and set the value to SPH for every events. * This way makes sense only for blocking transmission because this mode transfers fixed number or none of events. This calculation assumes that each data block has a PCM frame which is sampled according to event timing clock. Current packet streaming layer has the same assumption. Although this sequence works fine for MOTU FireWire series at sampling transmission frequency based on 48.0kHz, it is not enough at the frequency based on 44.1kHz. The units generate choppy noise every few seconds. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2017-03-22 12:30:18 +00:00
} else {
process_ctx_payloads = process_it_ctx_payloads;
ALSA: firewire-motu: add MOTU specific protocol layer MOTU FireWire series uses blocking transmission for AMDTP packet streaming. They transmit/receive 8,000 packets per second, to handle the same number of data blocks as current sampling transmission frequency. Thus, IEC 61883-1/6 packet streaming engine of ALSA firewire stack is available for them. However, the sequence of packet and data blocks includes some quirks. Below sample is a sequence of CIP headers of packets received by 828mk2, at 44.1kHz of sampling transmission frequency. quads CIP1 CIP2 488 0x020F04E8 0x8222FFFF 8 0x020F04F8 0x8222FFFF 488 0x020F0400 0x8222FFFF 488 0x020F0408 0x8222FFFF 8 0x020F04E8 0x8222FFFF 488 0x020F04F0 0x8222FFFF 488 0x020F04F8 0x8222FFFF The SID (source node ID), DBS (data block size), SPH (source packet header), FMT (format ID), FDF (format dependent field) and SYT (time stamp) fields are in IEC 61883-1. Especially, FMT is 0x02, FDF is 0x22 and SYT is 0xffff to define MOTU specific protocol. In an aspect of dbc field, the value represents accumulated number of data blocks included the packet. This is against IEC 61883-1, because according to the specification this value should be the number of data blocks already transferred. In ALSA IEC 61883-1/6 engine, this quirk is already supported by CIP_DBC_IS_END_EVENT flag, because Echo Audio Fireworks has. Each data block includes SPH as its first quadlet field, to represent its presentation time stamp. Actual value of SPH is compliant to IEC 61883-1; lower 25 bits of 32 bits width consists of 13 bits cycle count and 12 bits cycle offset. The rest of each data block consists of 24 bit chunks. All of PCM samples, MIDI messages, status and control messages are transferred by the chunks. This is similar to '24-bit * 4 Audio Pack' in IEC 61883-6. The position of each kind of data depends on generations of each model. The number of whole chunks in a data block is a multiple of 4, to consists of quadlet-aligned packets. This commit adds data block processing layer specific for the MOTU protocol. The remarkable point is the way to generate SPH header. Time stamps for each data blocks are generated by below calculation: * Using pre-computed table for the number of ticks per event * 44,1kHz: (557 + 123/441) * 48.0kHz: (512 + 0/441) * 88.2kHz: (278 + 282/441) * 96.0kHz: (256 + 0/441) * 176.4kHz: (139 + 141/441) * 192.0kHz: (128 + 0/441) * Accumulate the ticks and set the value to SPH for every events. * This way makes sense only for blocking transmission because this mode transfers fixed number or none of events. This calculation assumes that each data block has a PCM frame which is sampled according to event timing clock. Current packet streaming layer has the same assumption. Although this sequence works fine for MOTU FireWire series at sampling transmission frequency based on 48.0kHz, it is not enough at the frequency based on 44.1kHz. The units generate choppy noise every few seconds. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2017-03-22 12:30:18 +00:00
flags |= CIP_DBC_IS_END_EVENT;
}
err = amdtp_stream_init(s, unit, dir, flags, fmt, process_ctx_payloads,
ALSA: firewire-motu: add MOTU specific protocol layer MOTU FireWire series uses blocking transmission for AMDTP packet streaming. They transmit/receive 8,000 packets per second, to handle the same number of data blocks as current sampling transmission frequency. Thus, IEC 61883-1/6 packet streaming engine of ALSA firewire stack is available for them. However, the sequence of packet and data blocks includes some quirks. Below sample is a sequence of CIP headers of packets received by 828mk2, at 44.1kHz of sampling transmission frequency. quads CIP1 CIP2 488 0x020F04E8 0x8222FFFF 8 0x020F04F8 0x8222FFFF 488 0x020F0400 0x8222FFFF 488 0x020F0408 0x8222FFFF 8 0x020F04E8 0x8222FFFF 488 0x020F04F0 0x8222FFFF 488 0x020F04F8 0x8222FFFF The SID (source node ID), DBS (data block size), SPH (source packet header), FMT (format ID), FDF (format dependent field) and SYT (time stamp) fields are in IEC 61883-1. Especially, FMT is 0x02, FDF is 0x22 and SYT is 0xffff to define MOTU specific protocol. In an aspect of dbc field, the value represents accumulated number of data blocks included the packet. This is against IEC 61883-1, because according to the specification this value should be the number of data blocks already transferred. In ALSA IEC 61883-1/6 engine, this quirk is already supported by CIP_DBC_IS_END_EVENT flag, because Echo Audio Fireworks has. Each data block includes SPH as its first quadlet field, to represent its presentation time stamp. Actual value of SPH is compliant to IEC 61883-1; lower 25 bits of 32 bits width consists of 13 bits cycle count and 12 bits cycle offset. The rest of each data block consists of 24 bit chunks. All of PCM samples, MIDI messages, status and control messages are transferred by the chunks. This is similar to '24-bit * 4 Audio Pack' in IEC 61883-6. The position of each kind of data depends on generations of each model. The number of whole chunks in a data block is a multiple of 4, to consists of quadlet-aligned packets. This commit adds data block processing layer specific for the MOTU protocol. The remarkable point is the way to generate SPH header. Time stamps for each data blocks are generated by below calculation: * Using pre-computed table for the number of ticks per event * 44,1kHz: (557 + 123/441) * 48.0kHz: (512 + 0/441) * 88.2kHz: (278 + 282/441) * 96.0kHz: (256 + 0/441) * 176.4kHz: (139 + 141/441) * 192.0kHz: (128 + 0/441) * Accumulate the ticks and set the value to SPH for every events. * This way makes sense only for blocking transmission because this mode transfers fixed number or none of events. This calculation assumes that each data block has a PCM frame which is sampled according to event timing clock. Current packet streaming layer has the same assumption. Although this sequence works fine for MOTU FireWire series at sampling transmission frequency based on 48.0kHz, it is not enough at the frequency based on 44.1kHz. The units generate choppy noise every few seconds. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2017-03-22 12:30:18 +00:00
sizeof(struct amdtp_motu));
if (err < 0)
return err;
s->sph = 1;
if (dir == AMDTP_OUT_STREAM) {
// Use fixed value for FDF field.
s->ctx_data.rx.fdf = MOTU_FDF_AM824;
}
ALSA: firewire-motu: add MOTU specific protocol layer MOTU FireWire series uses blocking transmission for AMDTP packet streaming. They transmit/receive 8,000 packets per second, to handle the same number of data blocks as current sampling transmission frequency. Thus, IEC 61883-1/6 packet streaming engine of ALSA firewire stack is available for them. However, the sequence of packet and data blocks includes some quirks. Below sample is a sequence of CIP headers of packets received by 828mk2, at 44.1kHz of sampling transmission frequency. quads CIP1 CIP2 488 0x020F04E8 0x8222FFFF 8 0x020F04F8 0x8222FFFF 488 0x020F0400 0x8222FFFF 488 0x020F0408 0x8222FFFF 8 0x020F04E8 0x8222FFFF 488 0x020F04F0 0x8222FFFF 488 0x020F04F8 0x8222FFFF The SID (source node ID), DBS (data block size), SPH (source packet header), FMT (format ID), FDF (format dependent field) and SYT (time stamp) fields are in IEC 61883-1. Especially, FMT is 0x02, FDF is 0x22 and SYT is 0xffff to define MOTU specific protocol. In an aspect of dbc field, the value represents accumulated number of data blocks included the packet. This is against IEC 61883-1, because according to the specification this value should be the number of data blocks already transferred. In ALSA IEC 61883-1/6 engine, this quirk is already supported by CIP_DBC_IS_END_EVENT flag, because Echo Audio Fireworks has. Each data block includes SPH as its first quadlet field, to represent its presentation time stamp. Actual value of SPH is compliant to IEC 61883-1; lower 25 bits of 32 bits width consists of 13 bits cycle count and 12 bits cycle offset. The rest of each data block consists of 24 bit chunks. All of PCM samples, MIDI messages, status and control messages are transferred by the chunks. This is similar to '24-bit * 4 Audio Pack' in IEC 61883-6. The position of each kind of data depends on generations of each model. The number of whole chunks in a data block is a multiple of 4, to consists of quadlet-aligned packets. This commit adds data block processing layer specific for the MOTU protocol. The remarkable point is the way to generate SPH header. Time stamps for each data blocks are generated by below calculation: * Using pre-computed table for the number of ticks per event * 44,1kHz: (557 + 123/441) * 48.0kHz: (512 + 0/441) * 88.2kHz: (278 + 282/441) * 96.0kHz: (256 + 0/441) * 176.4kHz: (139 + 141/441) * 192.0kHz: (128 + 0/441) * Accumulate the ticks and set the value to SPH for every events. * This way makes sense only for blocking transmission because this mode transfers fixed number or none of events. This calculation assumes that each data block has a PCM frame which is sampled according to event timing clock. Current packet streaming layer has the same assumption. Although this sequence works fine for MOTU FireWire series at sampling transmission frequency based on 48.0kHz, it is not enough at the frequency based on 44.1kHz. The units generate choppy noise every few seconds. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2017-03-22 12:30:18 +00:00
p = s->protocol;
p->cache = cache;
ALSA: firewire-motu: add MOTU specific protocol layer MOTU FireWire series uses blocking transmission for AMDTP packet streaming. They transmit/receive 8,000 packets per second, to handle the same number of data blocks as current sampling transmission frequency. Thus, IEC 61883-1/6 packet streaming engine of ALSA firewire stack is available for them. However, the sequence of packet and data blocks includes some quirks. Below sample is a sequence of CIP headers of packets received by 828mk2, at 44.1kHz of sampling transmission frequency. quads CIP1 CIP2 488 0x020F04E8 0x8222FFFF 8 0x020F04F8 0x8222FFFF 488 0x020F0400 0x8222FFFF 488 0x020F0408 0x8222FFFF 8 0x020F04E8 0x8222FFFF 488 0x020F04F0 0x8222FFFF 488 0x020F04F8 0x8222FFFF The SID (source node ID), DBS (data block size), SPH (source packet header), FMT (format ID), FDF (format dependent field) and SYT (time stamp) fields are in IEC 61883-1. Especially, FMT is 0x02, FDF is 0x22 and SYT is 0xffff to define MOTU specific protocol. In an aspect of dbc field, the value represents accumulated number of data blocks included the packet. This is against IEC 61883-1, because according to the specification this value should be the number of data blocks already transferred. In ALSA IEC 61883-1/6 engine, this quirk is already supported by CIP_DBC_IS_END_EVENT flag, because Echo Audio Fireworks has. Each data block includes SPH as its first quadlet field, to represent its presentation time stamp. Actual value of SPH is compliant to IEC 61883-1; lower 25 bits of 32 bits width consists of 13 bits cycle count and 12 bits cycle offset. The rest of each data block consists of 24 bit chunks. All of PCM samples, MIDI messages, status and control messages are transferred by the chunks. This is similar to '24-bit * 4 Audio Pack' in IEC 61883-6. The position of each kind of data depends on generations of each model. The number of whole chunks in a data block is a multiple of 4, to consists of quadlet-aligned packets. This commit adds data block processing layer specific for the MOTU protocol. The remarkable point is the way to generate SPH header. Time stamps for each data blocks are generated by below calculation: * Using pre-computed table for the number of ticks per event * 44,1kHz: (557 + 123/441) * 48.0kHz: (512 + 0/441) * 88.2kHz: (278 + 282/441) * 96.0kHz: (256 + 0/441) * 176.4kHz: (139 + 141/441) * 192.0kHz: (128 + 0/441) * Accumulate the ticks and set the value to SPH for every events. * This way makes sense only for blocking transmission because this mode transfers fixed number or none of events. This calculation assumes that each data block has a PCM frame which is sampled according to event timing clock. Current packet streaming layer has the same assumption. Although this sequence works fine for MOTU FireWire series at sampling transmission frequency based on 48.0kHz, it is not enough at the frequency based on 44.1kHz. The units generate choppy noise every few seconds. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2017-03-22 12:30:18 +00:00
return 0;
}