2011-03-15 13:53:21 +07:00
|
|
|
#ifndef SOUND_FIREWIRE_AMDTP_H_INCLUDED
|
|
|
|
#define SOUND_FIREWIRE_AMDTP_H_INCLUDED
|
|
|
|
|
2011-09-05 03:15:44 +07:00
|
|
|
#include <linux/err.h>
|
2012-05-14 03:03:09 +07:00
|
|
|
#include <linux/interrupt.h>
|
2011-03-15 13:53:21 +07:00
|
|
|
#include <linux/mutex.h>
|
2013-11-19 11:29:24 +07:00
|
|
|
#include <sound/asound.h>
|
2011-03-15 13:53:21 +07:00
|
|
|
#include "packets-buffer.h"
|
|
|
|
|
|
|
|
/**
|
2014-04-25 20:44:42 +07:00
|
|
|
* enum cip_flags - describes details of the streaming protocol
|
2011-03-15 13:53:21 +07: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 03:12:48 +07: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 20:44:49 +07: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.
|
2011-03-15 13:53:21 +07:00
|
|
|
*/
|
2014-04-25 20:44:42 +07:00
|
|
|
enum cip_flags {
|
2014-04-25 20:44:49 +07:00
|
|
|
CIP_NONBLOCKING = 0x00,
|
|
|
|
CIP_BLOCKING = 0x01,
|
2014-04-25 20:44:51 +07:00
|
|
|
CIP_SYNC_TO_DEVICE = 0x02,
|
2011-03-15 13:53:21 +07:00
|
|
|
};
|
|
|
|
|
|
|
|
/**
|
|
|
|
* enum cip_sfc - a stream's sample rate
|
|
|
|
*/
|
|
|
|
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 03:16:10 +07:00
|
|
|
CIP_SFC_COUNT
|
2011-03-15 13:53:21 +07:00
|
|
|
};
|
|
|
|
|
2014-04-25 20:44:46 +07:00
|
|
|
#define AMDTP_IN_PCM_FORMAT_BITS SNDRV_PCM_FMTBIT_S32
|
|
|
|
|
2011-03-15 13:53:21 +07: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 20:44:47 +07:00
|
|
|
|
2014-04-25 20:44:50 +07: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 20:44:47 +07: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 13:53:21 +07:00
|
|
|
struct fw_unit;
|
|
|
|
struct fw_iso_context;
|
|
|
|
struct snd_pcm_substream;
|
2014-04-25 20:44:52 +07: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 20:44:47 +07:00
|
|
|
struct snd_rawmidi_substream;
|
2011-03-15 13:53:21 +07:00
|
|
|
|
2014-04-25 20:44:44 +07:00
|
|
|
enum amdtp_stream_direction {
|
|
|
|
AMDTP_OUT_STREAM = 0,
|
|
|
|
AMDTP_IN_STREAM
|
|
|
|
};
|
|
|
|
|
2014-04-25 20:44:42 +07:00
|
|
|
struct amdtp_stream {
|
2011-03-15 13:53:21 +07:00
|
|
|
struct fw_unit *unit;
|
2014-04-25 20:44:42 +07:00
|
|
|
enum cip_flags flags;
|
2014-04-25 20:44:44 +07:00
|
|
|
enum amdtp_stream_direction direction;
|
2011-03-15 13:53:21 +07:00
|
|
|
struct fw_iso_context *context;
|
|
|
|
struct mutex mutex;
|
|
|
|
|
|
|
|
enum cip_sfc sfc;
|
|
|
|
unsigned int data_block_quadlets;
|
|
|
|
unsigned int pcm_channels;
|
|
|
|
unsigned int midi_ports;
|
2014-04-25 20:44:42 +07:00
|
|
|
void (*transfer_samples)(struct amdtp_stream *s,
|
2011-03-15 13:53:21 +07:00
|
|
|
struct snd_pcm_substream *pcm,
|
|
|
|
__be32 *buffer, unsigned int frames);
|
2014-04-25 20:44:50 +07:00
|
|
|
u8 pcm_positions[AMDTP_MAX_CHANNELS_FOR_PCM];
|
|
|
|
u8 midi_position;
|
2011-03-15 13:53:21 +07:00
|
|
|
|
|
|
|
unsigned int syt_interval;
|
2011-09-05 03:12:48 +07:00
|
|
|
unsigned int transfer_delay;
|
2011-03-15 13:53:21 +07:00
|
|
|
unsigned int source_node_id_field;
|
|
|
|
struct iso_packets_buffer buffer;
|
|
|
|
|
|
|
|
struct snd_pcm_substream *pcm;
|
2012-05-14 03:03:09 +07:00
|
|
|
struct tasklet_struct period_tasklet;
|
2011-03-15 13:53:21 +07:00
|
|
|
|
2011-03-15 13:57:24 +07:00
|
|
|
int packet_index;
|
2011-03-15 13:53:21 +07:00
|
|
|
unsigned int data_block_counter;
|
|
|
|
|
|
|
|
unsigned int data_block_state;
|
|
|
|
|
|
|
|
unsigned int last_syt_offset;
|
|
|
|
unsigned int syt_offset_state;
|
|
|
|
|
|
|
|
unsigned int pcm_buffer_pointer;
|
|
|
|
unsigned int pcm_period_pointer;
|
2012-05-14 00:07:22 +07: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 20:44:47 +07:00
|
|
|
|
|
|
|
struct snd_rawmidi_substream *midi[AMDTP_MAX_CHANNELS_FOR_MIDI * 8];
|
2014-04-25 20:44:49 +07:00
|
|
|
|
|
|
|
bool callbacked;
|
|
|
|
wait_queue_head_t callback_wait;
|
|
|
|
struct amdtp_stream *sync_slave;
|
2011-03-15 13:53:21 +07:00
|
|
|
};
|
|
|
|
|
2014-04-25 20:44:42 +07:00
|
|
|
int amdtp_stream_init(struct amdtp_stream *s, struct fw_unit *unit,
|
2014-04-25 20:44:44 +07:00
|
|
|
enum amdtp_stream_direction dir,
|
2014-04-25 20:44:42 +07:00
|
|
|
enum cip_flags flags);
|
|
|
|
void amdtp_stream_destroy(struct amdtp_stream *s);
|
2011-03-15 13:53:21 +07:00
|
|
|
|
2014-04-25 20:44:42 +07: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 13:53:21 +07:00
|
|
|
|
2014-04-25 20:44:42 +07: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 13:53:21 +07:00
|
|
|
|
2014-04-25 20:44:52 +07:00
|
|
|
int amdtp_stream_add_pcm_hw_constraints(struct amdtp_stream *s,
|
|
|
|
struct snd_pcm_runtime *runtime);
|
2014-04-25 20:44:42 +07: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 13:53:21 +07:00
|
|
|
|
2011-10-17 02:39:00 +07:00
|
|
|
extern const unsigned int amdtp_syt_intervals[CIP_SFC_COUNT];
|
2011-09-05 03:16:10 +07:00
|
|
|
|
2014-04-25 20:44:42 +07: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 03:15:44 +07:00
|
|
|
{
|
|
|
|
return !IS_ERR(s->context);
|
|
|
|
}
|
|
|
|
|
2011-03-15 13:57:24 +07:00
|
|
|
/**
|
2014-04-25 20:44:42 +07:00
|
|
|
* amdtp_streaming_error - check for streaming error
|
|
|
|
* @s: the AMDTP stream
|
2011-03-15 13:57:24 +07:00
|
|
|
*
|
|
|
|
* If this function returns true, the stream's packet queue has stopped due to
|
|
|
|
* an asynchronous error.
|
|
|
|
*/
|
2014-04-25 20:44:42 +07:00
|
|
|
static inline bool amdtp_streaming_error(struct amdtp_stream *s)
|
2011-03-15 13:57:24 +07: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 20:44:47 +07: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 13:53:21 +07:00
|
|
|
/**
|
2014-04-25 20:44:42 +07:00
|
|
|
* amdtp_stream_pcm_trigger - start/stop playback from a PCM device
|
|
|
|
* @s: the AMDTP stream
|
2011-03-15 13:53:21 +07: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 20:44:42 +07:00
|
|
|
static inline void amdtp_stream_pcm_trigger(struct amdtp_stream *s,
|
|
|
|
struct snd_pcm_substream *pcm)
|
2011-03-15 13:53:21 +07: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 20:44:47 +07: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 13:53:21 +07:00
|
|
|
static inline bool cip_sfc_is_base_44100(enum cip_sfc sfc)
|
|
|
|
{
|
|
|
|
return sfc & 1;
|
|
|
|
}
|
|
|
|
|
2014-04-25 20:44:49 +07: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 13:53:21 +07:00
|
|
|
#endif
|