| 4e9050e5 | 01-Dec-2022 |
Takashi Sakamoto <o-takashi@sakamocchi.jp> |
ALSA: dice: Remove left-over license text
Following a commit 1dd0dd0b1fef ("ALSA: firewire: Remove some left-over license text in sound/firewire"), this patch removes it added carelessly.
Fixes: 21
ALSA: dice: Remove left-over license text
Following a commit 1dd0dd0b1fef ("ALSA: firewire: Remove some left-over license text in sound/firewire"), this patch removes it added carelessly.
Fixes: 2133dc91d665 ("ALSA: dice: add support for Focusrite Saffire Pro 40 with TCD3070 ASIC") Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20221201030100.31495-1-o-takashi@sakamocchi.jp Signed-off-by: Takashi Iwai <tiwai@suse.de>
show more ...
|
| 4121f626 | 01-Jun-2021 |
Takashi Sakamoto <o-takashi@sakamocchi.jp> |
ALSA: dice: perform sequence replay for media clock recovery
This commit takes ALSA dice driver to perform sequence replay for media clock recovery.
Unlike the other types of device, DICE-based dev
ALSA: dice: perform sequence replay for media clock recovery
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>
show more ...
|
| 41319eb5 | 01-Jun-2021 |
Takashi Sakamoto <o-takashi@sakamocchi.jp> |
ALSA: dice: wait just for NOTIFY_CLOCK_ACCEPTED after GLOBAL_CLOCK_SELECT operation
NOTIFY_CLOCK_ACCEPTED notification is always generated as a result of GLOBAL_CLOCK_SELECT operation, however NOTIF
ALSA: dice: wait just for NOTIFY_CLOCK_ACCEPTED after GLOBAL_CLOCK_SELECT operation
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 <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>
show more ...
|
| f9e5ecdf | 27-May-2021 |
Takashi Sakamoto <o-takashi@sakamocchi.jp> |
ALSA: firewire-lib: add replay target to cache sequence of packet
In design of audio and music unit in IEEE 1394 bus, feedback of effective sampling transfer frequency (STF) is delivered by packets
ALSA: firewire-lib: add replay target to cache sequence of packet
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>
show more ...
|
| 4c6fe8c5 | 18-May-2021 |
Takashi Sakamoto <o-takashi@sakamocchi.jp> |
ALSA: dice: fix stream format for TC Electronic Konnekt Live at high sampling transfer frequency
At high sampling transfer frequency, TC Electronic Konnekt Live transfers/receives 6 audio data frame
ALSA: dice: fix stream format for TC Electronic Konnekt Live at high sampling transfer frequency
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: <stable@vger.kernel.org> Fixes: f1f0f330b1d0 ("ALSA: dice: add parameters of stream formats for models produced by TC Electronic") Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20210518012612.37268-1-o-takashi@sakamocchi.jp Signed-off-by: Takashi Iwai <tiwai@suse.de>
show more ...
|
| 9f079c1b | 18-May-2021 |
Takashi Sakamoto <o-takashi@sakamocchi.jp> |
ALSA: dice: disable double_pcm_frames mode for M-Audio Profire 610, 2626 and Avid M-Box 3 Pro
ALSA dice driver detects jumbo payload at high sampling transfer frequency for below models:
* Avid M-
ALSA: dice: disable double_pcm_frames mode for M-Audio Profire 610, 2626 and Avid M-Box 3 Pro
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>
show more ...
|