2019-05-29 16:57:59 -07:00
|
|
|
/* SPDX-License-Identifier: GPL-2.0-only */
|
2017-03-22 05:30:11 -07:00
|
|
|
/*
|
|
|
|
|
* motu.h - a part of driver for MOTU FireWire series
|
|
|
|
|
*
|
|
|
|
|
* Copyright (c) 2015-2017 Takashi Sakamoto <o-takashi@sakamocchi.jp>
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
#ifndef SOUND_FIREWIRE_MOTU_H_INCLUDED
|
|
|
|
|
#define SOUND_FIREWIRE_MOTU_H_INCLUDED
|
|
|
|
|
|
|
|
|
|
#include <linux/device.h>
|
|
|
|
|
#include <linux/firewire.h>
|
|
|
|
|
#include <linux/firewire-constants.h>
|
|
|
|
|
#include <linux/module.h>
|
|
|
|
|
#include <linux/mod_devicetable.h>
|
|
|
|
|
#include <linux/mutex.h>
|
|
|
|
|
#include <linux/slab.h>
|
2017-03-22 05:30:24 -07:00
|
|
|
#include <linux/compat.h>
|
|
|
|
|
#include <linux/sched/signal.h>
|
2017-03-22 05:30:11 -07:00
|
|
|
|
|
|
|
|
#include <sound/control.h>
|
|
|
|
|
#include <sound/core.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 05:30:18 -07:00
|
|
|
#include <sound/pcm.h>
|
2017-03-22 05:30:21 -07:00
|
|
|
#include <sound/info.h>
|
2017-03-22 05:30:23 -07:00
|
|
|
#include <sound/rawmidi.h>
|
2017-03-22 05:30:24 -07:00
|
|
|
#include <sound/firewire.h>
|
|
|
|
|
#include <sound/hwdep.h>
|
2017-03-22 05:30:11 -07:00
|
|
|
|
2017-03-22 05:30:12 -07:00
|
|
|
#include "../lib.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 05:30:18 -07:00
|
|
|
#include "../amdtp-stream.h"
|
2017-03-22 05:30:20 -07:00
|
|
|
#include "../iso-resources.h"
|
2017-03-22 05:30:12 -07:00
|
|
|
|
ALSA: firewire-motu: add an abstraction layer for three types of protocols
In an aspect of used protocols to communicate, models of MOTU FireWire
units are categorized to three generations.
This commit adds an abstraction layer of the protocols for features
related to packet streaming functionality. This layer includes 5
operations.
When configuring packet streaming functionality with sampling rate and
sampling transmission frequency, .get_clock_rate and .set_clock_rate are
called with proper arguments. MOTU FireWire series supports up to 192.0kHz.
When checking current source of sampling clock (not clock for packetization
layer), .get_clock_source is used. Enumeration is added to represent the
sources supported by this series. This operation can be used to expose
available sampling rate to user space applications when the unit is
configured to use any input signal as source of clock instead of crystal
clock.
In the protocols, the path between packet processing layer and digital
signal processing layer can be controlled. This looks a functionality to
'mute' the unit. For this feature, .switch_fetching_mode is added. This
can be used to suppress noises every time packet streaming starts/stops.
In a point of the size of data blocks at a certain sampling transmission
frequency, the most units accept several modes. This is due to usage of
optical interfaces. The size differs depending on which modes are
configured to the interfaces; None, S/PDIF and ADAT. Additionally, format
of packet is different depending on protocols. To cache current size of
data blocks and its format, .cache_packet_formats is added. This is used
by PCM functionality, packet streaming functionality and data block
processing layer.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2017-03-22 05:30:14 -07:00
|
|
|
struct snd_motu_packet_format {
|
2017-03-22 05:30:23 -07:00
|
|
|
unsigned char midi_flag_offset;
|
|
|
|
|
unsigned char midi_byte_offset;
|
ALSA: firewire-motu: add an abstraction layer for three types of protocols
In an aspect of used protocols to communicate, models of MOTU FireWire
units are categorized to three generations.
This commit adds an abstraction layer of the protocols for features
related to packet streaming functionality. This layer includes 5
operations.
When configuring packet streaming functionality with sampling rate and
sampling transmission frequency, .get_clock_rate and .set_clock_rate are
called with proper arguments. MOTU FireWire series supports up to 192.0kHz.
When checking current source of sampling clock (not clock for packetization
layer), .get_clock_source is used. Enumeration is added to represent the
sources supported by this series. This operation can be used to expose
available sampling rate to user space applications when the unit is
configured to use any input signal as source of clock instead of crystal
clock.
In the protocols, the path between packet processing layer and digital
signal processing layer can be controlled. This looks a functionality to
'mute' the unit. For this feature, .switch_fetching_mode is added. This
can be used to suppress noises every time packet streaming starts/stops.
In a point of the size of data blocks at a certain sampling transmission
frequency, the most units accept several modes. This is due to usage of
optical interfaces. The size differs depending on which modes are
configured to the interfaces; None, S/PDIF and ADAT. Additionally, format
of packet is different depending on protocols. To cache current size of
data blocks and its format, .cache_packet_formats is added. This is used
by PCM functionality, packet streaming functionality and data block
processing layer.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2017-03-22 05:30:14 -07:00
|
|
|
unsigned char pcm_byte_offset;
|
|
|
|
|
|
|
|
|
|
unsigned char msg_chunks;
|
2020-05-19 04:16:34 -07:00
|
|
|
unsigned char pcm_chunks[3];
|
ALSA: firewire-motu: add an abstraction layer for three types of protocols
In an aspect of used protocols to communicate, models of MOTU FireWire
units are categorized to three generations.
This commit adds an abstraction layer of the protocols for features
related to packet streaming functionality. This layer includes 5
operations.
When configuring packet streaming functionality with sampling rate and
sampling transmission frequency, .get_clock_rate and .set_clock_rate are
called with proper arguments. MOTU FireWire series supports up to 192.0kHz.
When checking current source of sampling clock (not clock for packetization
layer), .get_clock_source is used. Enumeration is added to represent the
sources supported by this series. This operation can be used to expose
available sampling rate to user space applications when the unit is
configured to use any input signal as source of clock instead of crystal
clock.
In the protocols, the path between packet processing layer and digital
signal processing layer can be controlled. This looks a functionality to
'mute' the unit. For this feature, .switch_fetching_mode is added. This
can be used to suppress noises every time packet streaming starts/stops.
In a point of the size of data blocks at a certain sampling transmission
frequency, the most units accept several modes. This is due to usage of
optical interfaces. The size differs depending on which modes are
configured to the interfaces; None, S/PDIF and ADAT. Additionally, format
of packet is different depending on protocols. To cache current size of
data blocks and its format, .cache_packet_formats is added. This is used
by PCM functionality, packet streaming functionality and data block
processing layer.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2017-03-22 05:30:14 -07:00
|
|
|
};
|
|
|
|
|
|
2021-06-01 18:34:05 -07:00
|
|
|
struct amdtp_motu_cache {
|
|
|
|
|
unsigned int *event_offsets;
|
|
|
|
|
unsigned int size;
|
|
|
|
|
unsigned int tail;
|
|
|
|
|
unsigned int tx_cycle_count;
|
2021-06-01 18:34:06 -07:00
|
|
|
unsigned int head;
|
|
|
|
|
unsigned int rx_cycle_count;
|
2021-06-01 18:34:05 -07:00
|
|
|
};
|
|
|
|
|
|
2017-03-22 05:30:11 -07:00
|
|
|
struct snd_motu {
|
|
|
|
|
struct snd_card *card;
|
|
|
|
|
struct fw_unit *unit;
|
|
|
|
|
struct mutex mutex;
|
2017-03-22 05:30:23 -07:00
|
|
|
spinlock_t lock;
|
2017-03-22 05:30:12 -07:00
|
|
|
|
2017-03-22 05:30:13 -07:00
|
|
|
/* Model dependent information. */
|
|
|
|
|
const struct snd_motu_spec *spec;
|
ALSA: firewire-motu: add an abstraction layer for three types of protocols
In an aspect of used protocols to communicate, models of MOTU FireWire
units are categorized to three generations.
This commit adds an abstraction layer of the protocols for features
related to packet streaming functionality. This layer includes 5
operations.
When configuring packet streaming functionality with sampling rate and
sampling transmission frequency, .get_clock_rate and .set_clock_rate are
called with proper arguments. MOTU FireWire series supports up to 192.0kHz.
When checking current source of sampling clock (not clock for packetization
layer), .get_clock_source is used. Enumeration is added to represent the
sources supported by this series. This operation can be used to expose
available sampling rate to user space applications when the unit is
configured to use any input signal as source of clock instead of crystal
clock.
In the protocols, the path between packet processing layer and digital
signal processing layer can be controlled. This looks a functionality to
'mute' the unit. For this feature, .switch_fetching_mode is added. This
can be used to suppress noises every time packet streaming starts/stops.
In a point of the size of data blocks at a certain sampling transmission
frequency, the most units accept several modes. This is due to usage of
optical interfaces. The size differs depending on which modes are
configured to the interfaces; None, S/PDIF and ADAT. Additionally, format
of packet is different depending on protocols. To cache current size of
data blocks and its format, .cache_packet_formats is added. This is used
by PCM functionality, packet streaming functionality and data block
processing layer.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2017-03-22 05:30:14 -07:00
|
|
|
|
|
|
|
|
/* For packet streaming */
|
|
|
|
|
struct snd_motu_packet_format tx_packet_formats;
|
|
|
|
|
struct snd_motu_packet_format rx_packet_formats;
|
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 05:30:18 -07:00
|
|
|
struct amdtp_stream tx_stream;
|
|
|
|
|
struct amdtp_stream rx_stream;
|
2017-03-22 05:30:20 -07:00
|
|
|
struct fw_iso_resources tx_resources;
|
|
|
|
|
struct fw_iso_resources rx_resources;
|
2019-06-17 01:15:01 -07:00
|
|
|
unsigned int substreams_counter;
|
2017-03-22 05:30:19 -07:00
|
|
|
|
|
|
|
|
/* For notification. */
|
|
|
|
|
struct fw_address_handler async_handler;
|
|
|
|
|
u32 msg;
|
2017-03-22 05:30:24 -07:00
|
|
|
|
|
|
|
|
/* For uapi */
|
|
|
|
|
int dev_lock_count;
|
|
|
|
|
bool dev_lock_changed;
|
|
|
|
|
wait_queue_head_t hwdep_wait;
|
2021-10-15 01:08:25 -07:00
|
|
|
struct snd_hwdep *hwdep;
|
2019-08-03 23:21:36 -07:00
|
|
|
|
|
|
|
|
struct amdtp_domain domain;
|
2021-06-01 18:34:05 -07:00
|
|
|
|
|
|
|
|
struct amdtp_motu_cache cache;
|
2021-10-15 01:08:16 -07:00
|
|
|
|
|
|
|
|
void *message_parser;
|
2017-03-22 05:30:13 -07:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
enum snd_motu_spec_flags {
|
2020-05-19 04:16:38 -07:00
|
|
|
SND_MOTU_SPEC_RX_MIDI_2ND_Q = 0x0001,
|
|
|
|
|
SND_MOTU_SPEC_RX_MIDI_3RD_Q = 0x0002,
|
|
|
|
|
SND_MOTU_SPEC_TX_MIDI_2ND_Q = 0x0004,
|
|
|
|
|
SND_MOTU_SPEC_TX_MIDI_3RD_Q = 0x0008,
|
2021-10-15 01:08:16 -07:00
|
|
|
SND_MOTU_SPEC_REGISTER_DSP = 0x0010,
|
2021-10-15 01:08:17 -07:00
|
|
|
SND_MOTU_SPEC_COMMAND_DSP = 0x0020,
|
2017-03-22 05:30:13 -07:00
|
|
|
};
|
|
|
|
|
|
ALSA: firewire-motu: add an abstraction layer for three types of protocols
In an aspect of used protocols to communicate, models of MOTU FireWire
units are categorized to three generations.
This commit adds an abstraction layer of the protocols for features
related to packet streaming functionality. This layer includes 5
operations.
When configuring packet streaming functionality with sampling rate and
sampling transmission frequency, .get_clock_rate and .set_clock_rate are
called with proper arguments. MOTU FireWire series supports up to 192.0kHz.
When checking current source of sampling clock (not clock for packetization
layer), .get_clock_source is used. Enumeration is added to represent the
sources supported by this series. This operation can be used to expose
available sampling rate to user space applications when the unit is
configured to use any input signal as source of clock instead of crystal
clock.
In the protocols, the path between packet processing layer and digital
signal processing layer can be controlled. This looks a functionality to
'mute' the unit. For this feature, .switch_fetching_mode is added. This
can be used to suppress noises every time packet streaming starts/stops.
In a point of the size of data blocks at a certain sampling transmission
frequency, the most units accept several modes. This is due to usage of
optical interfaces. The size differs depending on which modes are
configured to the interfaces; None, S/PDIF and ADAT. Additionally, format
of packet is different depending on protocols. To cache current size of
data blocks and its format, .cache_packet_formats is added. This is used
by PCM functionality, packet streaming functionality and data block
processing layer.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2017-03-22 05:30:14 -07:00
|
|
|
#define SND_MOTU_CLOCK_RATE_COUNT 6
|
|
|
|
|
extern const unsigned int snd_motu_clock_rates[SND_MOTU_CLOCK_RATE_COUNT];
|
|
|
|
|
|
|
|
|
|
enum snd_motu_clock_source {
|
|
|
|
|
SND_MOTU_CLOCK_SOURCE_INTERNAL,
|
|
|
|
|
SND_MOTU_CLOCK_SOURCE_ADAT_ON_DSUB,
|
|
|
|
|
SND_MOTU_CLOCK_SOURCE_ADAT_ON_OPT,
|
|
|
|
|
SND_MOTU_CLOCK_SOURCE_ADAT_ON_OPT_A,
|
|
|
|
|
SND_MOTU_CLOCK_SOURCE_ADAT_ON_OPT_B,
|
|
|
|
|
SND_MOTU_CLOCK_SOURCE_SPDIF_ON_OPT,
|
|
|
|
|
SND_MOTU_CLOCK_SOURCE_SPDIF_ON_OPT_A,
|
|
|
|
|
SND_MOTU_CLOCK_SOURCE_SPDIF_ON_OPT_B,
|
|
|
|
|
SND_MOTU_CLOCK_SOURCE_SPDIF_ON_COAX,
|
|
|
|
|
SND_MOTU_CLOCK_SOURCE_AESEBU_ON_XLR,
|
|
|
|
|
SND_MOTU_CLOCK_SOURCE_WORD_ON_BNC,
|
2019-10-30 01:06:41 -07:00
|
|
|
SND_MOTU_CLOCK_SOURCE_SPH,
|
ALSA: firewire-motu: add an abstraction layer for three types of protocols
In an aspect of used protocols to communicate, models of MOTU FireWire
units are categorized to three generations.
This commit adds an abstraction layer of the protocols for features
related to packet streaming functionality. This layer includes 5
operations.
When configuring packet streaming functionality with sampling rate and
sampling transmission frequency, .get_clock_rate and .set_clock_rate are
called with proper arguments. MOTU FireWire series supports up to 192.0kHz.
When checking current source of sampling clock (not clock for packetization
layer), .get_clock_source is used. Enumeration is added to represent the
sources supported by this series. This operation can be used to expose
available sampling rate to user space applications when the unit is
configured to use any input signal as source of clock instead of crystal
clock.
In the protocols, the path between packet processing layer and digital
signal processing layer can be controlled. This looks a functionality to
'mute' the unit. For this feature, .switch_fetching_mode is added. This
can be used to suppress noises every time packet streaming starts/stops.
In a point of the size of data blocks at a certain sampling transmission
frequency, the most units accept several modes. This is due to usage of
optical interfaces. The size differs depending on which modes are
configured to the interfaces; None, S/PDIF and ADAT. Additionally, format
of packet is different depending on protocols. To cache current size of
data blocks and its format, .cache_packet_formats is added. This is used
by PCM functionality, packet streaming functionality and data block
processing layer.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2017-03-22 05:30:14 -07:00
|
|
|
SND_MOTU_CLOCK_SOURCE_UNKNOWN,
|
|
|
|
|
};
|
|
|
|
|
|
2020-05-19 04:16:30 -07:00
|
|
|
enum snd_motu_protocol_version {
|
ALSA: firewire-motu: add support for MOTU 828
MOTU 828 is a first model in MOTU FireWire series, produced in 2001. This
model consists of three chips:
* Texas Instruments TSB41AB1 (Physical layer for IEEE 1394 bus)
* Philips Semiconductors 1394L21BE (Link layer for IEEE 1394 bus and
packet processing layer)
* QuickLogic QuickRAM QL4016 (Data block processing layer and digital
signal processing)
This commit adds a support for this model, with its unique protocol as
version 1. The features of this protocol are:
* no MIDI support.
* Rx packets have no data chunks for control and status messages.
* Tx packets have 2 data chunks for control and status messages in the
end of each data block. The chunks consist of data block counter
(4 byte) and message (2 byte).
* All of settings are represented in bit flag in one quadlet address
(0x'ffff'f000'0b00).
* When optical interface is configured as S/PDIF, signals of the interface
is multiplexed for packets, instead of signals of coaxial interface.
* The internal multiplexer is not configured by software.
I note that the device has a quirk to mute output voluntarily during
receiving batch of packets in the beginning of packet streaming. The
operation to unmute should be done by software enough after the device
shifts the state, however it's not deterministic. Furthermore, just
after switching rate of sampling clock, the device keeps the state longer.
This patch manages to sleep 100 msec before unmute operation, but it may
fail to release the mute in the case that the rate is changed. As a
workaround, users can restart packet streaming at the same rate, or write
to specific register from userspace.
$ python3 crpp < /sys/bus/firewire/devices/fw1/config_rom
ROM header and bus information block
-----------------------------------------------------------------
400 04105c54 bus_info_length 4, crc_length 16, crc 23636
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 00005015 device_id 0000005015 | EUI-64 0001f20000005015
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 00035052 directory_length 3, crc 20562
42c 120001f2 specifier id
430 13000001 version
434 17101800 model
eui-64 leaf at 438
-----------------------------------------------------------------
438 0002eeb6 leaf_length 2, crc 61110
43c 0001f200 company_id 0001f2 |
440 00005015 device_id 0000005015 | EUI-64 0001f20000005015
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20210616082847.124688-2-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2021-06-16 01:28:46 -07:00
|
|
|
SND_MOTU_PROTOCOL_V1,
|
2020-05-19 04:16:30 -07:00
|
|
|
SND_MOTU_PROTOCOL_V2,
|
|
|
|
|
SND_MOTU_PROTOCOL_V3,
|
|
|
|
|
};
|
|
|
|
|
|
2017-03-22 05:30:13 -07:00
|
|
|
struct snd_motu_spec {
|
|
|
|
|
const char *const name;
|
2020-05-19 04:16:30 -07:00
|
|
|
enum snd_motu_protocol_version protocol_version;
|
2021-05-18 01:45:48 -07:00
|
|
|
// The combination of snd_motu_spec_flags enumeration-constants.
|
|
|
|
|
unsigned int flags;
|
2017-03-22 05:30:13 -07:00
|
|
|
|
2020-05-19 04:16:33 -07:00
|
|
|
unsigned char tx_fixed_pcm_chunks[3];
|
|
|
|
|
unsigned char rx_fixed_pcm_chunks[3];
|
2017-03-22 05:30:11 -07:00
|
|
|
};
|
|
|
|
|
|
ALSA: firewire-motu: add support for MOTU 828
MOTU 828 is a first model in MOTU FireWire series, produced in 2001. This
model consists of three chips:
* Texas Instruments TSB41AB1 (Physical layer for IEEE 1394 bus)
* Philips Semiconductors 1394L21BE (Link layer for IEEE 1394 bus and
packet processing layer)
* QuickLogic QuickRAM QL4016 (Data block processing layer and digital
signal processing)
This commit adds a support for this model, with its unique protocol as
version 1. The features of this protocol are:
* no MIDI support.
* Rx packets have no data chunks for control and status messages.
* Tx packets have 2 data chunks for control and status messages in the
end of each data block. The chunks consist of data block counter
(4 byte) and message (2 byte).
* All of settings are represented in bit flag in one quadlet address
(0x'ffff'f000'0b00).
* When optical interface is configured as S/PDIF, signals of the interface
is multiplexed for packets, instead of signals of coaxial interface.
* The internal multiplexer is not configured by software.
I note that the device has a quirk to mute output voluntarily during
receiving batch of packets in the beginning of packet streaming. The
operation to unmute should be done by software enough after the device
shifts the state, however it's not deterministic. Furthermore, just
after switching rate of sampling clock, the device keeps the state longer.
This patch manages to sleep 100 msec before unmute operation, but it may
fail to release the mute in the case that the rate is changed. As a
workaround, users can restart packet streaming at the same rate, or write
to specific register from userspace.
$ python3 crpp < /sys/bus/firewire/devices/fw1/config_rom
ROM header and bus information block
-----------------------------------------------------------------
400 04105c54 bus_info_length 4, crc_length 16, crc 23636
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 00005015 device_id 0000005015 | EUI-64 0001f20000005015
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 00035052 directory_length 3, crc 20562
42c 120001f2 specifier id
430 13000001 version
434 17101800 model
eui-64 leaf at 438
-----------------------------------------------------------------
438 0002eeb6 leaf_length 2, crc 61110
43c 0001f200 company_id 0001f2 |
440 00005015 device_id 0000005015 | EUI-64 0001f20000005015
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20210616082847.124688-2-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2021-06-16 01:28:46 -07:00
|
|
|
extern const struct snd_motu_spec snd_motu_spec_828;
|
ALSA: firewire-motu: add support for MOTU 896
MOTU 896 is a second model in MOTU FireWire series, produced in 2001. This
model consists of three chips:
* Texas Instruments TSB41AB2 (Physical layer for IEEE 1394 bus)
* Philips Semiconductors PDI 1394L21BE (Link layer for IEEE 1394 bus and
packet processing layer)
* QuickLogic QuickRAM QL4016 (Data block processing layer and digital
signal processing)
This commit adds a support for the model, with its unique protocol as
version 1. The features of this protocol are:
* no MIDI support.
* Rx packets have no data chunks for control and status messages.
* Tx packets have 2 bytes for control and status messages in the end of
each data block.
* The most of settings are represented in bit flag in one quadlet address
(0x'ffff'f000'0b14).
* It's selectable to use signal on optical interface, however the device
has no register specific to it. The state has effect just to whether
to exclude differed data chunks.
* The internal multiplexer is not configured by software.
Just after powering on, the device has a quirk to fail handling
transaction. I recommend users to connect the device enough after powering
on.
$ python3 crpp < /sys/bus/firewire/devices/fw1/config_rom
ROM header and bus information block
-----------------------------------------------------------------
400 04102814 bus_info_length 4, crc_length 16, crc 10260
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 0000d645 device_id 000000d645 | EUI-64 0001f2000000d645
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 0003ab34 directory_length 3, crc 43828
42c 120001f2 specifier id
430 13000002 version
434 17102801 model
eui-64 leaf at 438
-----------------------------------------------------------------
438 0002057d leaf_length 2, crc 1405
43c 0001f200 company_id 0001f2 |
440 0000d645 device_id 000000d645 | EUI-64 0001f2000000d645
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20210616082847.124688-3-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2021-06-16 01:28:47 -07:00
|
|
|
extern const struct snd_motu_spec snd_motu_spec_896;
|
ALSA: firewire-motu: add support for MOTU 828
MOTU 828 is a first model in MOTU FireWire series, produced in 2001. This
model consists of three chips:
* Texas Instruments TSB41AB1 (Physical layer for IEEE 1394 bus)
* Philips Semiconductors 1394L21BE (Link layer for IEEE 1394 bus and
packet processing layer)
* QuickLogic QuickRAM QL4016 (Data block processing layer and digital
signal processing)
This commit adds a support for this model, with its unique protocol as
version 1. The features of this protocol are:
* no MIDI support.
* Rx packets have no data chunks for control and status messages.
* Tx packets have 2 data chunks for control and status messages in the
end of each data block. The chunks consist of data block counter
(4 byte) and message (2 byte).
* All of settings are represented in bit flag in one quadlet address
(0x'ffff'f000'0b00).
* When optical interface is configured as S/PDIF, signals of the interface
is multiplexed for packets, instead of signals of coaxial interface.
* The internal multiplexer is not configured by software.
I note that the device has a quirk to mute output voluntarily during
receiving batch of packets in the beginning of packet streaming. The
operation to unmute should be done by software enough after the device
shifts the state, however it's not deterministic. Furthermore, just
after switching rate of sampling clock, the device keeps the state longer.
This patch manages to sleep 100 msec before unmute operation, but it may
fail to release the mute in the case that the rate is changed. As a
workaround, users can restart packet streaming at the same rate, or write
to specific register from userspace.
$ python3 crpp < /sys/bus/firewire/devices/fw1/config_rom
ROM header and bus information block
-----------------------------------------------------------------
400 04105c54 bus_info_length 4, crc_length 16, crc 23636
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 00005015 device_id 0000005015 | EUI-64 0001f20000005015
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 00035052 directory_length 3, crc 20562
42c 120001f2 specifier id
430 13000001 version
434 17101800 model
eui-64 leaf at 438
-----------------------------------------------------------------
438 0002eeb6 leaf_length 2, crc 61110
43c 0001f200 company_id 0001f2 |
440 00005015 device_id 0000005015 | EUI-64 0001f20000005015
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20210616082847.124688-2-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2021-06-16 01:28:46 -07:00
|
|
|
|
2019-10-30 01:06:43 -07:00
|
|
|
extern const struct snd_motu_spec snd_motu_spec_828mk2;
|
ALSA: firewire-motu: add support for MOTU 896HD
Mark of the Unicorn (MOTU) shipped 896HD 2003 as one of models in second
generation of its FireWire series, and already discontinued it. The model
consists of below ICs:
* Texas Instruments TSB41AB2
* Phillips Semiconductors PDI1394L40
* Altera cyclone EP1C3
* Texas Instruments TMS320VC5402
It supports sampling transmission frequency up to 192.0 kHz. The packet
format differs depending on both of sampling transfer frequency and enabling
ADAT channels. The model doesn't support MIDI message transmission.
This commit adds support for it.
$ python3 crpp < /sys/bus/firewire/devices/fw1/config_rom
ROM header and bus information block
-----------------------------------------------------------------
400 04101b66 bus_info_length 4, crc_length 16, crc 7014
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 0001dbce device_id 000001dbce | EUI-64 0001f2000001dbce
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 0003dcc1 directory_length 3, crc 56513
42c 120001f2 specifier id
430 13000005 version
434 17102800 model
eui-64 leaf at 438
-----------------------------------------------------------------
438 000264f2 leaf_length 2, crc 25842
43c 0001f200 company_id 0001f2 |
440 0001dbce device_id 000001dbce | EUI-64 0001f2000001dbce
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20210823085741.33864-1-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2021-08-23 01:57:41 -07:00
|
|
|
extern const struct snd_motu_spec snd_motu_spec_896hd;
|
2020-05-19 04:16:28 -07:00
|
|
|
extern const struct snd_motu_spec snd_motu_spec_traveler;
|
|
|
|
|
extern const struct snd_motu_spec snd_motu_spec_ultralite;
|
|
|
|
|
extern const struct snd_motu_spec snd_motu_spec_8pre;
|
ALSA: firewire-motu: add support for Motu Traveler
This commit adds support for MOTU Traveler, launched in 2005, discontinued
quite before. As a result, transmission of PCM frame and MIDI messages is
available via ALSA PCM and RawMIDI/Sequencer interfaces.
This model supports sampling transmission frequency up to 192.0 kHz, and
AES/EBU on XLR interface and ADAT on optical interface. Unlike
Motu 828MkII, Windows driver can switch fetching mode for DSP, like
mute/unmute feature.
Although this commit enables high sampling transmission frequency, actual
sound from this model is not good. As long as I tested, it's silence at
176.4 kHz, and it includes hissing noise at 192.0 kHz. In my opinion, as I
reported at 3526ce7f9ba7 ('ALSA: firewire-motu: add MOTU specific protocol
layer'), timestamping on source packet header (SPH) may not still be good
for this model as well.
$ python2 crpp < /sys/bus/firewire/devices/fw1/config_rom
ROM header and bus information block
-----------------------------------------------------------------
400 04106505 bus_info_length 4, crc_length 16, crc 25861
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 0001f32f device_id 000001f32f | EUI-64 0001f2000001f32f
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 00035955 directory_length 3, crc 22869
42c 120001f2 specifier id
430 13000009 version
434 17107800 model
eui-64 leaf at 438
-----------------------------------------------------------------
438 000206b2 leaf_length 2, crc 1714
43c 0001f200 company_id 0001f2 |
440 0001f32f device_id 000001f32f | EUI-64 0001f2000001f32f
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2018-06-18 05:07:55 -07:00
|
|
|
|
2021-06-17 21:07:13 -07:00
|
|
|
extern const struct snd_motu_spec snd_motu_spec_828mk3_fw;
|
|
|
|
|
extern const struct snd_motu_spec snd_motu_spec_828mk3_hybrid;
|
ALSA: firewire-motu: add support for MOTU 896 mk3 FireWire and Hybrid
Mark of the Unicorn released 896 mk3 FireWire in 2008 as part of the third
generation of its FireWire series. In 2011, 896 mk3 hybrid was released to
support USB protocol.
It supports sampling transfer frequency up to 192.0 kHz. The packet
format differs depending on both of current sampling transfer frequency
and the type of signal in optical interfaces. The model supports
transmission of PCM frames as well as MIDI messages.
The 896 mk3 FireWire consists of below ICs:
* Texas Instruments TSB41AB2
* Xilinx Spartan-3A FPGA, XC3S500E
* Texas Instruments TMS320C6722
* Microchip (Atmel) AT91SAM SAM7S256
It supports sampling transfer frequency up to 192.0 kHz. The packet
format differs depending on both of current sampling transfer frequency
and the type of signal in two pairs of optical interfaces. The model
supports transmission of PCM frames, while has no port for MIDi messages.
The model supports command mechanism to configure internal DSP. Hardware
meter information is available in the first 2 chunks of each data block
of tx packet.
This commit adds support for it. The 896 mk3 FireWire is just tested, but
the 896 mk3 Hybrid is not yet.
$ config-rom-pretty-printer < motu-896mk3fw.img
ROM header and bus information block
-----------------------------------------------------------------
1024 04100ce1 bus_info_length 4, crc_length 16, crc 3297
1028 31333934 bus_name "1394"
1032 20ff7000 irmc 0, cmc 0, isc 1, bmc 0, cyc_clk_acc 255, max_rec 7 (256)
1036 0001f200 company_id 0001f2 |
1040 00093add device_id 0000604893 | EUI-64 0547556791237341
root directory
-----------------------------------------------------------------
1044 0004ef04 directory_length 4, crc 61188
1048 030001f2 vendor
1052 0c0083c0 node capabilities: per IEEE 1394
1056 d1000002 --> unit directory at 1064
1060 8d000005 --> eui-64 leaf at 1080
unit directory at 1064
-----------------------------------------------------------------
1064 0003998d directory_length 3, crc 39309
1068 120001f2 specifier id
1072 13000017 version
1076 17101800 model
eui-64 leaf at 1080
-----------------------------------------------------------------
1080 0002cc82 leaf_length 2, crc 52354
1084 0001f200 company_id 0001f2 |
1088 00093add device_id 0000604893 | EUI-64 0547556791237341
$ config-rom-pretty-printer < motu-896mk3hybrid.img
ROM header and bus information block
-----------------------------------------------------------------
1024 04103cbe bus_info_length 4, crc_length 16, crc 15550
1028 31333934 bus_name "1394"
1032 20ff7000 irmc 0, cmc 0, isc 1, bmc 0, cyc_clk_acc 255, max_rec 7 (256)
1036 0001f200 company_id 0001f2 |
1040 000ae601 device_id 0000714241 | EUI-64 0547556791346689
root directory
-----------------------------------------------------------------
1044 0004ef04 directory_length 4, crc 61188
1048 030001f2 vendor
1052 0c0083c0 node capabilities: per IEEE 1394
1056 d1000002 --> unit directory at 1064
1060 8d000005 --> eui-64 leaf at 1080
unit directory at 1064
-----------------------------------------------------------------
1064 000394ac directory_length 3, crc 38060
1068 120001f2 specifier id
1072 13000037 version
1076 17102800 model
eui-64 leaf at 1080
-----------------------------------------------------------------
1080 0002cf69 leaf_length 2, crc 53097
1084 0001f200 company_id 0001f2 |
1088 000ae601 device_id 0000714241 | EUI-64 0547556791346689
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20240129022711.254383-1-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2024-01-28 19:27:11 -07:00
|
|
|
extern const struct snd_motu_spec snd_motu_spec_896mk3;
|
ALSA: firewire-motu: add support for MOTU Traveler mk3
Mark of the Unicorn (MOTU) shipped Traveler mk3 as one of models in third
generation of its FireWire series, and discontinued it already. The model
consists of below ICs:
* Texas Instruments TSB41AB2
* Phillips Semiconductors PDI1394L40
* Altera cyclone EP1C3
* Texas Instruments TMS320VC5402
It supports sampling transfer frequency up to 192.0 kHz. The packet
format differs depending on both of current sampling transfer frequency
and whether to enable ADAT channels in rx/tx packets. The model supports
transmission of PCM frames as well as MIDI messages.
The model supports command mechanism to configure internal DSP. Hardware
meter information is available in the first 2 chunks of each data block
of tx packet.
This commit adds support for it.
$ cd linux-firewire-tools/src
$ python crpp < /sys/bus/firewire/devices/fw1/config_rom
ROM header and bus information block
-----------------------------------------------------------------
400 0410af0a bus_info_length 4, crc_length 16, crc 44810
404 31333934 bus_name "1394"
408 20ff7000 irmc 0, cmc 0, isc 1, bmc 0, cyc_clk_acc 255, max_rec 7 (256)
40c 0001f200 company_id 0001f2 |
410 00090911 device_id 0000090911 | EUI-64 0001f20000090911
root directory
-----------------------------------------------------------------
414 0004ef04 directory_length 4, crc 61188
418 030001f2 vendor
41c 0c0083c0 node capabilities per IEEE 1394
420 d1000002 --> unit directory at 428
424 8d000005 --> eui-64 leaf at 438
unit directory at 428
-----------------------------------------------------------------
428 00031733 directory_length 3, crc 5939
42c 120001f2 specifier id
430 1300001b version
434 17102800 model
eui-64 leaf at 438
-----------------------------------------------------------------
438 00028484 leaf_length 2, crc 33924
43c 0001f200 company_id 0001f2 |
440 00090911 device_id 0000090911 | EUI-64 0001f20000090911
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20211104110627.94469-1-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2021-11-04 04:06:27 -07:00
|
|
|
extern const struct snd_motu_spec snd_motu_spec_traveler_mk3;
|
ALSA: firewire-motu: add support for MOTU UltraLite-mk3 (FireWire only model)
UltraLite-mk3 was shipped 2008 by MOTU. This model has two lineups;
FireWire-only and FireWire/USB2.0 Hybrid model. Additionally, the latter
has two variants in respect of the type of IEEE 1394 connector; alpha
and beta connector.
This commit adds support for the FireWire-only model, which is already
discontinued.
$ python3 crpp < /sys/bus/firewire/devices/fw1/config_rom
ROM header and bus information block
-----------------------------------------------------------------
400 0410353a bus_info_length 4, crc_length 16, crc 13626
404 31333934 bus_name "1394"
408 20ff7000 irmc 0, cmc 0, isc 1, bmc 0, cyc_clk_acc 255, max_rec 7 (256)
40c 0001f200 company_id 0001f2 |
410 000902c7 device_id 00000902c7 | EUI-64 0001f200000902c7
root directory
-----------------------------------------------------------------
414 0004ef04 directory_length 4, crc 61188
418 030001f2 vendor
41c 0c0083c0 node capabilities per IEEE 1394
420 d1000002 --> unit directory at 428
424 8d000005 --> eui-64 leaf at 438
unit directory at 428
-----------------------------------------------------------------
428 00035556 directory_length 3, crc 21846
42c 120001f2 specifier id
430 13000019 version
434 17100800 model
eui-64 leaf at 438
-----------------------------------------------------------------
438 0002f3c5 leaf_length 2, crc 62405
43c 0001f200 company_id 0001f2 |
440 000902c7 device_id 00000902c7 | EUI-64 0001f200000902c7
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20200523071733.170129-1-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2020-05-23 00:17:33 -07:00
|
|
|
extern const struct snd_motu_spec snd_motu_spec_ultralite_mk3;
|
2020-05-19 04:16:29 -07:00
|
|
|
extern const struct snd_motu_spec snd_motu_spec_audio_express;
|
ALSA: firewire-motu: add support for MOTU Track 16
Mark of the Unicorn designed Track 16 2011 as one of models in third
generation of its FireWire series. The model is already discontinued.
It consists of below ICs:
* Texas Instruments TSB41AB1
* Microchip (SMSC) USB3300
* Xilinx Spartan-3A FPGA, XC3S700A
* Texas Instruments TMS320C6722
* Microchip (Atmel) AT91SAM SAM7S512
It supports sampling transfer frequency up to 192.0 kHz. The packet
format differs depending on both of current sampling transfer frequency
and the type of signal in optical interfaces. The model supports
transmission of PCM frames as well as MIDI messages.
The model supports command mechanism to configure internal DSP. Hardware
meter information is available in the first 2 chunks of each data block
of tx packet.
This commit adds support for it.
$ cd linux-firewire-tools/src
$ python crpp < /sys/bus/firewire/devices/fw1/config_rom
ROM header and bus information block
-----------------------------------------------------------------
400 04107d95 bus_info_length 4, crc_length 16, crc 32149
404 31333934 bus_name "1394"
408 20ff7000 irmc 0, cmc 0, isc 1, bmc 0, cyc_clk_acc 255, max_rec 7 (256)
40c 0001f200 company_id 0001f2 |
410 000a83c4 device_id 00000a83c4 | EUI-64 0001f200000a83c4
root directory
-----------------------------------------------------------------
414 0004ef04 directory_length 4, crc 61188
418 030001f2 vendor
41c 0c0083c0 node capabilities per IEEE 1394
420 d1000002 --> unit directory at 428
424 8d000005 --> eui-64 leaf at 438
unit directory at 428
-----------------------------------------------------------------
428 00035b04 directory_length 3, crc 23300
42c 120001f2 specifier id
430 13000039 version
434 17102800 model
eui-64 leaf at 438
-----------------------------------------------------------------
438 0002b25f leaf_length 2, crc 45663
43c 0001f200 company_id 0001f2 |
440 000a83c4 device_id 00000a83c4 | EUI-64 0001f200000a83c4
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20211107110644.23511-1-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2021-11-07 04:06:44 -07:00
|
|
|
extern const struct snd_motu_spec snd_motu_spec_track16;
|
2020-05-19 04:16:29 -07:00
|
|
|
extern const struct snd_motu_spec snd_motu_spec_4pre;
|
|
|
|
|
|
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 05:30:18 -07:00
|
|
|
int amdtp_motu_init(struct amdtp_stream *s, struct fw_unit *unit,
|
|
|
|
|
enum amdtp_stream_direction dir,
|
2021-06-01 18:34:05 -07:00
|
|
|
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 05:30:18 -07:00
|
|
|
int amdtp_motu_set_parameters(struct amdtp_stream *s, unsigned int rate,
|
2017-03-22 05:30:23 -07:00
|
|
|
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 05:30:18 -07:00
|
|
|
struct snd_motu_packet_format *formats);
|
|
|
|
|
int amdtp_motu_add_pcm_hw_constraints(struct amdtp_stream *s,
|
|
|
|
|
struct snd_pcm_runtime *runtime);
|
2017-03-22 05:30:23 -07:00
|
|
|
void amdtp_motu_midi_trigger(struct amdtp_stream *s, unsigned int port,
|
|
|
|
|
struct snd_rawmidi_substream *midi);
|
2017-03-22 05:30:19 -07:00
|
|
|
|
|
|
|
|
int snd_motu_transaction_read(struct snd_motu *motu, u32 offset, __be32 *reg,
|
|
|
|
|
size_t size);
|
|
|
|
|
int snd_motu_transaction_write(struct snd_motu *motu, u32 offset, __be32 *reg,
|
|
|
|
|
size_t size);
|
|
|
|
|
int snd_motu_transaction_register(struct snd_motu *motu);
|
|
|
|
|
int snd_motu_transaction_reregister(struct snd_motu *motu);
|
|
|
|
|
void snd_motu_transaction_unregister(struct snd_motu *motu);
|
2017-03-22 05:30:20 -07:00
|
|
|
|
|
|
|
|
int snd_motu_stream_init_duplex(struct snd_motu *motu);
|
|
|
|
|
void snd_motu_stream_destroy_duplex(struct snd_motu *motu);
|
2017-08-20 05:25:03 -07:00
|
|
|
int snd_motu_stream_cache_packet_formats(struct snd_motu *motu);
|
2019-10-07 04:05:23 -07:00
|
|
|
int snd_motu_stream_reserve_duplex(struct snd_motu *motu, unsigned int rate,
|
2019-10-17 08:54:20 -07:00
|
|
|
unsigned int frames_per_period,
|
|
|
|
|
unsigned int frames_per_buffer);
|
2019-06-17 01:15:08 -07:00
|
|
|
int snd_motu_stream_start_duplex(struct snd_motu *motu);
|
2017-03-22 05:30:20 -07:00
|
|
|
void snd_motu_stream_stop_duplex(struct snd_motu *motu);
|
2017-03-22 05:30:24 -07:00
|
|
|
int snd_motu_stream_lock_try(struct snd_motu *motu);
|
|
|
|
|
void snd_motu_stream_lock_release(struct snd_motu *motu);
|
2017-03-22 05:30:21 -07:00
|
|
|
|
|
|
|
|
void snd_motu_proc_init(struct snd_motu *motu);
|
2017-03-22 05:30:22 -07:00
|
|
|
|
|
|
|
|
int snd_motu_create_pcm_devices(struct snd_motu *motu);
|
2017-03-22 05:30:23 -07:00
|
|
|
|
|
|
|
|
int snd_motu_create_midi_devices(struct snd_motu *motu);
|
2017-03-22 05:30:24 -07:00
|
|
|
|
|
|
|
|
int snd_motu_create_hwdep_device(struct snd_motu *motu);
|
2020-05-19 04:16:31 -07:00
|
|
|
|
ALSA: firewire-motu: add support for MOTU 828
MOTU 828 is a first model in MOTU FireWire series, produced in 2001. This
model consists of three chips:
* Texas Instruments TSB41AB1 (Physical layer for IEEE 1394 bus)
* Philips Semiconductors 1394L21BE (Link layer for IEEE 1394 bus and
packet processing layer)
* QuickLogic QuickRAM QL4016 (Data block processing layer and digital
signal processing)
This commit adds a support for this model, with its unique protocol as
version 1. The features of this protocol are:
* no MIDI support.
* Rx packets have no data chunks for control and status messages.
* Tx packets have 2 data chunks for control and status messages in the
end of each data block. The chunks consist of data block counter
(4 byte) and message (2 byte).
* All of settings are represented in bit flag in one quadlet address
(0x'ffff'f000'0b00).
* When optical interface is configured as S/PDIF, signals of the interface
is multiplexed for packets, instead of signals of coaxial interface.
* The internal multiplexer is not configured by software.
I note that the device has a quirk to mute output voluntarily during
receiving batch of packets in the beginning of packet streaming. The
operation to unmute should be done by software enough after the device
shifts the state, however it's not deterministic. Furthermore, just
after switching rate of sampling clock, the device keeps the state longer.
This patch manages to sleep 100 msec before unmute operation, but it may
fail to release the mute in the case that the rate is changed. As a
workaround, users can restart packet streaming at the same rate, or write
to specific register from userspace.
$ python3 crpp < /sys/bus/firewire/devices/fw1/config_rom
ROM header and bus information block
-----------------------------------------------------------------
400 04105c54 bus_info_length 4, crc_length 16, crc 23636
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 00005015 device_id 0000005015 | EUI-64 0001f20000005015
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 00035052 directory_length 3, crc 20562
42c 120001f2 specifier id
430 13000001 version
434 17101800 model
eui-64 leaf at 438
-----------------------------------------------------------------
438 0002eeb6 leaf_length 2, crc 61110
43c 0001f200 company_id 0001f2 |
440 00005015 device_id 0000005015 | EUI-64 0001f20000005015
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20210616082847.124688-2-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2021-06-16 01:28:46 -07:00
|
|
|
int snd_motu_protocol_v1_get_clock_rate(struct snd_motu *motu,
|
|
|
|
|
unsigned int *rate);
|
|
|
|
|
int snd_motu_protocol_v1_set_clock_rate(struct snd_motu *motu,
|
|
|
|
|
unsigned int rate);
|
|
|
|
|
int snd_motu_protocol_v1_get_clock_source(struct snd_motu *motu,
|
|
|
|
|
enum snd_motu_clock_source *src);
|
|
|
|
|
int snd_motu_protocol_v1_switch_fetching_mode(struct snd_motu *motu,
|
|
|
|
|
bool enable);
|
|
|
|
|
int snd_motu_protocol_v1_cache_packet_formats(struct snd_motu *motu);
|
|
|
|
|
|
2020-05-19 04:16:31 -07:00
|
|
|
int snd_motu_protocol_v2_get_clock_rate(struct snd_motu *motu,
|
|
|
|
|
unsigned int *rate);
|
|
|
|
|
int snd_motu_protocol_v2_set_clock_rate(struct snd_motu *motu,
|
|
|
|
|
unsigned int rate);
|
|
|
|
|
int snd_motu_protocol_v2_get_clock_source(struct snd_motu *motu,
|
|
|
|
|
enum snd_motu_clock_source *src);
|
|
|
|
|
int snd_motu_protocol_v2_switch_fetching_mode(struct snd_motu *motu,
|
|
|
|
|
bool enable);
|
|
|
|
|
int snd_motu_protocol_v2_cache_packet_formats(struct snd_motu *motu);
|
|
|
|
|
|
|
|
|
|
int snd_motu_protocol_v3_get_clock_rate(struct snd_motu *motu,
|
|
|
|
|
unsigned int *rate);
|
|
|
|
|
int snd_motu_protocol_v3_set_clock_rate(struct snd_motu *motu,
|
|
|
|
|
unsigned int rate);
|
|
|
|
|
int snd_motu_protocol_v3_get_clock_source(struct snd_motu *motu,
|
|
|
|
|
enum snd_motu_clock_source *src);
|
|
|
|
|
int snd_motu_protocol_v3_switch_fetching_mode(struct snd_motu *motu,
|
|
|
|
|
bool enable);
|
|
|
|
|
int snd_motu_protocol_v3_cache_packet_formats(struct snd_motu *motu);
|
|
|
|
|
|
|
|
|
|
static inline int snd_motu_protocol_get_clock_rate(struct snd_motu *motu,
|
|
|
|
|
unsigned int *rate)
|
|
|
|
|
{
|
|
|
|
|
if (motu->spec->protocol_version == SND_MOTU_PROTOCOL_V2)
|
|
|
|
|
return snd_motu_protocol_v2_get_clock_rate(motu, rate);
|
|
|
|
|
else if (motu->spec->protocol_version == SND_MOTU_PROTOCOL_V3)
|
|
|
|
|
return snd_motu_protocol_v3_get_clock_rate(motu, rate);
|
ALSA: firewire-motu: add support for MOTU 828
MOTU 828 is a first model in MOTU FireWire series, produced in 2001. This
model consists of three chips:
* Texas Instruments TSB41AB1 (Physical layer for IEEE 1394 bus)
* Philips Semiconductors 1394L21BE (Link layer for IEEE 1394 bus and
packet processing layer)
* QuickLogic QuickRAM QL4016 (Data block processing layer and digital
signal processing)
This commit adds a support for this model, with its unique protocol as
version 1. The features of this protocol are:
* no MIDI support.
* Rx packets have no data chunks for control and status messages.
* Tx packets have 2 data chunks for control and status messages in the
end of each data block. The chunks consist of data block counter
(4 byte) and message (2 byte).
* All of settings are represented in bit flag in one quadlet address
(0x'ffff'f000'0b00).
* When optical interface is configured as S/PDIF, signals of the interface
is multiplexed for packets, instead of signals of coaxial interface.
* The internal multiplexer is not configured by software.
I note that the device has a quirk to mute output voluntarily during
receiving batch of packets in the beginning of packet streaming. The
operation to unmute should be done by software enough after the device
shifts the state, however it's not deterministic. Furthermore, just
after switching rate of sampling clock, the device keeps the state longer.
This patch manages to sleep 100 msec before unmute operation, but it may
fail to release the mute in the case that the rate is changed. As a
workaround, users can restart packet streaming at the same rate, or write
to specific register from userspace.
$ python3 crpp < /sys/bus/firewire/devices/fw1/config_rom
ROM header and bus information block
-----------------------------------------------------------------
400 04105c54 bus_info_length 4, crc_length 16, crc 23636
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 00005015 device_id 0000005015 | EUI-64 0001f20000005015
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 00035052 directory_length 3, crc 20562
42c 120001f2 specifier id
430 13000001 version
434 17101800 model
eui-64 leaf at 438
-----------------------------------------------------------------
438 0002eeb6 leaf_length 2, crc 61110
43c 0001f200 company_id 0001f2 |
440 00005015 device_id 0000005015 | EUI-64 0001f20000005015
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20210616082847.124688-2-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2021-06-16 01:28:46 -07:00
|
|
|
else if (motu->spec->protocol_version == SND_MOTU_PROTOCOL_V1)
|
|
|
|
|
return snd_motu_protocol_v1_get_clock_rate(motu, rate);
|
2020-05-19 04:16:31 -07:00
|
|
|
else
|
|
|
|
|
return -ENXIO;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static inline int snd_motu_protocol_set_clock_rate(struct snd_motu *motu,
|
|
|
|
|
unsigned int rate)
|
|
|
|
|
{
|
|
|
|
|
if (motu->spec->protocol_version == SND_MOTU_PROTOCOL_V2)
|
|
|
|
|
return snd_motu_protocol_v2_set_clock_rate(motu, rate);
|
|
|
|
|
else if (motu->spec->protocol_version == SND_MOTU_PROTOCOL_V3)
|
|
|
|
|
return snd_motu_protocol_v3_set_clock_rate(motu, rate);
|
ALSA: firewire-motu: add support for MOTU 828
MOTU 828 is a first model in MOTU FireWire series, produced in 2001. This
model consists of three chips:
* Texas Instruments TSB41AB1 (Physical layer for IEEE 1394 bus)
* Philips Semiconductors 1394L21BE (Link layer for IEEE 1394 bus and
packet processing layer)
* QuickLogic QuickRAM QL4016 (Data block processing layer and digital
signal processing)
This commit adds a support for this model, with its unique protocol as
version 1. The features of this protocol are:
* no MIDI support.
* Rx packets have no data chunks for control and status messages.
* Tx packets have 2 data chunks for control and status messages in the
end of each data block. The chunks consist of data block counter
(4 byte) and message (2 byte).
* All of settings are represented in bit flag in one quadlet address
(0x'ffff'f000'0b00).
* When optical interface is configured as S/PDIF, signals of the interface
is multiplexed for packets, instead of signals of coaxial interface.
* The internal multiplexer is not configured by software.
I note that the device has a quirk to mute output voluntarily during
receiving batch of packets in the beginning of packet streaming. The
operation to unmute should be done by software enough after the device
shifts the state, however it's not deterministic. Furthermore, just
after switching rate of sampling clock, the device keeps the state longer.
This patch manages to sleep 100 msec before unmute operation, but it may
fail to release the mute in the case that the rate is changed. As a
workaround, users can restart packet streaming at the same rate, or write
to specific register from userspace.
$ python3 crpp < /sys/bus/firewire/devices/fw1/config_rom
ROM header and bus information block
-----------------------------------------------------------------
400 04105c54 bus_info_length 4, crc_length 16, crc 23636
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 00005015 device_id 0000005015 | EUI-64 0001f20000005015
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 00035052 directory_length 3, crc 20562
42c 120001f2 specifier id
430 13000001 version
434 17101800 model
eui-64 leaf at 438
-----------------------------------------------------------------
438 0002eeb6 leaf_length 2, crc 61110
43c 0001f200 company_id 0001f2 |
440 00005015 device_id 0000005015 | EUI-64 0001f20000005015
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20210616082847.124688-2-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2021-06-16 01:28:46 -07:00
|
|
|
else if (motu->spec->protocol_version == SND_MOTU_PROTOCOL_V1)
|
|
|
|
|
return snd_motu_protocol_v1_set_clock_rate(motu, rate);
|
2020-05-19 04:16:31 -07:00
|
|
|
else
|
|
|
|
|
return -ENXIO;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static inline int snd_motu_protocol_get_clock_source(struct snd_motu *motu,
|
|
|
|
|
enum snd_motu_clock_source *source)
|
|
|
|
|
{
|
|
|
|
|
if (motu->spec->protocol_version == SND_MOTU_PROTOCOL_V2)
|
|
|
|
|
return snd_motu_protocol_v2_get_clock_source(motu, source);
|
|
|
|
|
else if (motu->spec->protocol_version == SND_MOTU_PROTOCOL_V3)
|
|
|
|
|
return snd_motu_protocol_v3_get_clock_source(motu, source);
|
ALSA: firewire-motu: add support for MOTU 828
MOTU 828 is a first model in MOTU FireWire series, produced in 2001. This
model consists of three chips:
* Texas Instruments TSB41AB1 (Physical layer for IEEE 1394 bus)
* Philips Semiconductors 1394L21BE (Link layer for IEEE 1394 bus and
packet processing layer)
* QuickLogic QuickRAM QL4016 (Data block processing layer and digital
signal processing)
This commit adds a support for this model, with its unique protocol as
version 1. The features of this protocol are:
* no MIDI support.
* Rx packets have no data chunks for control and status messages.
* Tx packets have 2 data chunks for control and status messages in the
end of each data block. The chunks consist of data block counter
(4 byte) and message (2 byte).
* All of settings are represented in bit flag in one quadlet address
(0x'ffff'f000'0b00).
* When optical interface is configured as S/PDIF, signals of the interface
is multiplexed for packets, instead of signals of coaxial interface.
* The internal multiplexer is not configured by software.
I note that the device has a quirk to mute output voluntarily during
receiving batch of packets in the beginning of packet streaming. The
operation to unmute should be done by software enough after the device
shifts the state, however it's not deterministic. Furthermore, just
after switching rate of sampling clock, the device keeps the state longer.
This patch manages to sleep 100 msec before unmute operation, but it may
fail to release the mute in the case that the rate is changed. As a
workaround, users can restart packet streaming at the same rate, or write
to specific register from userspace.
$ python3 crpp < /sys/bus/firewire/devices/fw1/config_rom
ROM header and bus information block
-----------------------------------------------------------------
400 04105c54 bus_info_length 4, crc_length 16, crc 23636
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 00005015 device_id 0000005015 | EUI-64 0001f20000005015
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 00035052 directory_length 3, crc 20562
42c 120001f2 specifier id
430 13000001 version
434 17101800 model
eui-64 leaf at 438
-----------------------------------------------------------------
438 0002eeb6 leaf_length 2, crc 61110
43c 0001f200 company_id 0001f2 |
440 00005015 device_id 0000005015 | EUI-64 0001f20000005015
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20210616082847.124688-2-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2021-06-16 01:28:46 -07:00
|
|
|
else if (motu->spec->protocol_version == SND_MOTU_PROTOCOL_V1)
|
|
|
|
|
return snd_motu_protocol_v1_get_clock_source(motu, source);
|
2020-05-19 04:16:31 -07:00
|
|
|
else
|
|
|
|
|
return -ENXIO;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static inline int snd_motu_protocol_switch_fetching_mode(struct snd_motu *motu,
|
|
|
|
|
bool enable)
|
|
|
|
|
{
|
|
|
|
|
if (motu->spec->protocol_version == SND_MOTU_PROTOCOL_V2)
|
|
|
|
|
return snd_motu_protocol_v2_switch_fetching_mode(motu, enable);
|
|
|
|
|
else if (motu->spec->protocol_version == SND_MOTU_PROTOCOL_V3)
|
|
|
|
|
return snd_motu_protocol_v3_switch_fetching_mode(motu, enable);
|
ALSA: firewire-motu: add support for MOTU 828
MOTU 828 is a first model in MOTU FireWire series, produced in 2001. This
model consists of three chips:
* Texas Instruments TSB41AB1 (Physical layer for IEEE 1394 bus)
* Philips Semiconductors 1394L21BE (Link layer for IEEE 1394 bus and
packet processing layer)
* QuickLogic QuickRAM QL4016 (Data block processing layer and digital
signal processing)
This commit adds a support for this model, with its unique protocol as
version 1. The features of this protocol are:
* no MIDI support.
* Rx packets have no data chunks for control and status messages.
* Tx packets have 2 data chunks for control and status messages in the
end of each data block. The chunks consist of data block counter
(4 byte) and message (2 byte).
* All of settings are represented in bit flag in one quadlet address
(0x'ffff'f000'0b00).
* When optical interface is configured as S/PDIF, signals of the interface
is multiplexed for packets, instead of signals of coaxial interface.
* The internal multiplexer is not configured by software.
I note that the device has a quirk to mute output voluntarily during
receiving batch of packets in the beginning of packet streaming. The
operation to unmute should be done by software enough after the device
shifts the state, however it's not deterministic. Furthermore, just
after switching rate of sampling clock, the device keeps the state longer.
This patch manages to sleep 100 msec before unmute operation, but it may
fail to release the mute in the case that the rate is changed. As a
workaround, users can restart packet streaming at the same rate, or write
to specific register from userspace.
$ python3 crpp < /sys/bus/firewire/devices/fw1/config_rom
ROM header and bus information block
-----------------------------------------------------------------
400 04105c54 bus_info_length 4, crc_length 16, crc 23636
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 00005015 device_id 0000005015 | EUI-64 0001f20000005015
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 00035052 directory_length 3, crc 20562
42c 120001f2 specifier id
430 13000001 version
434 17101800 model
eui-64 leaf at 438
-----------------------------------------------------------------
438 0002eeb6 leaf_length 2, crc 61110
43c 0001f200 company_id 0001f2 |
440 00005015 device_id 0000005015 | EUI-64 0001f20000005015
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20210616082847.124688-2-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2021-06-16 01:28:46 -07:00
|
|
|
else if (motu->spec->protocol_version == SND_MOTU_PROTOCOL_V1)
|
|
|
|
|
return snd_motu_protocol_v1_switch_fetching_mode(motu, enable);
|
2020-05-19 04:16:31 -07:00
|
|
|
else
|
|
|
|
|
return -ENXIO;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static inline int snd_motu_protocol_cache_packet_formats(struct snd_motu *motu)
|
|
|
|
|
{
|
|
|
|
|
if (motu->spec->protocol_version == SND_MOTU_PROTOCOL_V2)
|
|
|
|
|
return snd_motu_protocol_v2_cache_packet_formats(motu);
|
|
|
|
|
else if (motu->spec->protocol_version == SND_MOTU_PROTOCOL_V3)
|
|
|
|
|
return snd_motu_protocol_v3_cache_packet_formats(motu);
|
ALSA: firewire-motu: add support for MOTU 828
MOTU 828 is a first model in MOTU FireWire series, produced in 2001. This
model consists of three chips:
* Texas Instruments TSB41AB1 (Physical layer for IEEE 1394 bus)
* Philips Semiconductors 1394L21BE (Link layer for IEEE 1394 bus and
packet processing layer)
* QuickLogic QuickRAM QL4016 (Data block processing layer and digital
signal processing)
This commit adds a support for this model, with its unique protocol as
version 1. The features of this protocol are:
* no MIDI support.
* Rx packets have no data chunks for control and status messages.
* Tx packets have 2 data chunks for control and status messages in the
end of each data block. The chunks consist of data block counter
(4 byte) and message (2 byte).
* All of settings are represented in bit flag in one quadlet address
(0x'ffff'f000'0b00).
* When optical interface is configured as S/PDIF, signals of the interface
is multiplexed for packets, instead of signals of coaxial interface.
* The internal multiplexer is not configured by software.
I note that the device has a quirk to mute output voluntarily during
receiving batch of packets in the beginning of packet streaming. The
operation to unmute should be done by software enough after the device
shifts the state, however it's not deterministic. Furthermore, just
after switching rate of sampling clock, the device keeps the state longer.
This patch manages to sleep 100 msec before unmute operation, but it may
fail to release the mute in the case that the rate is changed. As a
workaround, users can restart packet streaming at the same rate, or write
to specific register from userspace.
$ python3 crpp < /sys/bus/firewire/devices/fw1/config_rom
ROM header and bus information block
-----------------------------------------------------------------
400 04105c54 bus_info_length 4, crc_length 16, crc 23636
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 00005015 device_id 0000005015 | EUI-64 0001f20000005015
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 00035052 directory_length 3, crc 20562
42c 120001f2 specifier id
430 13000001 version
434 17101800 model
eui-64 leaf at 438
-----------------------------------------------------------------
438 0002eeb6 leaf_length 2, crc 61110
43c 0001f200 company_id 0001f2 |
440 00005015 device_id 0000005015 | EUI-64 0001f20000005015
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20210616082847.124688-2-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2021-06-16 01:28:46 -07:00
|
|
|
else if (motu->spec->protocol_version == SND_MOTU_PROTOCOL_V1)
|
|
|
|
|
return snd_motu_protocol_v1_cache_packet_formats(motu);
|
2020-05-19 04:16:31 -07:00
|
|
|
else
|
|
|
|
|
return -ENXIO;
|
|
|
|
|
}
|
|
|
|
|
|
2021-10-15 01:08:16 -07:00
|
|
|
int snd_motu_register_dsp_message_parser_new(struct snd_motu *motu);
|
|
|
|
|
int snd_motu_register_dsp_message_parser_init(struct snd_motu *motu);
|
2023-01-08 19:17:37 -07:00
|
|
|
void snd_motu_register_dsp_message_parser_parse(const struct amdtp_stream *s,
|
|
|
|
|
const struct pkt_desc *descs, unsigned int count);
|
2021-10-15 01:08:18 -07:00
|
|
|
void snd_motu_register_dsp_message_parser_copy_meter(struct snd_motu *motu,
|
|
|
|
|
struct snd_firewire_motu_register_dsp_meter *meter);
|
2021-10-15 01:08:24 -07:00
|
|
|
void snd_motu_register_dsp_message_parser_copy_parameter(struct snd_motu *motu,
|
|
|
|
|
struct snd_firewire_motu_register_dsp_parameter *params);
|
2021-10-15 01:08:26 -07:00
|
|
|
unsigned int snd_motu_register_dsp_message_parser_count_event(struct snd_motu *motu);
|
|
|
|
|
bool snd_motu_register_dsp_message_parser_copy_event(struct snd_motu *motu, u32 *event);
|
2021-10-15 01:08:17 -07:00
|
|
|
|
|
|
|
|
int snd_motu_command_dsp_message_parser_new(struct snd_motu *motu);
|
|
|
|
|
int snd_motu_command_dsp_message_parser_init(struct snd_motu *motu, enum cip_sfc sfc);
|
2023-01-08 19:17:37 -07:00
|
|
|
void snd_motu_command_dsp_message_parser_parse(const struct amdtp_stream *s,
|
|
|
|
|
const struct pkt_desc *descs, unsigned int count);
|
2021-10-15 01:08:18 -07:00
|
|
|
void snd_motu_command_dsp_message_parser_copy_meter(struct snd_motu *motu,
|
|
|
|
|
struct snd_firewire_motu_command_dsp_meter *meter);
|
2021-10-15 01:08:17 -07:00
|
|
|
|
2017-03-22 05:30:11 -07:00
|
|
|
#endif
|