IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Below devices reports zero as the number of channels for external output
plug with MIDI type:
* Yamaha GO44/GO46
* Terratec Phase 24/X24
As a result, rx packet format is invalid and they generate silent sound.
This is a regression added in v5.13.
This commit fixes the bug, addressed at a commit 1bd1b3be8655 ("ALSA:
bebob: perform sequence replay for media clock recovery").
Cc: <stable@vger.kernel.org>
Fixes: 5c6ea94f2b7c ("ALSA: bebob: detect the number of available MIDI ports")
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20210618040447.113306-1-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
In a commit c4d860a0d256 ("ALSA: bebob: loosen up severity of checking
continuity for BeBoB v3 quirk"), a workaround was added for the quirk in
BeBoB protocol version 3 against the discontinuity of data block counter.
As long as seeing with sequence replay for media clock recovery, such
quirk disappears.
This commit deletes the workaround.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20210611035003.26852-3-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
In a commit d3eabe939aee ("ALSA: bebob: expand sleep just after breaking
connections for protocol version 1"), a workaround was added for a quirk
of freeze in BeBoB protocol version 1. As long as seeing with sequence
replay for media clock recovery, the quirk disappears.
This commit removes the workaround.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20210611035003.26852-2-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
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: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20210601081753.9191-4-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>
In former commit, ALSA IEC 61883-1/6 packet streaming engine drops
initial tx packets till the packet includes any event. This allows ALSA
bebob driver not to give option to skip initial packet since the engine
does drop the initial packet.
However, M-Audio ProFire Lightbridge has a quirk to stop packet
transmission after start multiplexing event to the packet. After several
thousands cycles, it restart packet transmission again.
This commit specializes the usage of initial skip option for the model.
Additionally, this commit expands timeout enough to wait processing
content of tx packet.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20210524031346.50539-5-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
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 <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20210520040154.80450-9-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Current implementation of ALSA IEC 61883-1/6 packet streaming engine
allows drivers to decide isochronous cycle to start IR context. This
option is mainly used to avoid processing the sequence of packet with
some quirks; e.g. discontinuity of counter. However, it's inconvenient
to fail to continue packet processing when the target device doesn't
start transmission of packet till the decided cycle.
This commit changes the behaviour. As an alternative to the start cycle
for IR context, the cycle count to drop content of packet in the beginning
of IR context.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20210520040154.80450-6-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Current implementation of bebob driver doesn't correctly handle the case
that the device has multiple MIDI ports. The cause is the number of MIDI
conformant data channels is passed to AM824 data block processing layer.
This commit fixes the bug.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20210321032831.340278-4-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Current implementation counts the number of input/output plugs for MIDI
type and uses the count as the number of physical MIDI ports. However,
the number of channels of the port represents the count.
This commit fixes the bug by additional vendor-specific AVC command
extension.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20210321032831.340278-3-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
ALSA bebob driver scans supported formats of packet for each direction
when probing the target device. Some helper functions are used for the
scanning, however its implementation is not necessarily irredundant.
This commit refactors the helper functions to remove redundant codes.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20210321032831.340278-2-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Originally BeBeB ASICs and firmware supports clock mode to synchronizing
to syt field of received isoc packet. This mode is known as 'SYT Match'
slightly described in IEC 61883-6 (but no detail mechanisms). In this
mode, drivers can control sampling clock in device. Driver for Windows
and macOS uses this feature to perform synchronization for devices
on the same bus.
In this mode, a plug of Music subunit for synchronization is connected
to a plug of isoc unit for incoming packet streaming, then the order to
establish connections is INPUT_PLUG first, OUTPUT_PLUG second.
This commit implements the above.
Actually each device works with its own clock for sampling, therefore
the original design is hardly implemented to vendor's products.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20191101131323.17300-4-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
As long as I investigated, there's some cases about the delay for device
between establishing OUTPUT_PLUG and transmitting first isoc packet. For
devices which support BeBoB protocol version 1 can transmit the packet
within several hundred milliseconds, while for devices which support
BeBoB protocol version 3 can transmit the packet within 2 seconds.
Devices with protocol version 1:
* Edirol FA-66
* Yamaha GO46
* Terratec Phase x24 FW
* M-Audio FireWire AudioPhile
* M-Audio FireWire Solo
* M-Audio FireWire 1814
* M-Audio FireWire 410
* Focusrite Saffire Pro 26 I/O
Devices with protocol version 3:
* M-Audio Profire Lightbridge
* Behringer FCA610
* Phonic Firefly 202
At present ALSA bebob driver postpones starting IR context during
1.5 sec for all of supported devices. The delay is too long for
devices with protocol version 1, while it's not enough for devices with
protocol version 3.
This commit improves the delay for these protocols.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20191101131323.17300-3-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
As long as I investigated, some devices with BeBoB protocol version 1
can be freezed during several hundreds milliseconds after breaking
connections. When accessing during the freezed time, any transaction
is corrupted. In the worst case, the device is going to reboot.
I can see this issue in:
* Roland FA-66
* M-Audio FireWire Solo
This commit expands sleep just after breaking connections to avoid
the freezed time as much as possible. I note that the freeze/reboot
behaviour is similar to below models:
* Focusrite Saffire Pro 10 I/O
* Focusrite Saffire Pro 26 I/O
The above models certainly reboot after breaking connections.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20191101131323.17300-2-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
A helper function of ALSA bebob driver returns negative value in a
function which has a prototype to return unsigned value.
This commit fixes it by changing the prototype.
Fixes: eb7b3a056cd8 ("ALSA: bebob: Add commands and connections/streams management")
Cc: <stable@vger.kernel.org> # v3.16+
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20191026030620.12077-1-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
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>
This commit allows ALSA bebob driver to share PCM buffer size for both
capture and playback PCM substream. When AMDTP domain starts for one
of the PCM substream, buffer size of the PCM substream is stores to
AMDTP domain structure. Some AMDTP streams have already run with the
buffer size when another PCM substream starts, therefore the PCM
substream has a constraint to its buffer size.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20191017155424.885-3-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The number of packets in packet buffer has been fixed number (=48) since
first commit of ALSA IEC 61883-1/6 packet streaming engine.
This commit allows the engine to use variable number of packets in the
buffer. The size is calculated by a parameter in AMDTP domain structure
surely to store the number of events in the packets of buffer. Although
the value of parameter is expected to come from 'period size' parameter
of PCM substream, at present 48 is still used.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20191017155424.885-2-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This commit is a preparation to share the size of PCM period between
PCM substreams on AMDTP streams in the same domain. At this time,
the size of PCM period in PCM substream which starts AMDTP streams in the
same domain is recorded.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20191007110532.30270-3-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This is a very big update, mainly thanks to Morimoto-san's refactoring
work and some fairly large new drivers.
- Lots more work on moving towards a component based framework from
Morimoto-san.
- Support for force disconnecting muxes from Jerome Brunet.
- New drivers for Cirrus Logic CS47L35, CS47L85 and CS47L90, Conexant
CX2072X, Realtek RT1011 and RT1308.
-----BEGIN PGP SIGNATURE-----
iQFHBAABCgAxFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAl0jGwUTHGJyb29uaWVA
a2VybmVsLm9yZwAKCRAk1otyXVSH0LD4B/9AkutfS+vznOrk0V0wFb2SUfjwE4Pr
+z/kAehohAOl/7pg9Dun/lmZYBWMyOM2aYmK81ahEo2DfO+uzwkwjCaXFjGVGwEK
j7XpWkrIjKnou/z1FeALgVvt+crzdy5iNWC04AbKaP2WHCcI7zvPQIsBta/V0OJt
lg+j0J7pagnTMcgV1+qJdaASmofy/hpoZ79Gv0PIfGC8hpJ/3mBgcNPCLQrJtD4R
v+tzvCZNrZVqCanwLf3vouEm1bpWYOpI+Wdmu4u6rY7MhmCj72EJ2zyfdm/qtaxF
e7whgCyOQFkWe7NgDn0G08aAT6LsaxOtPNr7H8tL8S8sw8425fqeOouV
=n/HQ
-----END PGP SIGNATURE-----
Merge tag 'asoc-v5.3' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus
ASoC: Updates for v5.3
This is a very big update, mainly thanks to Morimoto-san's refactoring
work and some fairly large new drivers.
- Lots more work on moving towards a component based framework from
Morimoto-san.
- Support for force disconnecting muxes from Jerome Brunet.
- New drivers for Cirrus Logic CS47L35, CS47L85 and CS47L90, Conexant
CX2072X, Realtek RT1011 and RT1308.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
When stopping packet streaming in reserve function for duplex streams,
isochronous resources should be released.
Fixes: 7bc93821a70a ("ALSA: firewire-lib: split allocation of isochronous resources from establishment of connection")
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
In current implementation, establishment connection corresponds to
allocation of isochronous resources. Although this is an ideal
implementation of CMP described in IEC 61883-1, it's not enough
efficient to recover PCM substream multiplexed in packet streaming.
The packet streaming can always restart on the same allocated
isochronous resources even if the previous packet streaming
corrupted.
This commit splits allocation of isochronous resources from
establishment of connection so that CMP runs with allocated
isochronous resources.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This commit changes helper functions to initialize/destroy stream
data so that it has an argument for direction.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The private structure of this driver has 'connected' member but nowadays
it's useless. This commit removes it.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
When stopping packet streaming, no need to stop PCM substream with XRUN
state. This commit suppresses it.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This commit is a part of preparation to perform allocation/release
of isochronous resources in pcm.hw_params/hw_free callbacks.
At present, several operations are done in pcm.prepare callback. To
reduce load of the callback, This commit splits out an operation to
set sampling transfer frequency in pcm.hw_params callback.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Based on 1 normalized pattern(s):
licensed under the terms of the gnu general public license version 2
extracted by the scancode license scanner the SPDX license identifier
GPL-2.0-only
has been chosen to replace the boilerplate/reference in 88 file(s).
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Alexios Zavras <alexios.zavras@intel.com>
Reviewed-by: Allison Randal <allison@lohutok.net>
Cc: linux-spdx@vger.kernel.org
Link: https://lkml.kernel.org/r/20190530000437.521539229@linutronix.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
In former commit, drivers in ALSA firewire stack always starts IT context
before IR context. If IR context starts after packets are transmitted by
peer unit, packet discontinuity may be detected because the context starts
in the middle of packet streaming. This situation is rare because IT
context usually starts immediately. However, it's better to solve this
issue. This is suppressed with CIP_SKIP_INIT_DBC_CHECK flag.
This commit enables the same feature as CIP_SKIP_INIT_DBC_CHECK.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Windows driver for BeBoB-based models mostly wait for transmitted packets,
then transfer packets to the models. This looks for the relationship
between incoming packets and outgoing packets to synchronize the sequence
of presentation timestamp.
However, the sequence between packets of both direction has no
relationship. Even if receiving NO-DATA packets, the drivers transfer
packets with meaningful value in SYT field. Additionally, the order of
starting packets is always the same, independently of the source of clock.
The corresponding driver is expected as a generator of presentation
timestamp and these models can select it as a source of sampling clock.
This commit drops reusing SYT sequence from ALSA bebob driver. The driver
always transfer packets with presentation timestamp generated by ALSA
firewire stack, without re-using the sequence of value in SYT field in
incoming packets to outgoing packets.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
DM1000/DM1100/DM1500 chipsets transfer packets with discontinue value in
'dbc' field of CIP header. For ALSA bebob driver, this makes its bus-reset
handler meaningless, because the discontinuity is detected quite earlier
than executing the handler.
This commit gives up updating streams at the bus reset handler.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The counter is incremented/decremented in critical section protected with
mutex. Therefore, no need to use atomic_t.
This commit changes the type to unsigned int.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Currently, critical section is protected by mutex in functions of
fireworks_stream.c. Callers increments/decrements substreams counter
before calling the functions. Moving mutex to the callers code allows
to change type of the substream counter from atomic_t to unsigned int.
This commit is a preparation for obsoleting usage of atomic_t for
substream counter.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
At bus-reset, DM1000/DM1100/DM1500 chipsets transfer packets with
discontinuous value in 'dbc' field of CIP header. In this case, packet
streaming layer in firewire-lib module stops streaming and set XRUN to PCM
substream.
In ALSA, PCM applications are notified the XRUN status by the return value
of ALSA PCM interface. They can recover this state by executing
snd_pcm_prepare(), then PCM drivers' prepare handler is called, and start
new PCM substream. For ALSA BeBoB driver, the handler establishes new
connections and start new AMDTP streaming.
Unfortunately, neither the PCM applications nor the driver know the reason
of XRUN. The driver gets to know the reason when update handler is called
by IEEE 1394 bus driver. As long as I tested, the order of below events are
not fixed:
* Detecting packet discontinuity in tasklet context of OHCI 1394 driver
* Calling prepare handler in process context of ALSA PCM application
* Calling update handler in kthread context of IEEE 1394 bus driver
The unpredictable order is disadvantage for the driver to be compliant to
CMP. In IEC 61883-1, new CMP establish operations should be done 1 sec
(isoc_resource_delay) after bus-reset. Within 1 sec, CMP restore
operations are allowed. For this reason, in former commit ('b6bc812327aa:
ALSA: bebob/firewire-lib: Add a quirk for discontinuity at bus reset'),
the process context is forced to wait for executing update handler. The
process context wait for bus-reset up to 1 sec. This commit solves the
issue, while causes more disadvantages. For PCM applications, calling
snd_pcm_prepare() for recovering XRUN state takes more time and the driver
got a bit complicated code, while the recovery is not always successful.
As long as I tested, DM1000/DM1100/DM1500 and BeBoB firmware can allow
drivers to establish new connections just after bus reset. Furthermore,
any FCP transactions are handled correctly. Therefore, the driver don't
need to wait for bus reset handler for starting new streaming.
This commit removes the codes to reduce maintenance cost.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The return type "unsigned int" was used by the get_formation_index function
despite of the aspect that it will eventually return a negative error code.
So, change to signed int and get index by reference in the parameters.
Done with the help of Coccinelle.
[Fix the missing braces suggested by Julia Lawall -- tiwai]
Signed-off-by: Lucas Tanure <tanure@linux.com>
Reviewed-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Tested-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The structures of type snd_bebob_clock_spec, snd_bebob_rate_spec,
snd_bebob_meter_spec, and snd_bebob_spec are never modified after they are
initialized. Make them all const.
Done with the help of Coccinelle.
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Tested-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Reviewed-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This commit renames some macros just related to AM824 format. In later
commit, they're moved to AM824 layer.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
In IEC 61883-6, several types of data are available in AM824 format. The
data is transferred in each data channel. The position of data channel in
data block differs depending on model.
Current implementation has an array to map the index of data channel in an
data block to the position of actual data channel. The implementation
allows each driver to access the mapping directly.
In later commit, the mapping is in specific structure pushed into an
opaque pointer. Helper functions are required.
This commit adds the helper functions for this purpose. In IEC 61883-6,
AM824 format supports many data types, while this specification easily
causes over-engineering. Current AM824 implementation is allowed to handle
two types of data, Multi Bit Linear Audio data (=PCM samples) and MIDI
conformant data (=MIDI messages).
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The value of FDF field in CIP header is protocol-dependent. Thus, it's
better to allow data block processing layer to decide the value in any
timing.
In AM824 data format, the value of FDF field in CIP header indicates
N-flag and Nominal Sampling Frequency Code (sfc). The N-flag is for
switching 'Clock-based rate control mode' and 'Command-based rate control
mode'. In our implementation, 'Clock-based rate control mode' is just
supported. Therefore, When sampling transfer frequency is decided, then
the FDF can be set.
This commit replaces 'amdtp_stream_set_parameters' with
'amdtp_am824_set_parameters' to set the FDF. This is the same timing
to decide the ration between the number of data blocks and the number of
PCM frames.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This commit adds data block processing layer for AM824 format. The new
layer initializes streaming layer with its value for fmt field.
Currently, most implementation of data block processing still remains
streaming layer. In later commits, these codes will be moved to the layer.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
In IEC 61883-6, one data block represents one event. In ALSA, the event is
one PCM frame. Therefore, when processing one data block, current
implementation counts one PCM frame.
On the other hand, Dice platform has a quirk called as 'dual wire' at
higher sampling rate. In detail, see comment of commit 6eb6c81eee2a
("ALSA: dice: Split stream functionality into a file").
Currently, to handle this quirk, AMDTP stream structure has a
'double_pcm_frames' member. When this is enabled, two PCM frames are
counted. Each driver set this flag by accessing the structure member
directly.
In future commit, some members related to AM824 data block will be moved
to specific structure, to separate packet streaming layer and data block
processing layer. The access will be limited by opaque pointer.
For this reason, this commit adds an argument into
amdtp_stream_set_parameter() to set the flag.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Currently, amdtp_stream_set_parameters() returns no error even if wrong
arguments are given. This is not good for streaming layer because drivers
can continue processing ignoring capability of streaming layer.
This commit changes this function to return error code.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Behringer FCA610 transmits packets with periodic noisy PCM samples
when receiving no streams, and generates a bit noisy sound.
ALSA BeBoB driver is programmed to establish both in/out connections
when starting streaming, then transfers packets as userspace applications
requested. This means that there's a case that one of incoming/outgoing
streams is running, to save CPU and bandwidth usage. Although, it's natural
to start transferring packets in both direction.
This commit makes this driver to keeps duplex streams always.
Tested-by: Kim Tore Jensen <kim@incendio.no>
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Behringer FCA610 and UFX1604 is confirmed to require more time till
transmitting packets after establishing connections. This seems to
be a quirk of DM1500 ASIC which ArchWave produced.
For this quirk, this commit extends the time to wait up to 2 seconds.
As a result, in worst cases, below userspace functions require 2 seconds
to return.
- snd_pcm_prepare()
- snd_pcm_hw_params()
- snd_pcm_recover()
Tested-by: Kim Tore Jensen <kim@incendio.no>
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
