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>
BeBoB installed devices have BeBoB register area. This area stores
basic information about its firmware. A register has its protocol
version.
This commit adds 'version' member and store the device's protocol
version to handle v3 quirks in following commits.
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>
In previous commits, this driver can detect the source of clock as mush
as possible. SYT-Match mode is also available.
This commit purge the restriction.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The old string literals were completely replaced by new normalized
representation.
This commit obsoletes it.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This commit changes function prototype and its processing. As a result,
function caller can execute additional processing according to detected
clock source.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Previous commit adds a enumerator as a normalized representation of
clock source, while model-dependent structures still use string literals
for this purpose.
This commit is a preparation for replacement.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Previous commit allows this driver to detect several types of clock
source, while there's no normalized expression for it.
This commit adds a new enumerator for this purpose.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
With BeBoB version 3, current ALSA BeBoB driver detects the type of
current clock signal source wrongly. This is due to a lack of proper
implementation to parse the information.
This commit renews the parser. As a result, this driver detects
SYT-Match clock signal, thus it can start streams with two modes;
SYT-Match mode and the others. SYT-Match mode will be supported in future
commits.
There's a constrain about detected internal/external clock source.
When detecting external clock source, this driver allows userspace
applications to use current sampling rate only. This is due to consider
abour synchronization to external clock sources such as S/PDIF, ADAT or
word-clock.
According to several information from some devices, I guesss that the
internal clock of most devices synchronize to IEEE 1394 cycle start
packet. In this case, by a usual way, it's detect as 'Sync type
of output Music Sub-Unit' connected to 'Sync type of PCR output Unit
(oPCR)', and this driver judges it as internal clock. Therefore,
userspace applications is allowed to request arbitrary supported sampling
rates.
On the other hand, several devices based on BeBoB version 3 have
additional internal clock. In this case, by a usual way, it's detect as
'Sync/Additional type of External input Unit'. Unfortunately, there's no
way to distinguish this sync type from the other external clock sources
such as word-clock. In this case, this driver handles it as external and
userspace applications is forced to use current sampling rate.
I note that when the source of clock is detected as 'Isochronous stream
type of input PCR[0]', it's under 'SYT-Match' mode. In this mode, the
synchronization clock is generated according to SYT-series in received
packets. In this case, this driver generates the series by myself. I
experienced this mode often make the device silent suddenly during
playbacking. This means that the mode is easy to lost synchronization.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
When detecting packet discontinuity, handle_in_packet() returns minus value
and this value is assigned to unsigned int variable, then the variable has
huge value. As a result, the variable causes buffer-over-run in
handle_out_packet(). This brings invalid page request and system hangup.
This commit fixes the bug to add a new argument into handle_in_packet()
and the number of handled data blocks is assignd to it. The function
return value is just used to check error.
I also considered to change the type of local variable to 'int' in
in_stream_callback(). This idea is based on type-conversion in C standard,
while it may cause future problems when adding more works. Thus, I dropped
this idea.
Fixes: 6fc6b9ce41c6('ALSA: firewire-lib: pass the number of data blocks in incoming packets to outgoing packets')
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This device is based on DM1000E, and BeBoB version 1 firmware is
installed.
$ cat /proc/asound/cards
0 [Pro ]: BeBoB - Mbox 2 Pro
DIGIDESIGN Mbox 2 Pro (id:1, rev:1),
GUID 00a07e0100a90000 at fw1.0, S400
$ cat /proc/asound/Pro/firewire/firmware
Manufacturer: bridgeCo
Protocol Ver: 1
Build Ver: 0
GUID: 0x00A07E0100A90000
Model ID: 0x01
Model Rev: 1
Firmware Date: 20071031
Firmware Time: 034402
Firmware ID: 0xA9
Firmware Ver: 16777215
Base Addr: 0x20080000
Max Size: 1572864
Loader Date: 20051207
Loader Time: 205554
With this patch, ALSA BeBoB driver can start packet streaming to/from
this model, while as a default, internal multiplexer of this model is
not initialized and generates no sound even if the driver transfers
any packets with PCM samples. To hear any sounds from this model,
userspace applications should be developed to set parameters to the
internal multiplexer. You can see raw information in FFADO website:
http://subversion.ffado.org/wiki/AvcModels/DigiDesignMboxPro2
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
When detecting zero in 'dbs' field of CIP header, this packet streaming
should be aborted because of avoiding division-by-zero. This is an error
in an aspect of IEC 61883-1, thus protocol error.
This commit use EPROTO instead of EIO. Actually, the returned value is
not used for userspace and this commit has no effect.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Acked-by: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
When detecting invalid value in 'dbs' field of CIP header or packet
discontinuity, current implementation reports the status by err_info().
In most cases this state is caused by model-specific issue due to
vendor's customization and should be reported to developers.
This commit use dev_err() instead of dev_info() for this purpose.
In the cases, packet streaming is aborted, thus no message floading
occurs.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Acked-by: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Some macros include my misunderstanding for IEC 61883-1 or -6.
Additionally, some fixed values appear on codes.
This commit replaces these with macros with proper names.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Acked-by: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The naming rule for local functions was inconsistent. This commit
rename them with a consistent manner.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Acked-by: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Former patches allow non-blocking streams to synchronize with timestamp.
This patch removes the restriction.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
In previous commit, error handling for incoming packet processing is
outside of packetization. This is nice for reading the codes.
This commit applies this idea for outgoing packet processing, too.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Current implementation reuses the value of syt field in incoming packet to
outgoing packet for full duplex timestamp synchronization, while the number
of data blocks in outgoing packets refers to hard-coded table and the
synchronization cannot be applied to non-blocking stream.
This commit passes the number of data blocks from incoming packet
processing to outgoing packet processing for the synchronization. For
normal mode, isochronous callback handler is changed to generate the values
of syt and data blocks.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This function is called according to conditions between the value of
syt and streaming mode(blocking or non-blocking).
To simplify caller's work, this commit push these conditions to the
function.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
In IEC 61883-6, the number of data blocks in a packet is limited up to
the value of SYT_INTERVAL. Current implementation is compliant to the
limitation, while it can cause buffer-over-run when the value of dbs
field in received packet is illegally large.
This commit adds a validator to detect such illegal packets to prevent
the buffer-over-run. Actually, the buffer is aligned to the size of memory
page, thus this issue hardly causes system errors due to the room to page
alignment, as long as a few packets includes such jumbo payload; i.e.
a packet to several received packets.
Here, Behringer F-Control Audio 202 (based on OXFW 960) has a quirk to
postpone transferring isochronous packet till finish handling any
asynchronous packets. In this case, this model is lazy, transfers no
packets according to several cycle-start packets. After finishing, this
model pushes required data in next isochronous packet. As a result, the
packet include more data blocks than IEC 61883-6 defines.
To continue to support this model, this commit adds a new flag to extend
the length of calculated payload. This flag allows the size of payload
5 times as large as IEC 61883-6 defines. As a result, packets from this
model passed the validator successfully.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Some M-Audio devices require to receive bootup command just after
powering on, while codes in BeBoB driver doesn't work properly in
big-endian machine because the command should be aligned by
little-endian.
This commit fixes this bug. This fix should go to stable kernel.
Cc: Takayuki Shiroma <t.shiroma.oki@gmail.com>
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
With previous commit, this module managed to leave the counting to each
drivers, but the isochronous resources functionality still increment/decrement
the count.
This commit purge such codes to leave the responsibility to each drivers.
Fix: c6f224dc20 ('ALSA: firewire-lib: remove reference counting')
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
For received packet stream, the offset of 'RX_SEQ_START' locates after
the offset of 'RX_NUMBER_MIDI', although current macro and proc output
includes wrong offsets.
Fortunately, this bug doesn't affect streaming functionality because
these macro is not used.
This commit fixes these wrong macro and outputs.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The amdtp_stream_wait_callback() doesn't return minus value and
the return code is not for error code.
This commit fixes with a propper condition and an error code.
Fixes: f3699e2c77 ('ALSA: oxfw: Change the way to start stream')
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Cc: <stable@vger.kernel.org> # 3.19+
Signed-off-by: Takashi Iwai <tiwai@suse.de>
A part of these drivers, especially BeBoB driver, are programmed to wait
some events. Thus the drivers should not destroy any data in .remove()
context.
This commit moves some destructors from 'struct fw_driver.remove()' to
'struct snd_card.private_free()' to shutdown safely.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Cc: <stable@vger.kernel.org> # 3.19+
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Currently stream destructor in each driver has a problem to be called in
a context in which sound card object is released, because the destructors
call amdtp_stream_pcm_abort() and touch PCM runtime data.
The PCM runtime data is destroyed in application's context with
snd_pcm_close(), on the other hand PCM substream data is destroyed after
sound card object is released, in most case after all of ALSA character
devices are released. When PCM runtime is destroyed and PCM substream is
remained, amdtp_stream_pcm_abort() touches PCM runtime data and causes
Null-pointer-dereference.
This commit changes stream destructors and allows each driver to call
it after releasing runtime.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Cc: <stable@vger.kernel.org> # 3.19+
Signed-off-by: Takashi Iwai <tiwai@suse.de>
AMDTP helper functions increment/decrement reference counter for an
instance of FireWire unit, while it's complicated for each driver to
process error state.
In previous commit, each driver has the role of reference counting. This
commit removes this role from the helper function.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Cc: <stable@vger.kernel.org> # 3.19+
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Fireworks and Dice drivers try to touch instances of FireWire unit after
sound card object is released, while references to the unit is decremented
in .remove(). When unplugging during streaming, sound card object is
released after .remove(), thus Fireworks and Dice drivers causes GPF or
Null-pointer-dereferencing to application processes because an instance of
FireWire unit was already released.
This commit adds reference-counting for FireWire unit in drivers to allow
them to touch an instance of FireWire unit after .remove(). In most case,
any operations after .remove() may be failed safely.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Cc: <stable@vger.kernel.org> # 3.19+
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The sign for microsecond (U+0085, MICRO SIGN) was encoded to '0x c2 b5'
by UTF-8 character encoding scheme. But the byte sequence was converted
to '0x c3 82 c2 b5' in a previous commit. As a result, the byte
sequence cannot represent microsecond sign in UTF-8 or ASCII. This
may confuse developers.
This commit replaces the sign to string expression with 'microseconds'
to purge superfluous troubles.
Fixes: 5c697e5b46ef("ALSA: firewire-lib: remove rx_blocks_for_midi quirk")
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Do no send MIDI bytes at the full rate at which FireWire packets happen
to be sent, but restrict them to the actual rate of a real MIDI port.
This is required by the specification, and prevents data loss when the
device's buffer overruns.
Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Reviewed-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Tested-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
There are several devices that expect to receive MIDI data only in the
first eight data blocks of a packet. If the driver restricts the data
rate to the allowed rate (as mandated by the specification, but not yet
implemented by this driver), this happens naturally. Therefore, there
is no reason to ever try to use more data packets with any device.
Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Reviewed-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Tested-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Although the 't->length' is a big-endian value, it's used without any
conversion. This means that the driver always uses 'length' parameter.
Fixes: 555e8a8f7f14("ALSA: fireworks: Add command/response functionality into hwdep interface")
Reported-by: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This code tends to use unsigned variables by default and it causes
signedness bugs when we use negative variables for error handling.
The "i" and "j" variables are used to iterated over small positive
values and so they should be type "int". The "len" variable doesn't
*need* to be signed but it should be signed to make the code easier to
read and audit.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This code causes a static checker warning:
sound/firewire/oxfw/oxfw.c:46 detect_loud_models()
warn: signedness bug returning '(-2)'
The detect_loud_models() function should return false on falure, so that
we don't try to set up the loud code for hardware that doesn't support
it.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This interface is designed for mixer/control application. By using this
interface, an application can get information about firewire node, can
lock/unlock kernel streaming and can get notification at starting/stopping
kernel streaming.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Acked-by: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This commit adds MIDI functionality with an assumption of 'if the device
has MIDI comformant data channels in its stream formation, the device has
one MIDI port'.
When no streams have already started, MIDI functionality starts stream
with current sampling rate.
When MIDI functionality has already starts some streams and PCM
functionality is going to start streams at different sampling rate,
this driver stops streams once and changes sampling rate, then restarts
streams for both PCM/MIDI substreams.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Acked-by: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
In previous commit, a support for transmitted packets is added. This commit
add a support for capturing PCM samples.
When any streams are already started, this driver should not change sampling
rate of the device, thus this commit also adds a restriction of sampling rate
in this situation.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Acked-by: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Some devices produced by Behringer/Mackie are based on OXFW970/971. This
commit adds support for them. Additionally, this commit changes the way to
name card with some information in config rom.
Ids of some Mackie(Loud) models are not identified, therefore this commit
applies name detection for these models.
The devices support capture/playback of PCM-samples and some of them
supports capture/playback of MIDI messages. These functionalities are
implemented by followed commits.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Acked-by: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
In past commit, this driver can keep stream formations for each sampling
rate. So its stream functionality can decide stream formations with given
some parameters.
This commit moves related codes from PCM functionality to stream
functionality. Furthermore, to set stream format correctly, this commit
uses AV/C Stream Format Information command instead of AV/C Input/Output
Plug Signal Format command.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Acked-by: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This commit adds proc interface to get information about stream
formation. This commit also adds snd_oxfw_stream_get_current_formation()
to get current stream formation.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Acked-by: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
In previous commit, this driver can get to know stream formations at
each supported sampling rates. This commit uses it to make PCM
rules/constraints and obsoletes hard-coded rules/constraints.
For this purpose, this commit adds 'struct snd_oxfw_stream_formation' and
snd_oxfw_stream_parse_format() to parse data channel formation of data
block.
According to datasheet of OXFW970/971, they support 32.0kHz to 196.0kHz.
As long as developers investigate, some devices are confirmed to have
several formats for the same sampling rate.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Acked-by: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
OXFW970/971 may supports AV/C Stream Format Information Specification 1.1
Working Draft (Apr 2005, 1394TA). By using this command, drivers can get to know
stream formations which device supports.
This commit adds 'EXTENDED STREAM FORMAT INFORMATION' command. This command
has two subfunctions, 'SINGLE' and 'LIST'. Drivers can use 'SINGLE' subfunction
to know/set current formation of AMDTP stream, Drivers can use 'LIST'
subfunction to know an available formation of AMDTP stream in a certain sampling
rate.
But some devices don't implement the 'LIST' subfunction. So this commit uses
an assumption that 'if they don't implement it, they don't change stream
formation depending on current each sampling rate'. With this assumption, this
driver generates formations for such devices by:
1.getting current formation by SINGLE subfunction
2.getting supported sampling rates
3.applying current formation for all of supported sampling rates
Followed commit implements a parser of this format information.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Acked-by: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This is a preparation for more models. In following commit, members
of 'struct snd_card' related to name becomes to consists of vendor and
model strings in device's config-rom.
Current supported devices also has strings in their config rom, but the
strings are too long to name sound card, thus this driver still keep
hard-coded vendor and model names for them.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Acked-by: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Takashi Sakamoto