In the former commits, the callback of isochronous context runs on usual
work process. In the case, ALSA PCM device has a flag, nonatomic, to
acquire mutex lock instead of spin lock for PCM substream group.
This commit uses the flag. It has an advantage in the case that ALSA PCM
application uses the large size of intermediate buffer, since it takes
too long time even in tasklet softIRQ to process many of isochronous
packets, then result in the delay of system event due to disabled IRQ so
long. It is avertible to switch to nonatomic operation.
Reviewed-by: Takashi Iwai <tiwai@suse.de>
Tested-by: Edmund Raile <edmund.raile@protonmail.com>
Link: https://lore.kernel.org/r/20240904125155.461886-6-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Current structure includes no field to express the number of messages
copied to user space, thus user space application needs to information
out of the structure to parse the content of structure.
This commit adds a field to express the number of messages copied to user
space since It is more preferable to use self-contained structure.
Kees Cook proposed an idea of annotation for bound of flexible arrays
in his future improvement for flexible-length array in kernel. The
additional field for message count is suitable to the idea as well.
Reference: https://people.kernel.org/kees/bounded-flexible-arrays-in-c
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20230202133708.163936-1-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The ff400_copy_msg_to_user() function drops the spin lock to call
copy_to_user(). However, if the copy_to_user() fails, then it must
take the lock again before returning. Failure to take the lock leads
to a double unlock in the caller, hwdep_read().
Fixes: acdebd8b4c ("ALSA: fireface: implement message parser for Fireface 400")
Signed-off-by: Dan Carpenter <error27@gmail.com>
Acked-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/Y8at+W/7OGvEBY8O@kili
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The time stamp of isochronous cycle at which asynchronous transaction is
sent is perhaps useful somehow. A commit b2405aa948 ("firewire: add
kernel API to access packet structure in request structure for AR context")
adds kernel API to retrieve the time stamp in inner structure of request
subaction.
This commit changes local framework to handle message delivered by the
asynchronous transaction so that time stamp is picked up by the kernel API.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20230112120954.500692-3-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
It's cleared that Fireface 400 transmits quadlet message for two purposes
at least; received MIDI messages and notification of knob control
operation. Nevertheless current implementation uses callback function name
just for MIDI messages.
This commit renames the callback functions.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20230112120954.500692-2-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
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>
The list of packet descriptor is passed to context payload processing
layer so that each driver can copy PCM frames, MIDI messages, and device
specific data between packet payload buffer and intermediate buffer for
user space application.
The list of packet descriptor was replaced by circular linked list in a
previous commit. This commit uses circular linked in context payload
processing layer as well.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20230109021738.75543-3-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This commit takes ALSA fireface driver to perform sequence replay for
media clock recovery.
The protocol specific to RME Fireface series is not compliant to
IEC 61883-1/6 since it has no CIP header, therefore presentation time
is not used for media clock recovery. The sequence of the number of data
blocks per packet is important.
I note that the device skips an isochronous cycle corresponding to an
empty packet or a NODATA packet in blocking transmission method of
IEC 61883-1/6. For sequence replay, the cycle is handled as receiving an
empty packet. Furthermore, it doesn't start packet transmission till
receiving any packet.
The sequence replay is tested with below models:
* Fireface 400
* Fireface 800
* Fireface 802
I note that it is better to initialize Fireface 400 in advance by
initialization transaction implemented in snd-fireface-ctl-service of
snd-firewire-ctl-services project. You can see whether initialized or
not by HOST LED on the device. Unless, the device often stops packet
transmission even if session starts.
I guess the sequence replay also works well with below models:
* Fireface UFX
* Fireface UCX
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20210531025103.17880-7-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>
