linux-dev/sound/firewire/oxfw, 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: oxfw: fix functional regression for Mackie Onyx 1640i in v5.14 or later

2021-10-28T15:33:11Z

A user reports functional regression for Mackie Onyx 1640i that the device generates slow sound with ALSA oxfw driver which supports media clock recovery. Although the device is based on OXFW971 ASIC, it does not transfer isochronous packet with own event frequency as expected. The device seems to adjust event frequency according to events in received isochronous packets in the beginning of packet streaming. This is unknown quirk. This commit fixes the regression to turn the recovery off in driver side. As a result, nominal frequency is used in duplex packet streaming between device and driver. For stability of sampling rate in events of transferred isochronous packet, 4,000 isochronous packets are skipped in the beginning of packet streaming. Reference: https://github.com/takaswie/snd-firewire-improve/issues/38 Fixes: 029ffc429440 ("ALSA: oxfw: perform sequence replay for media clock recovery") Signed-off-by: Takashi Sakamoto Link: https://lore.kernel.org/r/20211028130325.45772-1-o-takashi@sakamocchi.jp Signed-off-by: Takashi Iwai

ALSA: oxfw: fix transmission method for Loud models based on OXFW971

2021-09-13T05:31:58Z

Loud Technologies Mackie Onyx 1640i (former model) is identified as the model which uses OXFW971. The analysis of packet dump shows that it transfers events in blocking method of IEC 61883-6, however the default behaviour of ALSA oxfw driver is for non-blocking method. This commit adds code to detect it assuming that all of loud models based on OXFW971 have such quirk. It brings no functional change except for alignment rule of PCM buffer. Signed-off-by: Takashi Sakamoto Link: https://lore.kernel.org/r/20210913021042.10085-1-o-takashi@sakamocchi.jp Signed-off-by: Takashi Iwai

ALSA: oxfw: fix functioal regression for silence in Apogee Duet FireWire

2021-08-12T11:40:27Z

OXFW 971 has no function to use the value in syt field of received isochronous packet for playback timing generation. In kernel prepatch for v5.14, ALSA OXFW driver got change to send NO_INFO value in the field instead of actual timing value. The change brings Apogee Duet FireWire to generate no playback sound, while output meter moves. As long as I investigate, _any_ value in the syt field takes the device to generate sound. It's reasonable to think that the device just ignores data blocks in packet with NO_INFO value in its syt field for audio data processing. This commit adds a new flag for the quirk to fix regression. Fixes: 029ffc429440 ("ALSA: oxfw: perform sequence replay for media clock recovery") Cc: Signed-off-by: Takashi Sakamoto Link: https://lore.kernel.org/r/20210812022839.42043-1-o-takashi@sakamocchi.jp Signed-off-by: Takashi Iwai

ALSA: oxfw: cease from delayed card registration

2021-06-07T15:14:08Z

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-4-o-takashi@sakamocchi.jp Signed-off-by: Takashi Iwai

ALSA: oxfw: perform sequence replay for media clock recovery

2021-06-01T06:19:12Z

This commit takes ALSA oxfw driver to perform sequence replay for media clock recovery. Unfortunately, OXFW970 ASIC and its firmware has a quirk called jumbo payload which skips several isochronous cycles for packet transmission, thus the sequence replay is just adopted to OXFW971 ASIC. As well as Fireworks, OXFW ASICs also ignores presentation time against the way in IEC 61883-1/6. The sequence replay is tested with below models: * Tascam FireOne * Stanton Magnetics SCS.1m * Apogee Duet FireWire For below models, the sequence replay is tested to be disabled: * Griffin FireWave * Behringer F-Control Audio 202 * Loud Technology Tapco Link.FireWire 4x6 * Loud Technology Mackie Onyx Satellite Signed-off-by: Takashi Sakamoto Link: https://lore.kernel.org/r/20210531025103.17880-4-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: oxfw: add quirk flag for blocking transmission method

2021-05-18T10:24:24Z

Stanton SCS.1m and Apogee Duet FireWire use blocking transmission method unlike the other models. Signed-off-by: Takashi Sakamoto Link: https://lore.kernel.org/r/20210518084557.102681-12-o-takashi@sakamocchi.jp Signed-off-by: Takashi Iwai