IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
In MOTU FireWire series, devices which support protocol version 2 have
several types of hardware design to process audio data frames for isoc
packet. Roughly devices are categorized into three groups:
- 828mkII
- Traveler/896HD
- UltraLite/8pre FireWire
Some bit flags in register addressed by 0x'ffff'f000'0b14
includes device-specific effects.
This commit cleanups implementation of protocol v2 in this point.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20191030080644.1704-6-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This commit adds some helper functions to parse register value for
source of sampling clock and nominal sampling transmission frequency.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20191030080644.1704-5-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
In MOTU FireWire series, devices have a mode to generate sampling clock
from a sequence of source packet header (SPH) included in each data block
of received packet. This mode is used for several purposes such as mode
for SMPTE time code, sync to the other sound cards and so on.
This commit adds support for the SPH mode.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20191030080644.1704-4-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
When unknown source is detected for sampling clock, corresponding label
was not added for node on procfs.
This commit adds it.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20191030080644.1704-3-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
A helper function of ALSA bebob driver returns negative value in a
function which has a prototype to return unsigned value.
This commit fixes it by changing the prototype.
Fixes: eb7b3a056cd8 ("ALSA: bebob: Add commands and connections/streams management")
Cc: <stable@vger.kernel.org> # v3.16+
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20191026030620.12077-1-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Some devices have a quirk to postpone transmission of isoc packet for
several dozen or hundred isoc cycles since configured to transmit.
Furthermore, some devices have a quirk to transmit isoc packet with
discontinued data of its header.
In 1394 OHCI specification, software allows to start isoc context with
certain isoc cycle. Linux firewire subsystem has kernel API to use it
as well.
This commit uses the functionality of 1394 OHCI controller to handle
the quirks. At present, this feature is convenient to ALSA bebob and
fireface driver. As a result, some devices can be safely handled, as
long as I know:
- MAudio FireWire solo
- MAudio ProFire Lightbridge
- MAudio FireWire 410
- Roland FA-66
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20191018061911.24909-7-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This commit changes AMDTP domain to run on an IT context of 1394 OHCI as
IRQ target. No hardware interrupt is scheduled for the other isoc
contexts. All of the isoc context are processed in a callback for an isoc
context of IRQ target.
The IRQ target is automatically selected from a list of AMDTP streams,
thus users of AMDTP domain should add an AMDTP stream for IT context
at least.
The reason to select IT context as IRQ target is that the IT context
runs on local 1394 OHCI controller and it can be used as reliable,
constant IRQ generator. On the other hand, IR context can include skip
cycle according to isoc packet transferred by device.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20191018061911.24909-6-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The aim of AMDTP domain is to process several isoc context in the same
time. However, current implementation is against this idea because it
flushes each isoc context in the end of processing context callback.
This commit cancels it.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20191018061911.24909-5-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
An isoc context for AMDTP stream is flushed to queue packet
by a call of pcm.ack. This commit extends this for AMDTP
domain.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20191018061911.24909-4-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
An isoc context for AMDTP stream is flushed to queue packet
by a call of pcm.pointer. This commit extends this for AMDTP
domain.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20191018061911.24909-3-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This commit is a preparation to handle several IR/IT contexts in the same
domain by tasklet context for one of the IT context. Such IT context is
stored to AMDTP domain structure as 'irq_target'.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20191018061911.24909-2-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
In IEC 61883-1/6, one isoc packet can transfer events up to the value of
syt interval. This comes from the interval of isoc cycle. As 1394 OHCI
controller can generate hardware IRQ per isoc packet, the interval is
calculated as 125 usec.
In IEC 61883-1/6, two ways of transmission is described; blocking and
non-blocking methods. In blocking method, the sequence of packet includes
'empty' or 'NODATA' packets which include no events. In non-blocking
method, the number of events per packet is variable up to the syt
interval.
This commit uses double of the value of syt interval as minimum available
size of PCM period due to the above protocol design.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20191017155424.885-13-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Linux driver for 1394 OHCI controller voluntarily flushes isoc context
when total size of accumulated context header reached PAGE_SIZE. This
kicks tasklet for the isoc context. This is inconvenient to process
runtime of PCM substream.
This commit adds a restriction of the maximum size of PCM period to
avoid this behaviour.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20191017155424.885-12-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
ALSA IEC 61883-1/6 packet streaming engine controls 1394 OHCI controller
to generate hardware IRQ for fixed number of isochronous packets (=16)
since its first commit.
This commit allow the engine to generate it for variable period according
to the number of event to handle. For outgoing stream, internal
calculator is used to check the accumulated events. For incoming stream,
the number of data block in the packet of stream is used to check the
accumulated events. When it's unavailable, fixed number of packet
roughly calculated in advance is used instead of event counting.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20191017155424.885-11-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This commit allows ALSA fireface driver to share PCM buffer size for
both capture and playback PCM substream. When AMDTP domain starts for
one of the PCM substream, buffer size of the PCM substream is stores to
AMDTP domain structure. Some AMDTP streams have already run with the
buffer size when another PCM substream starts, therefore the PCM
substream has a constraint to its buffer size.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20191017155424.885-10-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This commit allows ALSA firewire-motu driver to share PCM buffer
size for both capture and playback PCM substream. When AMDTP domain
starts for one of the PCM substream, buffer size of the PCM substream
is stores to AMDTP domain structure. Some AMDTP streams have already
run with the buffer size when another PCM substream starts, therefore
the PCM substream has a constraint to its buffer size.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20191017155424.885-9-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This commit allows ALSA firewire-tascam driver to share PCM buffer
size for both capture and playback PCM substream. When AMDTP domain
starts for one of the PCM substream, buffer size of the PCM substream
is stores to AMDTP domain structure. Some AMDTP streams have already
run with the buffer size when another PCM substream starts, therefore
the PCM substream has a constraint to its buffer size.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20191017155424.885-8-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This commit allows ALSA firewire-digi00x driver to share PCM buffer
size for both capture and playback PCM substream. When AMDTP domain
starts for one of the PCM substream, buffer size of the PCM substream
is stores to AMDTP domain structure. Some AMDTP streams have already
run with the buffer size when another PCM substream starts, therefore
the PCM substream has a constraint to its buffer size.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20191017155424.885-7-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This commit allows ALSA dice driver to share PCM buffer size for both
capture and playback PCM substream. When AMDTP domain starts for one
of the PCM substream, buffer size of the PCM substream is stores to
AMDTP domain structure. Some AMDTP streams have already run with the
buffer size when another PCM substream starts, therefore the PCM
substream has a constraint to its buffer size.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20191017155424.885-6-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This commit allows ALSA oxfw driver to share PCM buffer size for both
capture and playback PCM substream. When AMDTP domain starts for one
of the PCM substream, buffer size of the PCM substream is stores to
AMDTP domain structure. Some AMDTP streams have already run with the
buffer size when another PCM substream starts, therefore the PCM
substream has a constraint to its buffer size.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20191017155424.885-5-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This commit allows ALSA fireworks driver to share PCM buffer size for
both capture and playback PCM substream. When AMDTP domain starts for
one of the PCM substream, buffer size of the PCM substream is stores
to AMDTP domain structure. Some AMDTP streams have already run with the
buffer size when another PCM substream starts, therefore the PCM
substream has a constraint to its buffer size.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20191017155424.885-4-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This commit allows ALSA bebob driver to share PCM buffer size for both
capture and playback PCM substream. When AMDTP domain starts for one
of the PCM substream, buffer size of the PCM substream is stores to
AMDTP domain structure. Some AMDTP streams have already run with the
buffer size when another PCM substream starts, therefore the PCM
substream has a constraint to its buffer size.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20191017155424.885-3-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The number of packets in packet buffer has been fixed number (=48) since
first commit of ALSA IEC 61883-1/6 packet streaming engine.
This commit allows the engine to use variable number of packets in the
buffer. The size is calculated by a parameter in AMDTP domain structure
surely to store the number of events in the packets of buffer. Although
the value of parameter is expected to come from 'period size' parameter
of PCM substream, at present 48 is still used.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20191017155424.885-2-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
In current implementation, when opening a PCM substream, it's needed to
check whether the opposite PCM substream runs. This is to assign
effectual constraints (e.g. sampling rate) to opened PCM substream.
The number of PCM substreams on AMDTP streams in domain is recorded in
own structure. Usage of this count is an alternative of the above check.
This is better because the count is incremented in pcm.hw_params earlier
than pcm.trigger.
This commit replaces the check with the substream count and the value for
the size of PCM period. Unlike the other drivers in ALSA firewire stack,
no MIDI substream is multiplexed into AMDTP stream.
I note that Fireface AMDTP protocol has a quirk that tx stream includes
blank isochronous cycle. The packet for blank cycle is equivalent to
empty or NODATA packet in IEC 61883-6, thus the protocol is similar to
blocking transmission method of IEC 61883-6. On the other hand, rx
stream adopts non-blocking transmission method. Although the difference
of transmission method between tx/rx streams precisely brings different
timing for a certain amount of events due to their different calculation
for data blocks per packet, it's possible to approximate enough amount
of events mostly has the same timing. Actually current ALSA IEC 61883-1/6
engine uses large amount of data blocks for each hardware IRQ
(=16 packets).
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20191007110532.30270-18-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
In current implementation, when opening a PCM substream, it's needed to
check whether the opposite PCM substream runs. This is to assign
effectual constraints (e.g. sampling rate) to opened PCM substream.
The number of PCM substreams and MIDI substreams on AMDTP streams in
domain is recorded in own structure. Usage of this count is an
alternative of the above check. This is better because the count is
incremented in pcm.hw_params earlier than pcm.trigger.
This idea has one issue because it's incremented for MIDI substreams as
well. In current implementation, for a case that any MIDI substream run
and a PCM substream is going to start, PCM application to start the PCM
substream can decide hardware parameters by restart packet streaming.
Just checking the substream count can brings regression.
Now AMDTP domain structure has a member for the size of PCM period in
PCM substream which starts AMDTP streams in domain. When the value has
zero and the substream count is greater than 1, it means that any MIDI
substream starts AMDTP streams in domain. Usage of the value can resolve
the above issue.
This commit replaces the check with the substream count and the value for
the size of PCM period.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20191007110532.30270-17-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
In current implementation, when opening a PCM substream, it's needed to
check whether the opposite PCM substream runs. This is to assign
effectual constraints (e.g. sampling rate) to opened PCM substream.
The number of PCM substreams on AMDTP streams in domain is recorded in
own structure. Usage of this count is an alternative of the above check.
This is better because the count is incremented in pcm.hw_params earlier
than pcm.trigger.
This commit replaces the check with the substream count and the value for
the size of PCM period. Unlike the other drivers in ALSA firewire stack,
no MIDI substream is multiplexed into AMDTP stream.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20191007110532.30270-16-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
In current implementation, when opening a PCM substream, it's needed to
check whether the opposite PCM substream runs. This is to assign
effectual constraints (e.g. sampling rate) to opened PCM substream.
The number of PCM substreams and MIDI substreams on AMDTP streams in
domain is recorded in own structure. Usage of this count is an
alternative of the above check. This is better because the count is
incremented in pcm.hw_params earlier than pcm.trigger.
This idea has one issue because it's incremented for MIDI substreams as
well. In current implementation, for a case that any MIDI substream run
and a PCM substream is going to start, PCM application to start the PCM
substream can decide hardware parameters by restart packet streaming.
Just checking the substream count can brings regression.
Now AMDTP domain structure has a member for the size of PCM period in
PCM substream which starts AMDTP streams in domain. When the value has
zero and the substream count is greater than 1, it means that any MIDI
substream starts AMDTP streams in domain. Usage of the value can resolve
the above issue.
This commit replaces the check with the substream count and the value for
the size of PCM period.
I note that DOT AMDTP protocol has a quirk to use different transmission
method of IEC 61883-6 for tx/rx streams; non-blocking in tx stream and
blocking in rx stream. Although the difference of transmission method
between tx/rx streams precisely brings different timing for a certain
amount of events due to their different calculation for data blocks per
packet, it's possible to approximate enough amount of events mostly has
the same timing. Actually current ALSA IEC 61883-1/6 engine uses large
amount of data blocks for each hardware IRQ (=16 packets).
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20191007110532.30270-15-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
In current implementation, when opening a PCM substream, it's needed to
check whether the opposite PCM substream runs. This is to assign
effectual constraints (e.g. sampling rate) to opened PCM substream.
The number of PCM substreams and MIDI substreams on AMDTP streams in
domain is recorded in own structure. Usage of this count is an
alternative of the above check. This is better because the count is
incremented in pcm.hw_params earlier than pcm.trigger.
This idea has one issue because it's incremented for MIDI substreams as
well. In current implementation, for a case that any MIDI substream run
and a PCM substream is going to start, PCM application to start the PCM
substream can decide hardware parameters by restart packet streaming.
Just checking the substream count can brings regression.
Now AMDTP domain structure has a member for the size of PCM period in
PCM substream which starts AMDTP streams in domain. When the value has
zero and the substream count is greater than 1, it means that any MIDI
substream starts AMDTP streams in domain. Usage of the value can resolve
the above issue.
This commit replaces the check with the substream count and the value for
the size of PCM period.
Dice hardware has a quirk called as 'Dual Wire'. For a case of higher
sampling transmission frequency, this commit performs calculations between
the number of PCM frames and the number of events in AMDTP stream.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20191007110532.30270-14-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
In current implementation, when opening a PCM substream, it's needed to
check whether the opposite PCM substream runs. This is to assign
effectual constraints (e.g. sampling rate) to opened PCM substream.
The number of PCM substreams and MIDI substreams on AMDTP streams in
domain is recorded in own structure. Usage of this count is an
alternative of the above check. This is better because the count is
incremented in pcm.hw_params earlier than pcm.trigger.
This idea has one issue because it's incremented for MIDI substreams as
well. In current implementation, for a case that any MIDI substream run
and a PCM substream is going to start, PCM application to start the PCM
substream can decide hardware parameters by restart packet streaming.
Just checking the substream count can brings regression.
Now AMDTP domain structure has a member for the size of PCM period in
PCM substream which starts AMDTP streams in domain. When the value has
zero and the substream count is greater than 1, it means that any MIDI
substream starts AMDTP streams in domain. Usage of the value can resolve
the above issue.
This commit replaces the check with the substream count and the value for
the size of PCM period.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20191007110532.30270-13-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
In current implementation, when opening a PCM substream, it's needed to
check whether the opposite PCM substream runs. This is to assign
effectual constraints (e.g. sampling rate) to opened PCM substream.
The number of PCM substreams and MIDI substreams on AMDTP streams in
domain is recorded in own structure. Usage of this count is an
alternative of the above check. This is better because the count is
incremented in pcm.hw_params earlier than pcm.trigger.
This idea has one issue because it's incremented for MIDI substreams as
well. In current implementation, for a case that any MIDI substream run
and a PCM substream is going to start, PCM application to start the PCM
substream can decide hardware parameters by restart packet streaming.
Just checking the substream count can brings regression.
Now AMDTP domain structure has a member for the size of PCM period in
PCM substream which starts AMDTP streams in domain. When the value has
zero and the substream count is greater than 1, it means that any MIDI
substream starts AMDTP streams in domain. Usage of the value can resolve
the above issue.
This commit replaces the check with the substream count and the value for
the size of PCM period.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20191007110532.30270-12-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
In current implementation, when opening a PCM substream, it's needed to
check whether the opposite PCM substream runs. This is to assign
effectual constraints (e.g. sampling rate) to opened PCM substream.
The number of PCM substreams and MIDI substreams on AMDTP streams in
domain is recorded in own structure. Usage of this count is an
alternative of the above check. This is better because the count is
incremented in pcm.hw_params earlier than pcm.trigger.
This idea has one issue because it's incremented for MIDI substreams as
well. In current implementation, for a case that any MIDI substream run
and a PCM substream is going to start, PCM application to start the PCM
substream can decide hardware parameters by restart packet streaming.
Just checking the substream count can brings regression.
Now AMDTP domain structure has a member for the size of PCM period in
PCM substream which starts AMDTP streams in domain. When the value has
zero and the substream count is greater than 1, it means that any MIDI
substream starts AMDTP streams in domain. Usage of the value can resolve
the above issue.
This commit replaces the check with the substream count and the value for
the size of PCM period.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20191007110532.30270-11-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This commit is a preparation to share the size of PCM period between
PCM substreams on AMDTP streams in the same domain. At this time,
the size of PCM period in PCM substream which starts AMDTP streams in the
same domain is recorded.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20191007110532.30270-10-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This commit is a preparation to share the size of PCM period between
PCM substreams on AMDTP streams in the same domain. At this time,
the size of PCM period in PCM substream which starts AMDTP streams in the
same domain is recorded.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20191007110532.30270-9-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This commit is a preparation to share the size of PCM period between
PCM substreams on AMDTP streams in the same domain. At this time,
the size of PCM period in PCM substream which starts AMDTP streams in the
same domain is recorded.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20191007110532.30270-8-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This commit is a preparation to share the size of PCM period between
PCM substreams on AMDTP streams in the same domain. At this time,
the size of PCM period in PCM substream which starts AMDTP streams in the
same domain is recorded.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20191007110532.30270-7-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This commit is a preparation to share the size of PCM period between
PCM substreams on AMDTP streams in the same domain. At this time,
the size of PCM period in PCM substream which starts AMDTP streams in the
same domain is recorded.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20191007110532.30270-6-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This commit is a preparation to share the size of PCM period between
PCM substreams on AMDTP streams in the same domain. At this time,
the size of PCM period in PCM substream which starts AMDTP streams in the
same domain is recorded.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20191007110532.30270-5-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This commit is a preparation to share the size of PCM period between
PCM substreams on AMDTP streams in the same domain. At this time,
the size of PCM period in PCM substream which starts AMDTP streams in the
same domain is recorded.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20191007110532.30270-4-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This commit is a preparation to share the size of PCM period between
PCM substreams on AMDTP streams in the same domain. At this time,
the size of PCM period in PCM substream which starts AMDTP streams in the
same domain is recorded.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20191007110532.30270-3-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
In IEC 61883-6, it's called as 'event' what has presentation time
represented by timestamp in CIP header. Although the ratio of the number
of event against the number of data block is different depending on
event data type represented by the specific field in CIP header, it's
just one in the most cases supported by ALSA IEC 61883-1/6 engine.
In 1394 OHCI specification, applications can schedule hardware IRQ
by configuring descriptor with IRQ flag for packet against each
isochronous cycle. For future commit, I use the hardware IRQ for
isoc IT context to acknowledge the elapse of PCM period for both
playback/capture directions on AMDTP streams in the same domain.
This commit is a preparation for the above idea. This commit adds
a member into AMDTP domain structure to record the number of PCM frames.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20191007110532.30270-2-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Adjust indentation from spaces to tab (+optional two spaces) as in
coding style with command like:
$ sed -e 's/^ /\t/' -i */Kconfig
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Acked-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20191004144931.3851-1-krzk@kernel.org
Signed-off-by: Takashi Iwai <tiwai@suse.de>
At higher sampling rate (e.g. 192.0 kHz), Alesis iO26 transfers 4 data
channels per data block in CIP.
Both iO14 and iO26 have the same contents in their configuration ROM.
For this reason, ALSA Dice driver attempts to distinguish them according
to the value of TX0_AUDIO register at probe callback. Although the way is
valid at lower and middle sampling rate, it's lastly invalid at higher
sampling rate because because the two models returns the same value for
read transaction to the register.
In the most cases, users just plug-in the device and ALSA dice driver
detects it. In the case, the device runs at lower sampling rate and
the driver detects expectedly. For this reason, this commit leaves the
way to detect as is.
Fixes: 28b208f600a3 ("ALSA: dice: add parameters of stream formats for models produced by Alesis")
Cc: <stable@vger.kernel.org> # v4.18+
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20190916101851.30409-1-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2 bytes in MSB of register for clock status is zero during intermediate
state after changing status of sampling clock in models of TASCAM FireWire
series. The duration of this state differs depending on cases. During the
state, it's better to retry reading the register for current status of
the clock.
In current implementation, the intermediate state is checked only when
getting current sampling transmission frequency, then retry reading.
This care is required for the other operations to read the register.
This commit moves the codes of check and retry into helper function
commonly used for operations to read the register.
Fixes: e453df44f0d6 ("ALSA: firewire-tascam: add PCM functionality")
Cc: <stable@vger.kernel.org> # v4.4+
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20190910135152.29800-3-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The return value of snd_tscm_stream_get_clock() is ignored. This commit
checks the value and handle error.
Fixes: e453df44f0d6 ("ALSA: firewire-tascam: add PCM functionality")
Cc: <stable@vger.kernel.org> # v4.4+
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20190910135152.29800-2-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Quite a big update this time around, particularly in the core
where we've had a lot of cleanups from Morimoto-san - there's
not much functional change but quite a bit of modernization
going on. We've also seen a lot of driver work, a lot of it
cleanups but also some particular drivers.
- Lots and lots of cleanups from Morimoto-san and Yue Haibing.
- Lots of cleanups and enhancements to the Freescale, sunxi dnd
Intel rivers.
- Initial Sound Open Firmware suppot for i.MX8.
- Removal of w90x900 and nuc900 drivers as the platforms are
being removed.
- New support for Cirrus Logic CS47L15 and CS47L92, Freescale
i.MX 7ULP and 8MQ, Meson G12A and NXP UDA1334
-----BEGIN PGP SIGNATURE-----
iQFHBAABCgAxFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAl13cr4THGJyb29uaWVA
a2VybmVsLm9yZwAKCRAk1otyXVSH0NKuB/9fvRIh6bJ4pUA26Bc7+shJQ1BtC/MN
jo1G4maN+hY5ZUwE5hvg04S6W6Unm1iNotQecKcF43Vh/4SZNiLtfSEM4b/6IBWw
IFUU6xDz8Q4HbF4HJMotpKQKMABpfds5flH2e1YrrNoMH+KlkC9kJOR26B2W36xW
TZclfquCDICxr8M7eYGM7N5hOqSrlugyWBZqTTnTDnsMrW4SAaH2HYwFhaeayd+I
ECyaXIoUHvo4FX5ueZv/mzBiMl0z4rgXn3tuqI6a8LoWJdRZTkcSQabtuIC+wmxb
P734RY6vjSUYZrv03cAtxHDrSVoC/RYedOzhT+iFF6y/NHzdu701lsJb
=aD0T
-----END PGP SIGNATURE-----
Merge tag 'asoc-v5.4' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-next
ASoC: Updates for v5.4
Quite a big update this time around, particularly in the core
where we've had a lot of cleanups from Morimoto-san - there's
not much functional change but quite a bit of modernization
going on. We've also seen a lot of driver work, a lot of it
cleanups but also some particular drivers.
- Lots and lots of cleanups from Morimoto-san and Yue Haibing.
- Lots of cleanups and enhancements to the Freescale, sunxi dnd
Intel rivers.
- Initial Sound Open Firmware suppot for i.MX8.
- Removal of w90x900 and nuc900 drivers as the platforms are
being removed.
- New support for Cirrus Logic CS47L15 and CS47L92, Freescale
i.MX 7ULP and 8MQ, Meson G12A and NXP UDA1334
The destructor of AMDTP domain has WARN_ON() for the list of associated
AMDTP stream. Although this reminds a case that developers forget to
program consumer drivers to stop AMDTP domain, it hits when AMDTP domain
is not initialized yet. This occurs when initialization of sound card
fails as well and it's superfluous.
This commit removes the WARN_ON. Although the API to AMDTP domain does
nothing, it's left for future usage.
Fixes: 3ec3d7a3ff106 ("ALSA: firewire-lib: add AMDTP domain structure to handle several isoc contexts")
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20190906131414.15370-1-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
TASCAM FE-8 is the rest of model in TASCAM FireWire series. This device
has no functionality to process audio signal and MIDI messages. Instead,
it transfers control messages to host system corresponding to operations
for some faders, buttons and knobs on its surface.
Unlike the other devices in this series, the control messages are
transmitted by asynchronous transactions. Some registers of device are
used for registration of destination address for the transaction. The
transaction includes quadlet-aligned data up to 32 quadlets.
Userspace applications can receive the transaction and parse it for
control message via Linux FireWire subsystem, without any support by
ALSA firewire-tascam driver. Therefore the driver gives no support
for it.
This commit removes placeholder for FE-8 and add some comment for its
functionalities as notes.
$ python2 linux-firewire-utils/src/crpp < ~/git/am-config-rom/tascam/tascam-fe8.img
ROM header and bus information block
-----------------------------------------------------------------
400 040f4798 bus_info_length 4, crc_length 15, crc 18328 (should be 14256)
404 31333934 bus_name "1394"
408 20ff7002 irmc 0, cmc 0, isc 1, bmc 0, cyc_clk_acc 255, max_rec 7 (256)
40c 00022eff company_id 00022e |
410 a094dcb7 device_id ffa094dcb7 | EUI-64 00022effa094dcb7
root directory
-----------------------------------------------------------------
414 0004bccc directory_length 4, crc 48332
418 0300022e 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 0003eda4 directory_length 3, crc 60836
42c 1200022e specifier id
430 13800001 version
434 d4000004 --> dependent info directory at 444
eui-64 leaf at 438
-----------------------------------------------------------------
438 0002461e leaf_length 2, crc 17950
43c 00022eff company_id 00022e |
440 a094dcb7 device_id ffa094dcb7 | EUI-64 00022effa094dcb7
dependent info directory at 444
-----------------------------------------------------------------
444 0002ae47 directory_length 2, crc 44615
448 81000002 --> descriptor leaf at 450
44c 82000006 --> bus dependent info leaf at 464
descriptor leaf at 450
-----------------------------------------------------------------
450 0004a79e leaf_length 4, crc 42910
454 00000000 textual descriptor
458 00000000 minimal ASCII
45c 54415343 "TASC"
460 414d0000 "AM"
bus dependent info leaf at 464
-----------------------------------------------------------------
464 0004a7d8 leaf_length 4, crc 42968
468 00000000
46c 00000000
470 46452d38
474 00000000
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20190906125544.13800-1-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
