Skip to content

L
linux
Switch branch/tag
  1. 06 Jun, 2021 2 commits
  3. 05 Jun, 2021 1 commit
  5. 04 Jun, 2021 1 commit
  7. 02 Jun, 2021 8 commits
  9. 01 Jun, 2021 9 commits
    • Takashi Sakamoto's avatar
      ALSA: bebob: perform sequence replay for media clock recovery · 1bd1b3be
      Takashi Sakamoto authored 
      This commit takes ALSA bebob driver to perform sequence replay for media
clock recovery.

Many users have reported discontinuity of data block counter field of CIP
header in tx packet from the devices based on BeBoB ASICs. In the worst
case, the device corrupts not to respond to any transaction, then generate
bus-reset voluntarily for recovery. The sequence replay for media clock
recovery is expected to suppress most of the problems.

In the beginning of packet streaming, the device transfers NODATA packets
for a while, then multiplexes any event and syt information. ALSA
IEC 61883-1/6 packet streaming engine has implementation for it to drop
the initial NODATA packets. It starts sequence replay when detecting any
event multiplexed to tx packets.

The sequence replay is tested with below models:

 * Focusrite Saffire
 * Focusrite Saffire LE
 * Focusrite Saffire Pro 10 I/O
 * Focusrite Saffire Pro 26 I/O
 * M-Audio FireWire Solo
 * M-Audio FireWire Audiophile
 * M-Audio Ozonic
 * M-Audio FireWire 410
 * M-Audio FireWire 1814
 * Edirol FA-66
 * ESI Quatafire 610
 * Apogee Ensemble
 * Phonic Firefly 202
 * Behringer F-Control Audio 610

Unfortunately, below models doesn't generate sound. This seems regression
introduced recent few years:

 * Stanton Final Scratch ScratchAmp at middle sampling transfer frequency
 * Yamaha GO44
 * Yamaha GO46
 * Terratec Phase x24

As I reported, below model has quirk of discontinuity:

 * M-Audio ProFire Lightbridge

DM1000/DM1100 ASICs in BeBoB solution are known to have bugs at switch of
sampling transfer frequency between low/middle/high rates. The switch
generates the similar problems about which I mention in the above. Some
vendors customizes firmware so that the switch of frequency is done in
vendor-specific registers, then restrict users to switch the frequency.

For example of Focusrite Saffire Pro 10 i/o and 26 i/o, users allows to
switch the frequency within the three steps; e.g. 44.1/48.0 kHz are
available at low step. Between the steps, extra operation is required and
it always generates bus-reset.

Another example of Edirol FA-66, users are prohibited to switch the
frequency by software. It's done by hardware switch and power-off.

I note that the sequence replay is not a solution for the ASIC bugs. Users
need to disconnect the device corrupted by the bug, then reconnect it to
refresh state machine inner the ASIC.
Signed-off-by: default avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20210601081753.9191-4-o-takashi@sakamocchi.jpSigned-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      1bd1b3be
    • Takashi Sakamoto's avatar
      ALSA: dice: perform sequence replay for media clock recovery · 4121f626
      Takashi Sakamoto authored 
      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: default avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20210601081753.9191-3-o-takashi@sakamocchi.jpSigned-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      4121f626
    • Takashi Sakamoto's avatar
      ALSA: dice: wait just for NOTIFY_CLOCK_ACCEPTED after GLOBAL_CLOCK_SELECT operation · 41319eb5
      Takashi Sakamoto authored 
      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 fbeac84d ("ALSA: dice: old firmware optimization for Dice notification")
 * commit aec045b8 ("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: default avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20210601081753.9191-2-o-takashi@sakamocchi.jpSigned-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      41319eb5
    • Takashi Sakamoto's avatar
      ALSA: fireface: perform sequence replay for media clock recovery · dfacca39
      Takashi Sakamoto authored 
      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: default avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20210531025103.17880-7-o-takashi@sakamocchi.jpSigned-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      dfacca39
    • Takashi Sakamoto's avatar
      ALSA: firewire-tascam: perform sequence replay for media clock recovery · a9dd8a61
      Takashi Sakamoto authored 
      This commit takes ALSA firewire-tascam driver to perform sequence replay
for media clock recovery.

The protocol specific to Tascam FireWire series is not compliant to
IEC 61883-1/6 in terms of syt field of CIP. The protocol doesn't use
presentation time in received CIP for playback timing. The sequence of
the number of data blocks per packet is important for media clock
recovery.

Although the devices in Tascam FireWire series transfer packets
regardless of receiving packets, the tx packets includes no events
in the beginning of streaming. It takes so long to multiplex any event
into the packet after receiving the sequence of packets. As long as I
experienced, it takes several thousands of isochronous cycle. Furthermore,
just after changing sampling transmission frequency, it stops multiplexing
event at once, then starts multiplexing again.

The sequence replay is tested with below models:
 * FW-1884
 * FW-1804
 * FW-1082
Signed-off-by: default avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20210531025103.17880-6-o-takashi@sakamocchi.jpSigned-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      a9dd8a61
    • Takashi Sakamoto's avatar
      ALSA: firewire-digi00x: perform sequence replay for media clock recovery · 019af592
      Takashi Sakamoto authored 
      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: default avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20210531025103.17880-5-o-takashi@sakamocchi.jpSigned-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      019af592
    • Takashi Sakamoto's avatar
      ALSA: oxfw: perform sequence replay for media clock recovery · 029ffc42
      Takashi Sakamoto authored 
      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: default avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20210531025103.17880-4-o-takashi@sakamocchi.jpSigned-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      029ffc42
    • Takashi Sakamoto's avatar
      ALSA: fireworks: perform sequence replay for media clock recovery · a105f642
      Takashi Sakamoto authored 
      Echo Digital Audio Corporation had US patent US7599388B2 titled as
'System and method for high-bandwidth serial bus data transfer'. In the
patent, dual-banked shared memory is used to deliver data between
serial bus transmission and processor in FIFO way. The patent seems to be
used for Fireworks board module. The mechanism is not compliant to
synchronization based on presentation time expressed in syt field
of CIP header. Fireworks board module takes care of the sequence of
the number of data blocks per packet and just ignores the value of syt
field.

This commit takes fireworks driver to performs sequence replay for media
clock recovery. As long as I tested, Audiofire 2 and 4 have a quirk to
skip an isochronous cycle several thousands after starting packet
transmission.

The sequence replay is tested with below models:
 * Loud Technology Mackie 400f
 * Echo Audio Audiofire 12 (DSP model)
 * Echo Audio Audiofire 12 (FPGA model)
 * Echo Audio Audiofire 8 (DSP model)
 * Echo Audio Audiofire 8 (FPGA model)
 * Echo Audio Audiofire Pre8
 * Echo Audio Audiofire 4
 * Echo Audio Audiofire 2
Signed-off-by: default avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20210531025103.17880-3-o-takashi@sakamocchi.jpSigned-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      a105f642
    • Takashi Sakamoto's avatar
      ALSA: fireworks: delete SYTMATCH clock source · 77f1fd6d
      Takashi Sakamoto authored 
      In the design of Fireworks board module, the device does't adjust its
media clock voluntarily by the sequence of presentation time expressed in
syt field of CIP header of received packet.
Signed-off-by: default avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20210531025103.17880-2-o-takashi@sakamocchi.jpSigned-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      77f1fd6d
  11. 30 May, 2021 1 commit
  13. 28 May, 2021 5 commits
    • YueHaibing's avatar
      ALSA: core: use DEVICE_ATTR_*() macro · 873fd813
      YueHaibing authored 
      Use DEVICE_ATTR_*() helper instead of plain DEVICE_ATTR,
which makes the code a bit shorter and easier to read.
Signed-off-by: default avatarYueHaibing <yuehaibing@huawei.com>
Link: https://lore.kernel.org/r/20210526121828.8460-1-yuehaibing@huawei.comSigned-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      873fd813
    • Takashi Sakamoto's avatar
      ALSA: firewire-lib: support NO_PERIOD_WAKEUP in ALSA PCM runtime · d360870a
      Takashi Sakamoto authored 
      Drivers of ALSA firewire stack can process packets for IT/IR context in
process context when the process operates ALSA PCM character device by
calling ioctl(2) with some requests. The ioctl requests are:

 * SNDRV_PCM_IOCTL_HWSYNC
 * SNDRV_PCM_IOCTL_SYNC_PTR
 * SNDRV_PCM_IOCTL_REWIND
 * SNDRV_PCM_IOCTL_FORWARD
 * SNDRV_PCM_IOCTL_WRITEI_FRAMES
 * SNDRV_PCM_IOCTL_READI_FRAMES
 * SNDRV_PCM_IOCTL_WRITEN_FRAMES
 * SNDRV_PCM_IOCTL_READN_FRAMES

This means that general application can process PCM frames apart from
hardware IRQ invocation, even if they are programmed by either IRQ-based
scheduling model or Timer-based scheduling model.

This commit add support for Timer-based scheduling model by allowing
PCM runtime to suppress both process wakeup per period and scheduling
hardware IRQ.

SNDRV_PCM_INFO_BATCH is obsoleted since ALSA IEC 61883-1/6 packet streaming
engine can report the number of transferred PCM frames within PCM period
boundary. The granularity equals to SYT_INTERVAL in blocking transmission.
In non-blocking transmission, it doesn't equal to SYT_INTERVAL but doesn't
exceed.

This patch is tested with PulseAudio, and --sched-model option of axfer
with fix against the issue reported at:

 * https://lore.kernel.org/alsa-devel/687f9871-7484-1370-04d1-9c968e86f72b@linux.intel.com/#rSigned-off-by: default avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20210527123253.174315-1-o-takashi@sakamocchi.jpSigned-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      d360870a
    • Takashi Sakamoto's avatar
      ALSA: firewire-lib: transfer rx packets on-the-fly when replaying · 2f21a177
      Takashi Sakamoto authored 
      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: default avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20210527122611.173711-4-o-takashi@sakamocchi.jpSigned-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      2f21a177
    • Takashi Sakamoto's avatar
      ALSA: firewire-lib: replay sequence of incoming packets for outgoing packets · 39c2649c
      Takashi Sakamoto authored 
      ALSA IEC 61883-1/6 packet streaming engine uses pre-computed parameters
ideal for nominal sampling transfer frequency (STF) to transfer packets
to device since it was added 2011. As a result of user experience for a
decade, it is clear that the sequence is not suitable to some actual
devices. It takes the devices to generate noise, and causes any type of
discontinuity in the series of packet transferred from the device. It's
required for the engine to transfer packets according to effective STF.

The effective STF is given by media clock recovered by the sequence of
packet transferred from the target device. In the previous commit, the
sequence is already cached. The media clock recovery can be achieved by
analyzing the sequence.

In technological world, many ideas are proposed for media clock recovery.
However, the small part of them could be actually adopted in our case
since floating point arithmetic is not mostly available in Linux kernel
land.

This commit adopts the simple way from them; sequence replay, which means
that the sequence of parameters from incoming packet is used as is to
transfer outgoing packets. The media clock is not computed internally,
but the sequence of outgoing packet superficially looks to be generated by
the media clock.

The association between source and destination is decided when starting
AMDTP domain. When the target device supports a pair of isochronous packet
streams, the tx stream is source and the rx stream is destination. When it
supports two pair of streams, each of tx stream is associated to
corresponding rx stream in its order. When it supports less number of tx
streams than rx streams, the fist tx stream is selected for all of rx
streams. When it supports more tx streams than rx streams, the first tx
packet is associated to the rx stream.

As I noted in previous commit, the sequence of parameters from incoming
packet is different between devices, time to time. It is worse idea to
replay the sequence of parameters from a device for the sequence of
packet to the other devices even if they are in the same category of
device.
Signed-off-by: default avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20210527122611.173711-3-o-takashi@sakamocchi.jpSigned-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      39c2649c
    • Takashi Sakamoto's avatar
      ALSA: firewire-lib: add replay target to cache sequence of packet · f9e5ecdf
      Takashi Sakamoto authored 
      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: default avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20210527122611.173711-2-o-takashi@sakamocchi.jpSigned-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      f9e5ecdf
  15. 27 May, 2021 4 commits
  17. 25 May, 2021 9 commits
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7