2011-03-15 14:53:21 +08:00
|
|
|
#ifndef SOUND_FIREWIRE_AMDTP_H_INCLUDED
|
|
|
|
#define SOUND_FIREWIRE_AMDTP_H_INCLUDED
|
|
|
|
|
2011-09-05 04:15:44 +08:00
|
|
|
#include <linux/err.h>
|
2012-05-14 04:03:09 +08:00
|
|
|
#include <linux/interrupt.h>
|
2011-03-15 14:53:21 +08:00
|
|
|
#include <linux/mutex.h>
|
2013-11-19 12:29:24 +08:00
|
|
|
#include <sound/asound.h>
|
2011-03-15 14:53:21 +08:00
|
|
|
#include "packets-buffer.h"
|
|
|
|
|
|
|
|
/**
|
2014-04-25 21:44:42 +08:00
|
|
|
* enum cip_flags - describes details of the streaming protocol
|
2011-03-15 14:53:21 +08:00
|
|
|
* @CIP_NONBLOCKING: In non-blocking mode, each packet contains
|
|
|
|
* sample_rate/8000 samples, with rounding up or down to adjust
|
|
|
|
* for clock skew and left-over fractional samples. This should
|
|
|
|
* be used if supported by the device.
|
2011-09-05 04:12:48 +08:00
|
|
|
* @CIP_BLOCKING: In blocking mode, each packet contains either zero or
|
|
|
|
* SYT_INTERVAL samples, with these two types alternating so that
|
|
|
|
* the overall sample rate comes out right.
|
2014-04-25 21:44:49 +08:00
|
|
|
* @CIP_SYNC_TO_DEVICE: In sync to device mode, time stamp in out packets is
|
|
|
|
* generated by in packets. Defaultly this driver generates timestamp.
|
2014-04-25 21:45:03 +08:00
|
|
|
* @CIP_EMPTY_WITH_TAG0: Only for in-stream. Empty in-packets have TAG0.
|
2014-04-25 21:45:04 +08:00
|
|
|
* @CIP_DBC_IS_END_EVENT: Only for in-stream. The value of dbc in an in-packet
|
|
|
|
* corresponds to the end of event in the packet. Out of IEC 61883.
|
2014-04-25 21:45:05 +08:00
|
|
|
* @CIP_WRONG_DBS: Only for in-stream. The value of dbs is wrong in in-packets.
|
|
|
|
* The value of data_block_quadlets is used instead of reported value.
|
2014-11-18 22:59:40 +08:00
|
|
|
* @CIP_SKIP_DBC_ZERO_CHECK: Only for in-stream. Packets with zero in dbc is
|
2014-04-25 21:45:07 +08:00
|
|
|
* skipped for detecting discontinuity.
|
2014-04-25 21:45:16 +08:00
|
|
|
* @CIP_SKIP_INIT_DBC_CHECK: Only for in-stream. The value of dbc in first
|
|
|
|
* packet is not continuous from an initial value.
|
2014-04-25 21:45:27 +08:00
|
|
|
* @CIP_EMPTY_HAS_WRONG_DBC: Only for in-stream. The value of dbc in empty
|
|
|
|
* packet is wrong but the others are correct.
|
ALSA: firewire-lib: add buffer-over-run protection at receiving more data blocks than expected
In IEC 61883-6, the number of data blocks in a packet is limited up to
the value of SYT_INTERVAL. Current implementation is compliant to the
limitation, while it can cause buffer-over-run when the value of dbs
field in received packet is illegally large.
This commit adds a validator to detect such illegal packets to prevent
the buffer-over-run. Actually, the buffer is aligned to the size of memory
page, thus this issue hardly causes system errors due to the room to page
alignment, as long as a few packets includes such jumbo payload; i.e.
a packet to several received packets.
Here, Behringer F-Control Audio 202 (based on OXFW 960) has a quirk to
postpone transferring isochronous packet till finish handling any
asynchronous packets. In this case, this model is lazy, transfers no
packets according to several cycle-start packets. After finishing, this
model pushes required data in next isochronous packet. As a result, the
packet include more data blocks than IEC 61883-6 defines.
To continue to support this model, this commit adds a new flag to extend
the length of calculated payload. This flag allows the size of payload
5 times as large as IEC 61883-6 defines. As a result, packets from this
model passed the validator successfully.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2015-05-22 22:00:50 +08:00
|
|
|
* @CIP_JUMBO_PAYLOAD: Only for in-stream. The number of data blocks in an
|
|
|
|
* packet is larger than IEC 61883-6 defines. Current implementation
|
|
|
|
* allows 5 times as large as IEC 61883-6 defines.
|
2011-03-15 14:53:21 +08:00
|
|
|
*/
|
2014-04-25 21:44:42 +08:00
|
|
|
enum cip_flags {
|
2014-04-25 21:44:49 +08:00
|
|
|
CIP_NONBLOCKING = 0x00,
|
|
|
|
CIP_BLOCKING = 0x01,
|
2014-04-25 21:44:51 +08:00
|
|
|
CIP_SYNC_TO_DEVICE = 0x02,
|
2014-04-25 21:45:03 +08:00
|
|
|
CIP_EMPTY_WITH_TAG0 = 0x04,
|
2014-04-25 21:45:04 +08:00
|
|
|
CIP_DBC_IS_END_EVENT = 0x08,
|
2014-04-25 21:45:05 +08:00
|
|
|
CIP_WRONG_DBS = 0x10,
|
2014-04-25 21:45:07 +08:00
|
|
|
CIP_SKIP_DBC_ZERO_CHECK = 0x20,
|
2014-04-25 21:45:16 +08:00
|
|
|
CIP_SKIP_INIT_DBC_CHECK = 0x40,
|
2014-04-25 21:45:27 +08:00
|
|
|
CIP_EMPTY_HAS_WRONG_DBC = 0x80,
|
ALSA: firewire-lib: add buffer-over-run protection at receiving more data blocks than expected
In IEC 61883-6, the number of data blocks in a packet is limited up to
the value of SYT_INTERVAL. Current implementation is compliant to the
limitation, while it can cause buffer-over-run when the value of dbs
field in received packet is illegally large.
This commit adds a validator to detect such illegal packets to prevent
the buffer-over-run. Actually, the buffer is aligned to the size of memory
page, thus this issue hardly causes system errors due to the room to page
alignment, as long as a few packets includes such jumbo payload; i.e.
a packet to several received packets.
Here, Behringer F-Control Audio 202 (based on OXFW 960) has a quirk to
postpone transferring isochronous packet till finish handling any
asynchronous packets. In this case, this model is lazy, transfers no
packets according to several cycle-start packets. After finishing, this
model pushes required data in next isochronous packet. As a result, the
packet include more data blocks than IEC 61883-6 defines.
To continue to support this model, this commit adds a new flag to extend
the length of calculated payload. This flag allows the size of payload
5 times as large as IEC 61883-6 defines. As a result, packets from this
model passed the validator successfully.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2015-05-22 22:00:50 +08:00
|
|
|
CIP_JUMBO_PAYLOAD = 0x100,
|
2011-03-15 14:53:21 +08:00
|
|
|
};
|
|
|
|
|
|
|
|
/**
|
2014-11-18 22:59:40 +08:00
|
|
|
* enum cip_sfc - supported Sampling Frequency Codes (SFCs)
|
|
|
|
* @CIP_SFC_32000: 32,000 data blocks
|
|
|
|
* @CIP_SFC_44100: 44,100 data blocks
|
|
|
|
* @CIP_SFC_48000: 48,000 data blocks
|
|
|
|
* @CIP_SFC_88200: 88,200 data blocks
|
|
|
|
* @CIP_SFC_96000: 96,000 data blocks
|
|
|
|
* @CIP_SFC_176400: 176,400 data blocks
|
|
|
|
* @CIP_SFC_192000: 192,000 data blocks
|
|
|
|
* @CIP_SFC_COUNT: the number of supported SFCs
|
|
|
|
*
|
|
|
|
* These values are used to show nominal Sampling Frequency Code in
|
|
|
|
* Format Dependent Field (FDF) of AMDTP packet header. In IEC 61883-6:2002,
|
|
|
|
* this code means the number of events per second. Actually the code
|
|
|
|
* represents the number of data blocks transferred per second in an AMDTP
|
|
|
|
* stream.
|
|
|
|
*
|
|
|
|
* In IEC 61883-6:2005, some extensions were added to support more types of
|
|
|
|
* data such as 'One Bit LInear Audio', therefore the meaning of SFC became
|
|
|
|
* different depending on the types.
|
|
|
|
*
|
|
|
|
* Currently our implementation is compatible with IEC 61883-6:2002.
|
2011-03-15 14:53:21 +08:00
|
|
|
*/
|
|
|
|
enum cip_sfc {
|
|
|
|
CIP_SFC_32000 = 0,
|
|
|
|
CIP_SFC_44100 = 1,
|
|
|
|
CIP_SFC_48000 = 2,
|
|
|
|
CIP_SFC_88200 = 3,
|
|
|
|
CIP_SFC_96000 = 4,
|
|
|
|
CIP_SFC_176400 = 5,
|
|
|
|
CIP_SFC_192000 = 6,
|
2011-09-05 04:16:10 +08:00
|
|
|
CIP_SFC_COUNT
|
2011-03-15 14:53:21 +08:00
|
|
|
};
|
|
|
|
|
2014-04-25 21:44:46 +08:00
|
|
|
#define AMDTP_IN_PCM_FORMAT_BITS SNDRV_PCM_FMTBIT_S32
|
|
|
|
|
2011-03-15 14:53:21 +08:00
|
|
|
#define AMDTP_OUT_PCM_FORMAT_BITS (SNDRV_PCM_FMTBIT_S16 | \
|
|
|
|
SNDRV_PCM_FMTBIT_S32)
|
|
|
|
|
ALSA: firewire-lib: Add support for MIDI capture/playback
For capturing/playbacking MIDI messages, this commit adds one MIDI conformant
data channel. This data channel has multiplexed 8 MIDI data streams. So this
data channel can transfer messages from/to 8 MIDI ports.
And this commit allows to set PCM format even if AMDTP streams already start.
I suppose the case that PCM substreams are going to be joined into AMDTP
streams when AMDTP streams are already started for MIDI substreams. Each
driver must count how many PCM/MIDI substreams use AMDTP streams to stop
AMDTP streams.
There are differences between specifications about MIDI conformant data.
About the multiplexing, IEC 61883-6:2002, itself, has no information. It
describes labels and bytes for MIDI messages and refers to MMA/AMEI RP-027
for 'successfull implementation'. MMA/AMEI RP-027 describes 8 MPX-MIDI data
streams for one MIDI conformant data channel. IEC 61883-6:2005 adds
'sequence multiplexing' and apply this way and describe incompatibility
between 2002 and 2005.
So this commit applies IEC 61883-6:2005. When we find some devices compliant
to IEC 61883-6:2002, then this difference should be handles as device quirk
in additional work.
About the number of bytes in an MIDI conformant data, IEC 61883-6:2002 describe
0,1,2,3 bytes. MMA/AMEI RP-027 describes 'MIDI1.0-1x-SPEED', 'MIDI1.0-2x-SPEED',
'MIDI1.0-3x-SPEED' modes and the maximum bytes for each mode corresponds to 1,
2, 3 bytes. The 'MIDI1.0-2x/3x-SPEED' modes are accompanied with 'negotiation
procedure' and 'encapsulation details' but there is no specifications for them.
So this commit implements 'MIDI1.0-1x-SPEED' mode for playback, but allows
to pick up 1-3 bytes for capturing.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2014-04-25 21:44:47 +08:00
|
|
|
|
2014-04-25 21:44:50 +08:00
|
|
|
/*
|
|
|
|
* This module supports maximum 64 PCM channels for one PCM stream
|
|
|
|
* This is for our convenience.
|
|
|
|
*/
|
|
|
|
#define AMDTP_MAX_CHANNELS_FOR_PCM 64
|
|
|
|
|
ALSA: firewire-lib: Add support for MIDI capture/playback
For capturing/playbacking MIDI messages, this commit adds one MIDI conformant
data channel. This data channel has multiplexed 8 MIDI data streams. So this
data channel can transfer messages from/to 8 MIDI ports.
And this commit allows to set PCM format even if AMDTP streams already start.
I suppose the case that PCM substreams are going to be joined into AMDTP
streams when AMDTP streams are already started for MIDI substreams. Each
driver must count how many PCM/MIDI substreams use AMDTP streams to stop
AMDTP streams.
There are differences between specifications about MIDI conformant data.
About the multiplexing, IEC 61883-6:2002, itself, has no information. It
describes labels and bytes for MIDI messages and refers to MMA/AMEI RP-027
for 'successfull implementation'. MMA/AMEI RP-027 describes 8 MPX-MIDI data
streams for one MIDI conformant data channel. IEC 61883-6:2005 adds
'sequence multiplexing' and apply this way and describe incompatibility
between 2002 and 2005.
So this commit applies IEC 61883-6:2005. When we find some devices compliant
to IEC 61883-6:2002, then this difference should be handles as device quirk
in additional work.
About the number of bytes in an MIDI conformant data, IEC 61883-6:2002 describe
0,1,2,3 bytes. MMA/AMEI RP-027 describes 'MIDI1.0-1x-SPEED', 'MIDI1.0-2x-SPEED',
'MIDI1.0-3x-SPEED' modes and the maximum bytes for each mode corresponds to 1,
2, 3 bytes. The 'MIDI1.0-2x/3x-SPEED' modes are accompanied with 'negotiation
procedure' and 'encapsulation details' but there is no specifications for them.
So this commit implements 'MIDI1.0-1x-SPEED' mode for playback, but allows
to pick up 1-3 bytes for capturing.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2014-04-25 21:44:47 +08:00
|
|
|
/*
|
|
|
|
* AMDTP packet can include channels for MIDI conformant data.
|
|
|
|
* Each MIDI conformant data channel includes 8 MPX-MIDI data stream.
|
|
|
|
* Each MPX-MIDI data stream includes one data stream from/to MIDI ports.
|
|
|
|
*
|
|
|
|
* This module supports maximum 1 MIDI conformant data channels.
|
|
|
|
* Then this AMDTP packets can transfer maximum 8 MIDI data streams.
|
|
|
|
*/
|
|
|
|
#define AMDTP_MAX_CHANNELS_FOR_MIDI 1
|
|
|
|
|
2011-03-15 14:53:21 +08:00
|
|
|
struct fw_unit;
|
|
|
|
struct fw_iso_context;
|
|
|
|
struct snd_pcm_substream;
|
2014-04-25 21:44:52 +08:00
|
|
|
struct snd_pcm_runtime;
|
ALSA: firewire-lib: Add support for MIDI capture/playback
For capturing/playbacking MIDI messages, this commit adds one MIDI conformant
data channel. This data channel has multiplexed 8 MIDI data streams. So this
data channel can transfer messages from/to 8 MIDI ports.
And this commit allows to set PCM format even if AMDTP streams already start.
I suppose the case that PCM substreams are going to be joined into AMDTP
streams when AMDTP streams are already started for MIDI substreams. Each
driver must count how many PCM/MIDI substreams use AMDTP streams to stop
AMDTP streams.
There are differences between specifications about MIDI conformant data.
About the multiplexing, IEC 61883-6:2002, itself, has no information. It
describes labels and bytes for MIDI messages and refers to MMA/AMEI RP-027
for 'successfull implementation'. MMA/AMEI RP-027 describes 8 MPX-MIDI data
streams for one MIDI conformant data channel. IEC 61883-6:2005 adds
'sequence multiplexing' and apply this way and describe incompatibility
between 2002 and 2005.
So this commit applies IEC 61883-6:2005. When we find some devices compliant
to IEC 61883-6:2002, then this difference should be handles as device quirk
in additional work.
About the number of bytes in an MIDI conformant data, IEC 61883-6:2002 describe
0,1,2,3 bytes. MMA/AMEI RP-027 describes 'MIDI1.0-1x-SPEED', 'MIDI1.0-2x-SPEED',
'MIDI1.0-3x-SPEED' modes and the maximum bytes for each mode corresponds to 1,
2, 3 bytes. The 'MIDI1.0-2x/3x-SPEED' modes are accompanied with 'negotiation
procedure' and 'encapsulation details' but there is no specifications for them.
So this commit implements 'MIDI1.0-1x-SPEED' mode for playback, but allows
to pick up 1-3 bytes for capturing.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2014-04-25 21:44:47 +08:00
|
|
|
struct snd_rawmidi_substream;
|
2011-03-15 14:53:21 +08:00
|
|
|
|
2014-04-25 21:44:44 +08:00
|
|
|
enum amdtp_stream_direction {
|
|
|
|
AMDTP_OUT_STREAM = 0,
|
|
|
|
AMDTP_IN_STREAM
|
|
|
|
};
|
|
|
|
|
2014-04-25 21:44:42 +08:00
|
|
|
struct amdtp_stream {
|
2011-03-15 14:53:21 +08:00
|
|
|
struct fw_unit *unit;
|
2014-04-25 21:44:42 +08:00
|
|
|
enum cip_flags flags;
|
2014-04-25 21:44:44 +08:00
|
|
|
enum amdtp_stream_direction direction;
|
2011-03-15 14:53:21 +08:00
|
|
|
struct mutex mutex;
|
|
|
|
|
2015-09-19 10:21:48 +08:00
|
|
|
/* For packet processing. */
|
|
|
|
struct fw_iso_context *context;
|
2011-03-15 14:53:21 +08:00
|
|
|
struct iso_packets_buffer buffer;
|
2011-03-15 14:57:24 +08:00
|
|
|
int packet_index;
|
2015-09-19 10:21:48 +08:00
|
|
|
|
|
|
|
/* For CIP headers. */
|
|
|
|
unsigned int source_node_id_field;
|
|
|
|
unsigned int data_block_quadlets;
|
2011-03-15 14:53:21 +08:00
|
|
|
unsigned int data_block_counter;
|
2015-09-19 10:21:48 +08:00
|
|
|
/* quirk: fixed interval of dbc between previos/current packets. */
|
|
|
|
unsigned int tx_dbc_interval;
|
|
|
|
/* quirk: indicate the value of dbc field in a first packet. */
|
|
|
|
unsigned int tx_first_dbc;
|
2011-03-15 14:53:21 +08:00
|
|
|
|
2015-09-19 10:21:48 +08:00
|
|
|
/* Internal flags. */
|
|
|
|
enum cip_sfc sfc;
|
|
|
|
unsigned int syt_interval;
|
|
|
|
unsigned int transfer_delay;
|
2011-03-15 14:53:21 +08:00
|
|
|
unsigned int data_block_state;
|
|
|
|
unsigned int last_syt_offset;
|
|
|
|
unsigned int syt_offset_state;
|
|
|
|
|
2015-09-19 10:21:48 +08:00
|
|
|
/* For a PCM substream processing. */
|
|
|
|
struct snd_pcm_substream *pcm;
|
|
|
|
struct tasklet_struct period_tasklet;
|
2011-03-15 14:53:21 +08:00
|
|
|
unsigned int pcm_buffer_pointer;
|
|
|
|
unsigned int pcm_period_pointer;
|
2012-05-14 01:07:22 +08:00
|
|
|
bool pointer_flush;
|
ALSA: firewire-lib: Add support for MIDI capture/playback
For capturing/playbacking MIDI messages, this commit adds one MIDI conformant
data channel. This data channel has multiplexed 8 MIDI data streams. So this
data channel can transfer messages from/to 8 MIDI ports.
And this commit allows to set PCM format even if AMDTP streams already start.
I suppose the case that PCM substreams are going to be joined into AMDTP
streams when AMDTP streams are already started for MIDI substreams. Each
driver must count how many PCM/MIDI substreams use AMDTP streams to stop
AMDTP streams.
There are differences between specifications about MIDI conformant data.
About the multiplexing, IEC 61883-6:2002, itself, has no information. It
describes labels and bytes for MIDI messages and refers to MMA/AMEI RP-027
for 'successfull implementation'. MMA/AMEI RP-027 describes 8 MPX-MIDI data
streams for one MIDI conformant data channel. IEC 61883-6:2005 adds
'sequence multiplexing' and apply this way and describe incompatibility
between 2002 and 2005.
So this commit applies IEC 61883-6:2005. When we find some devices compliant
to IEC 61883-6:2002, then this difference should be handles as device quirk
in additional work.
About the number of bytes in an MIDI conformant data, IEC 61883-6:2002 describe
0,1,2,3 bytes. MMA/AMEI RP-027 describes 'MIDI1.0-1x-SPEED', 'MIDI1.0-2x-SPEED',
'MIDI1.0-3x-SPEED' modes and the maximum bytes for each mode corresponds to 1,
2, 3 bytes. The 'MIDI1.0-2x/3x-SPEED' modes are accompanied with 'negotiation
procedure' and 'encapsulation details' but there is no specifications for them.
So this commit implements 'MIDI1.0-1x-SPEED' mode for playback, but allows
to pick up 1-3 bytes for capturing.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2014-04-25 21:44:47 +08:00
|
|
|
|
2015-09-19 10:21:48 +08:00
|
|
|
/* To wait for first packet. */
|
|
|
|
bool callbacked;
|
|
|
|
wait_queue_head_t callback_wait;
|
|
|
|
struct amdtp_stream *sync_slave;
|
|
|
|
|
|
|
|
/* For AM824 processing. */
|
ALSA: firewire-lib: Add support for MIDI capture/playback
For capturing/playbacking MIDI messages, this commit adds one MIDI conformant
data channel. This data channel has multiplexed 8 MIDI data streams. So this
data channel can transfer messages from/to 8 MIDI ports.
And this commit allows to set PCM format even if AMDTP streams already start.
I suppose the case that PCM substreams are going to be joined into AMDTP
streams when AMDTP streams are already started for MIDI substreams. Each
driver must count how many PCM/MIDI substreams use AMDTP streams to stop
AMDTP streams.
There are differences between specifications about MIDI conformant data.
About the multiplexing, IEC 61883-6:2002, itself, has no information. It
describes labels and bytes for MIDI messages and refers to MMA/AMEI RP-027
for 'successfull implementation'. MMA/AMEI RP-027 describes 8 MPX-MIDI data
streams for one MIDI conformant data channel. IEC 61883-6:2005 adds
'sequence multiplexing' and apply this way and describe incompatibility
between 2002 and 2005.
So this commit applies IEC 61883-6:2005. When we find some devices compliant
to IEC 61883-6:2002, then this difference should be handles as device quirk
in additional work.
About the number of bytes in an MIDI conformant data, IEC 61883-6:2002 describe
0,1,2,3 bytes. MMA/AMEI RP-027 describes 'MIDI1.0-1x-SPEED', 'MIDI1.0-2x-SPEED',
'MIDI1.0-3x-SPEED' modes and the maximum bytes for each mode corresponds to 1,
2, 3 bytes. The 'MIDI1.0-2x/3x-SPEED' modes are accompanied with 'negotiation
procedure' and 'encapsulation details' but there is no specifications for them.
So this commit implements 'MIDI1.0-1x-SPEED' mode for playback, but allows
to pick up 1-3 bytes for capturing.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2014-04-25 21:44:47 +08:00
|
|
|
struct snd_rawmidi_substream *midi[AMDTP_MAX_CHANNELS_FOR_MIDI * 8];
|
2014-11-26 05:54:10 +08:00
|
|
|
int midi_fifo_limit;
|
|
|
|
int midi_fifo_used[AMDTP_MAX_CHANNELS_FOR_MIDI * 8];
|
2015-09-19 10:21:48 +08:00
|
|
|
unsigned int pcm_channels;
|
|
|
|
unsigned int midi_ports;
|
2014-04-25 21:44:49 +08:00
|
|
|
|
2015-09-19 10:21:48 +08:00
|
|
|
u8 pcm_positions[AMDTP_MAX_CHANNELS_FOR_PCM];
|
|
|
|
u8 midi_position;
|
|
|
|
bool double_pcm_frames;
|
2014-04-25 21:45:06 +08:00
|
|
|
|
2015-09-19 10:21:48 +08:00
|
|
|
void (*transfer_samples)(struct amdtp_stream *s,
|
|
|
|
struct snd_pcm_substream *pcm,
|
|
|
|
__be32 *buffer, unsigned int frames);
|
2011-03-15 14:53:21 +08:00
|
|
|
};
|
|
|
|
|
2014-04-25 21:44:42 +08:00
|
|
|
int amdtp_stream_init(struct amdtp_stream *s, struct fw_unit *unit,
|
2014-04-25 21:44:44 +08:00
|
|
|
enum amdtp_stream_direction dir,
|
2014-04-25 21:44:42 +08:00
|
|
|
enum cip_flags flags);
|
|
|
|
void amdtp_stream_destroy(struct amdtp_stream *s);
|
2011-03-15 14:53:21 +08:00
|
|
|
|
2014-04-25 21:44:42 +08:00
|
|
|
void amdtp_stream_set_parameters(struct amdtp_stream *s,
|
|
|
|
unsigned int rate,
|
|
|
|
unsigned int pcm_channels,
|
|
|
|
unsigned int midi_ports);
|
|
|
|
unsigned int amdtp_stream_get_max_payload(struct amdtp_stream *s);
|
2011-03-15 14:53:21 +08:00
|
|
|
|
2014-04-25 21:44:42 +08:00
|
|
|
int amdtp_stream_start(struct amdtp_stream *s, int channel, int speed);
|
|
|
|
void amdtp_stream_update(struct amdtp_stream *s);
|
|
|
|
void amdtp_stream_stop(struct amdtp_stream *s);
|
2011-03-15 14:53:21 +08:00
|
|
|
|
2014-04-25 21:44:52 +08:00
|
|
|
int amdtp_stream_add_pcm_hw_constraints(struct amdtp_stream *s,
|
|
|
|
struct snd_pcm_runtime *runtime);
|
2014-04-25 21:44:42 +08:00
|
|
|
void amdtp_stream_set_pcm_format(struct amdtp_stream *s,
|
|
|
|
snd_pcm_format_t format);
|
|
|
|
void amdtp_stream_pcm_prepare(struct amdtp_stream *s);
|
|
|
|
unsigned long amdtp_stream_pcm_pointer(struct amdtp_stream *s);
|
|
|
|
void amdtp_stream_pcm_abort(struct amdtp_stream *s);
|
2011-03-15 14:53:21 +08:00
|
|
|
|
2011-10-17 03:39:00 +08:00
|
|
|
extern const unsigned int amdtp_syt_intervals[CIP_SFC_COUNT];
|
2014-04-25 21:44:59 +08:00
|
|
|
extern const unsigned int amdtp_rate_table[CIP_SFC_COUNT];
|
2011-09-05 04:16:10 +08:00
|
|
|
|
2014-04-25 21:44:42 +08:00
|
|
|
/**
|
|
|
|
* amdtp_stream_running - check stream is running or not
|
|
|
|
* @s: the AMDTP stream
|
|
|
|
*
|
|
|
|
* If this function returns true, the stream is running.
|
|
|
|
*/
|
|
|
|
static inline bool amdtp_stream_running(struct amdtp_stream *s)
|
2011-09-05 04:15:44 +08:00
|
|
|
{
|
|
|
|
return !IS_ERR(s->context);
|
|
|
|
}
|
|
|
|
|
2011-03-15 14:57:24 +08:00
|
|
|
/**
|
2014-04-25 21:44:42 +08:00
|
|
|
* amdtp_streaming_error - check for streaming error
|
|
|
|
* @s: the AMDTP stream
|
2011-03-15 14:57:24 +08:00
|
|
|
*
|
|
|
|
* If this function returns true, the stream's packet queue has stopped due to
|
|
|
|
* an asynchronous error.
|
|
|
|
*/
|
2014-04-25 21:44:42 +08:00
|
|
|
static inline bool amdtp_streaming_error(struct amdtp_stream *s)
|
2011-03-15 14:57:24 +08:00
|
|
|
{
|
|
|
|
return s->packet_index < 0;
|
|
|
|
}
|
|
|
|
|
ALSA: firewire-lib: Add support for MIDI capture/playback
For capturing/playbacking MIDI messages, this commit adds one MIDI conformant
data channel. This data channel has multiplexed 8 MIDI data streams. So this
data channel can transfer messages from/to 8 MIDI ports.
And this commit allows to set PCM format even if AMDTP streams already start.
I suppose the case that PCM substreams are going to be joined into AMDTP
streams when AMDTP streams are already started for MIDI substreams. Each
driver must count how many PCM/MIDI substreams use AMDTP streams to stop
AMDTP streams.
There are differences between specifications about MIDI conformant data.
About the multiplexing, IEC 61883-6:2002, itself, has no information. It
describes labels and bytes for MIDI messages and refers to MMA/AMEI RP-027
for 'successfull implementation'. MMA/AMEI RP-027 describes 8 MPX-MIDI data
streams for one MIDI conformant data channel. IEC 61883-6:2005 adds
'sequence multiplexing' and apply this way and describe incompatibility
between 2002 and 2005.
So this commit applies IEC 61883-6:2005. When we find some devices compliant
to IEC 61883-6:2002, then this difference should be handles as device quirk
in additional work.
About the number of bytes in an MIDI conformant data, IEC 61883-6:2002 describe
0,1,2,3 bytes. MMA/AMEI RP-027 describes 'MIDI1.0-1x-SPEED', 'MIDI1.0-2x-SPEED',
'MIDI1.0-3x-SPEED' modes and the maximum bytes for each mode corresponds to 1,
2, 3 bytes. The 'MIDI1.0-2x/3x-SPEED' modes are accompanied with 'negotiation
procedure' and 'encapsulation details' but there is no specifications for them.
So this commit implements 'MIDI1.0-1x-SPEED' mode for playback, but allows
to pick up 1-3 bytes for capturing.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2014-04-25 21:44:47 +08:00
|
|
|
/**
|
|
|
|
* amdtp_stream_pcm_running - check PCM substream is running or not
|
|
|
|
* @s: the AMDTP stream
|
|
|
|
*
|
|
|
|
* If this function returns true, PCM substream in the AMDTP stream is running.
|
|
|
|
*/
|
|
|
|
static inline bool amdtp_stream_pcm_running(struct amdtp_stream *s)
|
|
|
|
{
|
|
|
|
return !!s->pcm;
|
|
|
|
}
|
|
|
|
|
2011-03-15 14:53:21 +08:00
|
|
|
/**
|
2014-04-25 21:44:42 +08:00
|
|
|
* amdtp_stream_pcm_trigger - start/stop playback from a PCM device
|
|
|
|
* @s: the AMDTP stream
|
2011-03-15 14:53:21 +08:00
|
|
|
* @pcm: the PCM device to be started, or %NULL to stop the current device
|
|
|
|
*
|
|
|
|
* Call this function on a running isochronous stream to enable the actual
|
|
|
|
* transmission of PCM data. This function should be called from the PCM
|
|
|
|
* device's .trigger callback.
|
|
|
|
*/
|
2014-04-25 21:44:42 +08:00
|
|
|
static inline void amdtp_stream_pcm_trigger(struct amdtp_stream *s,
|
|
|
|
struct snd_pcm_substream *pcm)
|
2011-03-15 14:53:21 +08:00
|
|
|
{
|
|
|
|
ACCESS_ONCE(s->pcm) = pcm;
|
|
|
|
}
|
|
|
|
|
ALSA: firewire-lib: Add support for MIDI capture/playback
For capturing/playbacking MIDI messages, this commit adds one MIDI conformant
data channel. This data channel has multiplexed 8 MIDI data streams. So this
data channel can transfer messages from/to 8 MIDI ports.
And this commit allows to set PCM format even if AMDTP streams already start.
I suppose the case that PCM substreams are going to be joined into AMDTP
streams when AMDTP streams are already started for MIDI substreams. Each
driver must count how many PCM/MIDI substreams use AMDTP streams to stop
AMDTP streams.
There are differences between specifications about MIDI conformant data.
About the multiplexing, IEC 61883-6:2002, itself, has no information. It
describes labels and bytes for MIDI messages and refers to MMA/AMEI RP-027
for 'successfull implementation'. MMA/AMEI RP-027 describes 8 MPX-MIDI data
streams for one MIDI conformant data channel. IEC 61883-6:2005 adds
'sequence multiplexing' and apply this way and describe incompatibility
between 2002 and 2005.
So this commit applies IEC 61883-6:2005. When we find some devices compliant
to IEC 61883-6:2002, then this difference should be handles as device quirk
in additional work.
About the number of bytes in an MIDI conformant data, IEC 61883-6:2002 describe
0,1,2,3 bytes. MMA/AMEI RP-027 describes 'MIDI1.0-1x-SPEED', 'MIDI1.0-2x-SPEED',
'MIDI1.0-3x-SPEED' modes and the maximum bytes for each mode corresponds to 1,
2, 3 bytes. The 'MIDI1.0-2x/3x-SPEED' modes are accompanied with 'negotiation
procedure' and 'encapsulation details' but there is no specifications for them.
So this commit implements 'MIDI1.0-1x-SPEED' mode for playback, but allows
to pick up 1-3 bytes for capturing.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2014-04-25 21:44:47 +08:00
|
|
|
/**
|
|
|
|
* amdtp_stream_midi_trigger - start/stop playback/capture with a MIDI device
|
|
|
|
* @s: the AMDTP stream
|
|
|
|
* @port: index of MIDI port
|
|
|
|
* @midi: the MIDI device to be started, or %NULL to stop the current device
|
|
|
|
*
|
|
|
|
* Call this function on a running isochronous stream to enable the actual
|
|
|
|
* transmission of MIDI data. This function should be called from the MIDI
|
|
|
|
* device's .trigger callback.
|
|
|
|
*/
|
|
|
|
static inline void amdtp_stream_midi_trigger(struct amdtp_stream *s,
|
|
|
|
unsigned int port,
|
|
|
|
struct snd_rawmidi_substream *midi)
|
|
|
|
{
|
|
|
|
if (port < s->midi_ports)
|
|
|
|
ACCESS_ONCE(s->midi[port]) = midi;
|
|
|
|
}
|
|
|
|
|
2011-03-15 14:53:21 +08:00
|
|
|
static inline bool cip_sfc_is_base_44100(enum cip_sfc sfc)
|
|
|
|
{
|
|
|
|
return sfc & 1;
|
|
|
|
}
|
|
|
|
|
2014-04-25 21:44:49 +08:00
|
|
|
static inline void amdtp_stream_set_sync(enum cip_flags sync_mode,
|
|
|
|
struct amdtp_stream *master,
|
|
|
|
struct amdtp_stream *slave)
|
|
|
|
{
|
|
|
|
if (sync_mode == CIP_SYNC_TO_DEVICE) {
|
|
|
|
master->flags |= CIP_SYNC_TO_DEVICE;
|
|
|
|
slave->flags |= CIP_SYNC_TO_DEVICE;
|
|
|
|
master->sync_slave = slave;
|
|
|
|
} else {
|
|
|
|
master->flags &= ~CIP_SYNC_TO_DEVICE;
|
|
|
|
slave->flags &= ~CIP_SYNC_TO_DEVICE;
|
|
|
|
master->sync_slave = NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
slave->sync_slave = NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* amdtp_stream_wait_callback - sleep till callbacked or timeout
|
|
|
|
* @s: the AMDTP stream
|
|
|
|
* @timeout: msec till timeout
|
|
|
|
*
|
|
|
|
* If this function return false, the AMDTP stream should be stopped.
|
|
|
|
*/
|
|
|
|
static inline bool amdtp_stream_wait_callback(struct amdtp_stream *s,
|
|
|
|
unsigned int timeout)
|
|
|
|
{
|
|
|
|
return wait_event_timeout(s->callback_wait,
|
|
|
|
s->callbacked == true,
|
|
|
|
msecs_to_jiffies(timeout)) > 0;
|
|
|
|
}
|
|
|
|
|
2011-03-15 14:53:21 +08:00
|
|
|
#endif
|