linux-dev/sound/firewire/dice, branch master

ALSA: firewire: Replace runtime->status->state reference to runtime->state

2022-09-27T06:47:25Z

The recent change in ALSA core allows drivers to get the current PCM state directly from runtime object. Replace the calls accordingly. Reviewed-by: Jaroslav Kysela Link: https://lore.kernel.org/r/20220926135558.26580-5-tiwai@suse.de Signed-off-by: Takashi Iwai

ALSA: firewire: Remove some left-over license text in sound/firewire

2022-09-27T06:42:18Z

There is already a SPDX-License-Identifier tag, so the corresponding license text can be removed. While at it, be more consistent and: - add a missing .c (ff-protocol-latter) - remove an empty line (motu-protocol-v1) Signed-off-by: Christophe JAILLET Link: https://lore.kernel.org/r/2bfe76c7eeb0f5205a1427e280bf8d9da0354a62.1664110649.git.christophe.jaillet@wanadoo.fr Signed-off-by: Takashi Iwai

ALSA: dice: cease from delayed card registration

2021-06-07T15:14:14Z

The delayed registration of sound card instance brings less benefit than complication of kobject management. This commit ceases from it. Signed-off-by: Takashi Sakamoto Link: https://lore.kernel.org/r/20210607081250.13397-5-o-takashi@sakamocchi.jp Signed-off-by: Takashi Iwai

ALSA: dice: perform sequence replay for media clock recovery

2021-06-01T16:36:42Z

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 Link: https://lore.kernel.org/r/20210601081753.9191-3-o-takashi@sakamocchi.jp Signed-off-by: Takashi Iwai

ALSA: dice: wait just for NOTIFY_CLOCK_ACCEPTED after GLOBAL_CLOCK_SELECT operation

2021-06-01T16:36:18Z

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 fbeac84dbe9e ("ALSA: dice: old firmware optimization for Dice notification") * commit aec045b80d79 ("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 Link: https://lore.kernel.org/r/20210601081753.9191-2-o-takashi@sakamocchi.jp Signed-off-by: Takashi Iwai

ALSA: firewire-lib: transfer rx packets on-the-fly when replaying

2021-05-28T09:06:33Z

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 Link: https://lore.kernel.org/r/20210527122611.173711-4-o-takashi@sakamocchi.jp Signed-off-by: Takashi Iwai

ALSA: firewire-lib: add replay target to cache sequence of packet

2021-05-28T08:44:01Z

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 Link: https://lore.kernel.org/r/20210527122611.173711-2-o-takashi@sakamocchi.jp Signed-off-by: Takashi Iwai

ALSA: firewire-lib: change waking up timing to process packets

2021-05-20T12:01:17Z

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 Link: https://lore.kernel.org/r/20210520040154.80450-9-o-takashi@sakamocchi.jp Signed-off-by: Takashi Iwai

ALSA: dice: fix stream format for TC Electronic Konnekt Live at high sampling transfer frequency

2021-05-18T06:57:54Z

At high sampling transfer frequency, TC Electronic Konnekt Live transfers/receives 6 audio data frames in multi bit linear audio data channel of data block in CIP payload. Current hard-coded stream format is wrong. Cc: Fixes: f1f0f330b1d0 ("ALSA: dice: add parameters of stream formats for models produced by TC Electronic") Signed-off-by: Takashi Sakamoto Link: https://lore.kernel.org/r/20210518012612.37268-1-o-takashi@sakamocchi.jp Signed-off-by: Takashi Iwai

ALSA: dice: disable double_pcm_frames mode for M-Audio Profire 610, 2626 and Avid M-Box 3 Pro

2021-05-18T06:57:21Z

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 Link: https://lore.kernel.org/r/20210518012510.37126-1-o-takashi@sakamocchi.jp Signed-off-by: Takashi Iwai