For Lexicon I-ONIX FW810S, the call of ioctl(2) with
SNDRV_PCM_IOCTL_HW_PARAMS can returns -ETIMEDOUT. This is a regression due
to the commit 41319eb56e ("ALSA: dice: wait just for
NOTIFY_CLOCK_ACCEPTED after GLOBAL_CLOCK_SELECT operation"). The device
does not emit NOTIFY_CLOCK_ACCEPTED notification when accepting
GLOBAL_CLOCK_SELECT operation with the same parameters as current ones.
This commit fixes the regression. When receiving no notification, return
-ETIMEDOUT as long as operating for any change.
Fixes: 41319eb56e ("ALSA: dice: wait just for NOTIFY_CLOCK_ACCEPTED after GLOBAL_CLOCK_SELECT operation")
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20221130130604.29774-1-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This commit takes ALSA dice driver to perform sequence replay for media
clock recovery.
Unlike the other types of device, DICE-based devices interpret the value
of syt field of CIP header in rx packets as presentation time for audio
playback, thus it's required for driver to compute value for outgoing
packet adequate to the device. It's done by media clock recovery by
handling tx packets.
The device starts packet transmission immediately at operation to
GLOBAL_ENABLE thus on-the-fly mode is not required.
DICE ASICs supports several pairs of isochronous packet streams.
Actually, maximum two pairs of streams are supported by devices.
We have three cases regarding to the number of streams:
1. a pair of streams
2. two tx packet streams and one rx packet streams
3. one tx packet streams and two rx packet streams
4. two pair of streams
The decision of playback timing is slightly different in the four cases.
In the case 1, sequence replay in the pair results in suitable playback
timing.
In the case 2, sequence replay from the first tx packet stream to rx
packet stream results in suitable playback timing.
In the case 3, sequence replay from tx packet stream to all of rx packet
stream results in suitable playback timing. Furthermore, the cycle to
start receiving packets should be the same between all rx packet streams.
In the case 4, sequence replay in each pair results in suitable playback
timing. Furthermore, the cycle to start receiving packets should be the
same between all rx packet streams.
The sequence replay is tested with below models:
* For case 1:
* TC Electronic Konnekt 24d (DiceII)
* TC Electronic Konnekt 8 (DiceII)
* TC Electronic Konnekt Live (DiceII)
* TC Electronic Impact Twin (DiceII)
* TC Electronic Digital Konnekt X32 (DiceII)
* TC Electronic Desktop Konnekt 6 (TCD2220)
* Solid State Logic Duende Classic (DiceII)
* Solid State Logic Duende Mini (DiceII)
* PreSonus FireStudio Project (TCD2210)
* PreSonus FireStudio Mobile (TCD2210)
* Lexicon I-ONIX FW810s (TCD2220)
* Avid Mbox 3 Pro (TCD2220)
* For case 2 (but case 1 depends on sampling transfer frequency):
* Alesis iO 26 (DiceII)
* Alesis iO 14 (DiceII)
* Alesis MultiMix 12 FireWire (DiceII)
* Focusrite Saffire Pro 26 (TCD2220)
* For case 3 (but case 1 depends on sampling transfer frequency):
* M-Audio Profire 610 (TCD2220)
* Loud Technology Mackie Onyx Blackbird (TCD2210)
* For case 4:
* TC Electronic Studio Konnekt 48 (DiceII + TCD2220)
* PreSonus FireStudio (DiceII)
* M-Audio Profire 2626 (TCD2220)
* Focusrite Liquid Saffire 56 (TCD2220)
* Focusrite Saffire Pro 40 (TCD2220)
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20210601081753.9191-3-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
NOTIFY_CLOCK_ACCEPTED notification is always generated as a result of
GLOBAL_CLOCK_SELECT operation, however NOTIFY_LOCK_CHG notification
doesn't, as long as the selected clock is already configured. In the case,
ALSA dice driver waits so long. It's inconvenient for some devices to lock
to the sequence of value in syt field of CIP header in rx packets.
This commit wait just for NOTIFY_CLOCK_ACCEPTED notification by reverting
changes partially done by two commits below:
* commit fbeac84dbe ("ALSA: dice: old firmware optimization for Dice notification")
* commit aec045b80d ("ALSA: dice: change notification mask to detect lock status change")
I note that the successful lock to the sequence of value in syt field of
CIP header in rx packets results in NOTIFY_EXT_STATUS notification, then
EXT_STATUS_ARX1_LOCKED bit stands in GLOBAL_EXTENDED_STATUS register.
The notification can occur enough after receiving the batch of rx packets.
When the sequence doesn't include value in syt field of CIP header in rx
packets adequate to the device, the notification occurs again and the bit
is off.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20210601081753.9191-2-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Models in below series start transmission of packet after receiving the
sequence of packets:
* Digidesign Digi00x family
* RME Fireface series
Additionally, models in Tascam FireWire series start multiplexing PCM
frames into packets enough after receiving packets. It's required to
transfer packets on-the-fly for the above models according to nominal
sampling transfer frequency before starting sequence replay.
This commit allows drivers to decide whether the engine transfers packet
on-the-fly or not.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20210527122611.173711-4-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
In design of audio and music unit in IEEE 1394 bus, feedback of
effective sampling transfer frequency (STF) is delivered by packets
transferred from device. The devices supported by ALSA firewire stack
are categorized to three groups regarding to it.
* Group 1:
* Echo Audio Fireworks board module
* Oxford Semiconductor OXFW971 ASIC
* Digidesign Digi00x family
* Tascam FireWire series
* RME Fireface series
* Group 2:
* BridgeCo. DM1000/DM1100/DM1500 ASICs for BeBoB solution
* TC Applied Technologies DICE ASICs
* Group 3:
* Mark of the Unicord FireWire series
In group 1, the effective STF is determined by the sequence of the number
of events per packet. In group 2, the sequence of presentation timestamp
expressed in syt field of CIP header is interpreted as well. In group 3,
the presentation timestamp is expressed in source packet header (SPH) of
each data block.
I note that some models doesn't take care of effective STF with large
internal buffer. It's reasonable to name it as group 0:
* Group 0
* Oxford Semiconductor OXFW970 ASIC
The effective STF is known to be slightly different from nominal STF for
all of devices, and to be different between the devices. Furthermore, the
effective STF is known to be shifted for long-period transmission. This
makes it hard for software to satisfy the effective STF when processing
packets to the device.
The effective STF is deterministic as a result of analyzing the batch of
packet transferred from the device. For the analysis, caching the sequence
of parameter in the packet is required.
This commit adds an option so that AMDTP domain structure takes AMDTP
stream structure to cache the sequence of parameters in packet transferred
from the device. The parameters are offset ticks of syt field against the
cycle to receive the packet and the number of data blocks per packet.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20210527122611.173711-2-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
When starting AMDTP domain, tasks in process context yields running CPU
till all of isochronous context get callback, with an assumption that
it's OK to process content of packet.
However several isochronous cycles are skipped to transfer rx packets, or
the content of rx packets are dropped, to manage the timing to start
processing the packets.
This commit changes the timing for tasks in process context to wake up
when processing content of packet is actually ready.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20210520040154.80450-9-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
ALSA dice driver detects jumbo payload at high sampling transfer frequency
for below models:
* Avid M-Box 3 Pro
* M-Audio Profire 610
* M-Audio Profire 2626
Although many DICE-based devices have a quirk at high sampling transfer
frequency to multiplex double number of PCM frames into data block than
the number in IEC 61883-1/6, the above devices are just compliant to
IEC 61883-1/6.
This commit disables the mode of double_pcm_frames for the models.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20210518012510.37126-1-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
When node is removed from IEEE 1394 bus, any transaction fails to the node.
In the case, ALSA dice driver doesn't stop isochronous contexts even if
they are running. As a result, null pointer dereference occurs in callback
from the running context.
This commit fixes the bug to release isochronous contexts always.
Cc: <stable@vger.kernel.org> # v5.4 or later
Fixes: e9f21129b8 ("ALSA: dice: support AMDTP domain")
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20210312093407.23437-1-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
ALSA dice driver expects devices to multiplex MIDI messages into first
port of isochronous communication. Actually devices perform for it.
However, check of stream format is invalid for second port of isochronous
communication. As a result, when the device supports two ports for
isochronous communication and the stream format is hard-coded, ALSA
dice driver fails to start packet streaming.
This commit loosens stream format check for MIDI conformant data channel.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20200113084630.14305-3-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 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>
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>
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>
When introducing AMDTP domain to ALSA dice driver, error path does not
handle error correctly. This commit fixes the bug.
Fixes: e9f21129b8 ("ALSA: dice: support AMDTP domain")
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This is a very big update, mainly thanks to Morimoto-san's refactoring
work and some fairly large new drivers.
- Lots more work on moving towards a component based framework from
Morimoto-san.
- Support for force disconnecting muxes from Jerome Brunet.
- New drivers for Cirrus Logic CS47L35, CS47L85 and CS47L90, Conexant
CX2072X, Realtek RT1011 and RT1308.
-----BEGIN PGP SIGNATURE-----
iQFHBAABCgAxFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAl0jGwUTHGJyb29uaWVA
a2VybmVsLm9yZwAKCRAk1otyXVSH0LD4B/9AkutfS+vznOrk0V0wFb2SUfjwE4Pr
+z/kAehohAOl/7pg9Dun/lmZYBWMyOM2aYmK81ahEo2DfO+uzwkwjCaXFjGVGwEK
j7XpWkrIjKnou/z1FeALgVvt+crzdy5iNWC04AbKaP2WHCcI7zvPQIsBta/V0OJt
lg+j0J7pagnTMcgV1+qJdaASmofy/hpoZ79Gv0PIfGC8hpJ/3mBgcNPCLQrJtD4R
v+tzvCZNrZVqCanwLf3vouEm1bpWYOpI+Wdmu4u6rY7MhmCj72EJ2zyfdm/qtaxF
e7whgCyOQFkWe7NgDn0G08aAT6LsaxOtPNr7H8tL8S8sw8425fqeOouV
=n/HQ
-----END PGP SIGNATURE-----
Merge tag 'asoc-v5.3' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus
ASoC: Updates for v5.3
This is a very big update, mainly thanks to Morimoto-san's refactoring
work and some fairly large new drivers.
- Lots more work on moving towards a component based framework from
Morimoto-san.
- Support for force disconnecting muxes from Jerome Brunet.
- New drivers for Cirrus Logic CS47L35, CS47L85 and CS47L90, Conexant
CX2072X, Realtek RT1011 and RT1308.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
>From callbacks for pcm and rawmidi interfaces, the functions to stop
and release duplex streams are called at the same time. This commit
merges the two functions.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This commit fixes the warning due to returning uninitialized value
from start_streams() helper function.
sound/firewire/dice/dice-stream.c: In function 'start_streams.isra.0':
>> sound/firewire/dice/dice-stream.c:350:6: warning: 'err' may be used uninitialized in this function [-Wmaybe-uninitialized]
int err;
^~~
Reported-by: kbuild test robot <lkp@intel.com>
Fixes: 3cd2c2d780 ("ALSA: dice: reserve/release isochronous resources in pcm.hw_params/hw_free callbacks")
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
After bus reset, isochronous resource manager releases all of allocated
isochronous resources. The nodes to transfer isochronous packet should
request reallocation of the resources.
However, between the bus-reset and invocation of 'struct fw_driver.update'
handler, ALSA PCM application can detect this situation by XRUN because
the target device cancelled to transmit packets once bus-reset occurs.
Due to the above mechanism, ALSA fireface driver just stops packet
streaming in the update handler, thus pcm.prepare handler should
request the reallocation.
This commit requests the reallocation in pcm.prepare callback when
bus generation is changed.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Once allocated, isochronous resources are available for packet
streaming, even if the streaming is cancelled. For this reason,
current implementation handles allocation of the resources and
starting packet streaming at the same time. However, this brings
complicated procedure to start packet streaming.
This commit separates the allocation and starting. The allocation is
done in pcm.hw_params callback and available till pcm.hw_free callback.
Even if any XRUN occurs, pcm.prepare callback is done to restart
packet streaming without releasing/allocating the resources.
There are two points to stop packet streaming; in pcm.hw_params and
pcm.prepare callbacks. The former point is a case that packet streaming
is already started for any MIDI substream then packet streaming is
requested with different sampling transfer frequency for any PCM
substream. The latter point is cases of any XRUN or packet queueing
error.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This commit is a part of preparation to perform allocation/release
of isochronous resources in pcm.hw_params/hw_free callbacks.
This commit adds a helper function to allocate isochronous resources,
separated from operations to start packet streaming, I note that some
dice-based devices have two pair of endpoints for isochronous packet
straeming.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This commit is a part of preparation to perform allocation/release
of isochronous resources in pcm.hw_params/hw_free callbacks.
There're three points to finish packet streaming but no helper
functions for common operations for it. This commit adds a helper
function for operations to finish packet streaming.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Based on 1 normalized pattern(s):
licensed under the terms of the gnu general public license version 2
extracted by the scancode license scanner the SPDX license identifier
GPL-2.0-only
has been chosen to replace the boilerplate/reference in 88 file(s).
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Alexios Zavras <alexios.zavras@intel.com>
Reviewed-by: Allison Randal <allison@lohutok.net>
Cc: linux-spdx@vger.kernel.org
Link: https://lkml.kernel.org/r/20190530000437.521539229@linutronix.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This is a preparation for userspace applications to change current sampling
transmission frequency via ALSA PCM interface.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This commit is a small refactoring for better readability.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
At present, to check running stream, available stream formats are used
at current sampling transmission frequency (stf). But when changing stf,
it's convenient to use cache of stream formats.
This commit applies this idea.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
TC Applied Technologies (TCAT) have added extension to DICE protocol. This
protocol extension is called as Extended Application Protocol, a.k.a. EAP.
In this protocol extension, units get additional 9 address spaces. One of
it is for current configuration. In this address space, a pair of router
and stream formats are exposed per mode of three sampling transmission
frequencies.
This commit adds support the protocol extension for address space of the
current configuration to generate cache of stream formats.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
In former commits, proxy structure get members for cache of stream
formats. This commit fills the cache with stream formats at current mode
of sampling transmission frequency.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
In error path of snd_dice_stream_init_duplex(), stream data for incoming
packet can be left to be initialized.
This commit fixes it.
Fixes: 436b5abe22 ('ALSA: dice: handle whole available isochronous streams')
Cc: <stable@vger.kernel.org> # v4.6+
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
As of kernel 4.10, ALSA dice driver is expected to be used in default
speed. In most cases, it's S400. While, IEEE 1394 specification describes
the other speed such as S800.
According to 'TCD30XX User Guide', its link layer controller supports
several transmission speed up to S800[0]. In Dice software interface,
transmission speed in output direction can be configured by asynchronous
transaction to 'TX_SPEED' offset in its address space. S800 may be
available.
This commit improves configuration of transmission unit before starting
packet streaming for this purpose. The value of 'max_speed' in 'fw_device'
data structure has available maximum speed decided in bus arbitration,
thus it's within capacity of the unit.
[0] TCD3xx User Guide - TCAT 1394 LLC, Revision 0.9.0-41360 (TC Applied Technologies, May 6 2015)
http://www.tctechnologies.tc/index.php/support/support-hardware/dice-iii-detailed-documentation
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
When sound card is going to be released, dice private data is
also released. Then all of data should be released. However,
stream data is not released. This causes memory leak when
unplugging dice unit.
This commit fixes the bug.
Fixes: 4bdc495c87b3('ALSA: dice: handle several PCM substreams when any isochronous streams are available')
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
In dice interface, two blocks of register are accessible via IEEE 1394
asynchronous transaction to represent the number of supported isochronous
streams and the number of quadlets for stream information.
Current ALSA dice driver uses array with 'unsigned int' element for
temporary cache of these information. But using structure is preferable
for begin easily comprehensible.
This commit applies a local structure for this aim.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This commit enables ALSA dice driver to handle whole available streams.
In Dice, certain registers represent the number of available streams at
current sampling transfer frequency for both directions. The parameters
of each stream are represented in a block of register. This block is
aligned sequentially. These streams start simultaneously by writing
enable bit to a register.
This commit operates these registers when starting/stopping streams.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Currently ALSA dice driver handles a pair of isochronous resources for
IEC 61883-1/6 packet streaming. While, according to some documents about
ASICs named as 'Dice', several isochronous streams are available.
Here, I start to describe ASICs produced under 'Dice' name.
* Dice II (designed by wavefront semiconductor, including TCAT's IP)
* STD (with limited functionality of DTCP)
* CP (with full functionality of DTCP)
* TCD2210/2210-E (so-called 'Dice Mini')
* TCD2220/2220-E (so-called 'Dice Jr.')
* TCD3070-CH (so-called 'Dice III')
Some documents are public and we can see hardware design of them. We can
find some articles about hardware internal register definitions
(not registers exported to IEEE 1394 bus).
* DICE II User Guide
* http://www.tctechnologies.tc/archive/downloads/dice_ii_user_guide.pdf
* 6.1 AVS Audio Receivers
* Table 6.1: AVS Audio Receiver Memory Map
* ARX1-ARX4
* 6.2 AVS Audio Transmitters
* Table 6.2: AVS Audio Transmitter Memory Map
* ATX1, ATX2
* TCD22xx User Guide
* http://www.tctechnologies.tc/downloads/tcd22xx_user_guide.pdf
* 6.1 AVS Audio Receivers
* Table 66: AVS Audio Receiver Memory Map
* ARX1, ARX2
* 6/2 AVS Audio Transmitters
* Table 67: AVS Audio Transmitter Memory Map
* ATX1, ATX2
* DICE III
* http://www.tctechnologies.tc/downloads/TCD3070-CH.pdf
* Dual stream 63 channel transmitter/receiver
For Dice II and TCD22xx series, maximum 16 data channels are transferred in
an AMDTP packet, while for Dice III, maximum 32 data channels are
transferred.
According to the design of the series of these ASICs, this commit allows
this driver to handle additional set of isochronous resources. For
practical reason, two pair of isochronous resources are added. As of this
commit, this driver still use a pair of the first isochronous resources.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This commit drops implementation of duplex streams synchronization
from ALSA dice driver, due to a reason of hardware design. This patch
allows dice-based units to generate sounds correctly when isochronous
packet streaming starts at first time.
In IEC 61883-6:2005, CIP packetization layer for AM824 data format
utilizes the value of SYT field in CIP header of received packet for
a reference to phase lock loop. Figure 3 in clause 4.3 describes it.
The value is an offset from cycle_time field of every cycle start packet
from cycle master on IEEE 1394 bus. The time calculated with these two
fields is called as 'presentation timestamp' which represents the time
to play data included in the packet.
Although, this idea includes some problems due to accuracy of timekeep in
cycle master, accuracy of transmission of cycle start packet on the bus
with the other units, accuracy of sampling clock in data transmitter side
and accuracy of replay in data receiver side. In most case, these
accuracies somewhat worse because there's no such ideal hardwares in this
world.
For the issues, ASICs for Dice include Jitter Elimination Technologies
(JET) PLL. The PLL can handle several sources of clock and compensate it
with high-precision internal clock source. The sequence of value in syt
field of received AMDTP packets is one of the sources, therefore
transmitters on IEEE 1394 bus should transfer it.
On the other hand, current ALSA dice driver is programmed with a mode of
duplex streams with synchronization. In this mode, the driver outputs
packets after some incoming packets are handled, to re-use the value of
SYT field in incoming packets to the value for outgoing packets. This mode
is enabled when source signal of sampling clock is set to internal, and
this is a major use case. Thus, in most cases, the unit receives no packets
during a short time after packet streaming starts.
As long as I experienced, this causes the units to generate no sounds at
first time to receive packets. This issue occurs only with Dice II. I guess
this is due to a quirk of the PLL. In short, the PLL cannot generate firm
signals to ADCs/DACs or the other ICs when no packets are received in the
beginning of packet streaming. While, on second time or later, the unit
generates sound correctly. I guess that starting packet streaming at first
time sets the PLL correctly.
Well, still based on my hypothesis and no way to prove it, this commit
drops duplex streams synchronization from this driver. At least, the PLL
requires the sequence of value in SYT field of received AMDTP packets as
one of source of clock signals with internal clock source.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
As long as I tested, Dice-based models produced by TC Electronic with
factory-configured settings transfer no notification within
ensure_phase_lock(). On the other hand, with upgraded firmwares, it
starts to transfer the notification. This seems to be a quirk of earlier
firmwares.
This commit ensures phase lock by reading a register after waiting for
the notification. Even if it's timed-out, ensure_phase_lock() return
success as long as the register has expected clock status.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
In former commits, probing process has no need to set sampling transfer
frequency. Although it's OK to drop a function to change the frequency
from this module, some models require it before streaming. This seems to
be due to phase lock of clock source.
This commit moves the function from transaction layer to stream layer, and
rename it according to the purpose.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Dice interface design doesn't allow drivers to read supported combination
between sampling transfer frequencies and the number of Multi bit linear
audio data channels. Due to the design, ALSA dice driver changes current
sampling transfer frequency to generate cache of the combinations at
device probing processing.
Although, this idea is worse because ALSA dice driver changes the state of
clock. This is not what users want when they save favorite configuration
to the device in advance.
Furthermore, there's a possibility that the format of data block is decided
not only according to current sampling transfer frequency, but also the
other factors, i.e. data format for digital interface. It's not good to
generate channel cache according to the sampling transfer frequency only.
This commit purges processing cache data and related structure members. As
a result, users must set preferable sampling transfer frequency before
using ALSA PCM applications, as long as they want to start any PCM
substreams at the rate except for current one.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
In previous commit, ALSA Dice driver limits PCM substreams at current
sampling transfer frequency and current number of Multi bit linear audio
data channel. Thus, the driver has no need to start AMDTP streams at
the other sampling transfer frequency except for current one. This is due
to Dice interface design.
This commit limits AMDTP stream at current sampling transfer frequency,
according to the design.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Some local variables in some functions are typed as unsigned int, while
__be32 value is assigned to them. This causes sparse warnings.
dice-stream.c:50:17: warning: incorrect type in assignment (different base types)
dice-stream.c:50:17: expected unsigned int [unsigned] channel
dice-stream.c:50:17: got restricted __be32 [usertype] <noident>
dice-stream.c:74:17: warning: incorrect type in assignment (different base types)
dice-stream.c:74:17: expected unsigned int [unsigned] channel
dice-stream.c:74:17: got restricted __be32 [usertype] <noident>
This commit fixes this bug.
Fixes: 288a8d0cb04f('ALSA: dice: Change the way to start stream')
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
In IEC 61883-6, several types of data are available in AM824 format. The
data is transferred in each data channel. The position of data channel in
data block differs depending on model.
Current implementation has an array to map the index of data channel in an
data block to the position of actual data channel. The implementation
allows each driver to access the mapping directly.
In later commit, the mapping is in specific structure pushed into an
opaque pointer. Helper functions are required.
This commit adds the helper functions for this purpose. In IEC 61883-6,
AM824 format supports many data types, while this specification easily
causes over-engineering. Current AM824 implementation is allowed to handle
two types of data, Multi Bit Linear Audio data (=PCM samples) and MIDI
conformant data (=MIDI messages).
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The value of FDF field in CIP header is protocol-dependent. Thus, it's
better to allow data block processing layer to decide the value in any
timing.
In AM824 data format, the value of FDF field in CIP header indicates
N-flag and Nominal Sampling Frequency Code (sfc). The N-flag is for
switching 'Clock-based rate control mode' and 'Command-based rate control
mode'. In our implementation, 'Clock-based rate control mode' is just
supported. Therefore, When sampling transfer frequency is decided, then
the FDF can be set.
This commit replaces 'amdtp_stream_set_parameters' with
'amdtp_am824_set_parameters' to set the FDF. This is the same timing
to decide the ration between the number of data blocks and the number of
PCM frames.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This commit adds data block processing layer for AM824 format. The new
layer initializes streaming layer with its value for fmt field.
Currently, most implementation of data block processing still remains
streaming layer. In later commits, these codes will be moved to the layer.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
In IEC 61883-6, one data block represents one event. In ALSA, the event is
one PCM frame. Therefore, when processing one data block, current
implementation counts one PCM frame.
On the other hand, Dice platform has a quirk called as 'dual wire' at
higher sampling rate. In detail, see comment of commit 6eb6c81eee
("ALSA: dice: Split stream functionality into a file").
Currently, to handle this quirk, AMDTP stream structure has a
'double_pcm_frames' member. When this is enabled, two PCM frames are
counted. Each driver set this flag by accessing the structure member
directly.
In future commit, some members related to AM824 data block will be moved
to specific structure, to separate packet streaming layer and data block
processing layer. The access will be limited by opaque pointer.
For this reason, this commit adds an argument into
amdtp_stream_set_parameter() to set the flag.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Currently, amdtp_stream_set_parameters() returns no error even if wrong
arguments are given. This is not good for streaming layer because drivers
can continue processing ignoring capability of streaming layer.
This commit changes this function to return error code.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Currently stream destructor in each driver has a problem to be called in
a context in which sound card object is released, because the destructors
call amdtp_stream_pcm_abort() and touch PCM runtime data.
The PCM runtime data is destroyed in application's context with
snd_pcm_close(), on the other hand PCM substream data is destroyed after
sound card object is released, in most case after all of ALSA character
devices are released. When PCM runtime is destroyed and PCM substream is
remained, amdtp_stream_pcm_abort() touches PCM runtime data and causes
Null-pointer-dereference.
This commit changes stream destructors and allows each driver to call
it after releasing runtime.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Cc: <stable@vger.kernel.org> # 3.19+
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This commit adds a support for MIDI capture/playback
When MIDI substrams already start streaming and PCM substreams are going to
join at different sampling rate, streams are stopped once. Then sampling rate
is changed and streams are restarted.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Acked-by: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This commit allows this driver to handle devices with non SYT-Match
sampling clock source.
When sampling clock source is SYT-Match mode, devices handle
'presentation timestamp' in received packets and generates sampling clock
according to the information. In this case, driver is synchronization master
and must transfer correct value in SYT field of each packets in outgoing
stream, then the outgoing stream is a master stream.
On the other hand, non SYT-Match mode, devices do this. So drivers must pick
up the value in SYT field of incoming packets and use the value for outgoing
stream. Currently firewire-lib module achieve this work.
Furthermore, without SYT-Match and internal clock source, the sampling rate
should be fixed for the other devices connected to the handled device. This
commit add a restriction of sampling rate at this situation.
With these implementations, this driver has no need to set clock source.
This commit remove set function.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Acked-by: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This commit adds support for AMDTP in-stream. As a result, Dice driver
supports full duplex streams with synchronization.
AMDTP can transfer timestamps in its packets. By handling the timestamp,
devices can synchronize to the other devices or drivers on the same bus.
When Dice chipset is 'enabled', it starts streams with correct settings.
This 'enable' register is global, thus, when a stream is started to run,
an opposite stream can't start unless turning off 'enable'. Therefore
a pair of streams must be running. This causes a loss of CPU usage when
single stream is needed for neither playbacking or capturing.
This commit assumes that playback-only models also have a functionality
to transmit stream for delivering timestamps.
Currently, sampling clock source is restricted to SYT-Match mode. This is
improved in followed commit. I note that at SYT-Match mode, Dice can select
from 4 streams for synchronization but this driver uses the 1st stream only
for simplicity.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Acked-by: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
