a36183f6 | 10-Jan-2023 |
Takashi Sakamoto <o-takashi@sakamocchi.jp> |
ALSA: firewire-lib: move parameter for pcm frame multiplier from context payload processing layer
The current implementation delegates the task to calculate the number of processed PCM frames into t
ALSA: firewire-lib: move parameter for pcm frame multiplier from context payload processing layer
The current implementation delegates the task to calculate the number of processed PCM frames into the context payload processing layer. It looks good as long as frame calculation is done for a single purpose. Nevertheless, another purpose, the computation of extra delay for the runtime of PCM substream, requires frame calculation, too.
This commit refactors the current implementation so that the packet stream processing layer is responsible for the calculation of PCM frame, too. The member is moved to stream structure for multiplier between data block count and PCM frame count.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20230110134933.322794-2-o-takashi@sakamocchi.jp Signed-off-by: Takashi Iwai <tiwai@suse.de>
show more ...
|
019af592 | 30-May-2021 |
Takashi Sakamoto <o-takashi@sakamocchi.jp> |
ALSA: firewire-digi00x: perform sequence replay for media clock recovery
This commit takes ALSA firewire-digi00x driver to perform sequence replay for media clock recovery.
All of models in Digides
ALSA: firewire-digi00x: perform sequence replay for media clock recovery
This commit takes ALSA firewire-digi00x driver to perform sequence replay for media clock recovery.
All of models in Digidesign digi00x family don't transfer isochronous packets till receiving isochronous packets. The on-the-fly mode is used for the purpose. They don't interpret presentation time expressed in syt field of received CIP, therefore the sequence of the number of data blocks per packet is important for media clock recovery.
The sequence replay is tested with below models:
* Digidesign Digi 002 * Digidesign Digi 002 Rack * Digidesign Digi 003 * Digidesign Digi 003 Rack
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20210531025103.17880-5-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 ...
|
acfedcbe | 18-Oct-2019 |
Takashi Sakamoto <o-takashi@sakamocchi.jp> |
ALSA: firewire-lib: postpone to start IR context
Some devices have a quirk to postpone transmission of isoc packet for several dozen or hundred isoc cycles since configured to transmit. Furthermore,
ALSA: firewire-lib: postpone to start IR context
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>
show more ...
|
c36f8fcc | 07-Oct-2019 |
Takashi Sakamoto <o-takashi@sakamocchi.jp> |
ALSA: firewire-digi00x: use the same size of period for PCM substream in AMDTP streams
In current implementation, when opening a PCM substream, it's needed to check whether the opposite PCM substrea
ALSA: firewire-digi00x: use the same size of period for PCM substream in AMDTP streams
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>
show more ...
|