Fireworks uses TSB43CB43(IceLynx-Micro) as its IEC 61883-1/6 interface.
This chip includes ARM7 core, and loads and runs program. The firmware
is stored in on-board memory and loaded every powering-on from it.
Echo Audio ships several versions of firmwares for each model. These
firmwares have each quirk and the quirk changes a sequence of packets.
As long as I investigated, AudioFire2/AudioFire4/AudioFirePre8 have a
quirk to transfer a first packet with 0x02 in its dbc field. This causes
ALSA Fireworks driver to detect discontinuity. In this case, firmware
version 5.7.0, 5.7.3 and 5.8.0 are used.
Payload CIP CIP
quadlets header1 header2
02 00050002 90ffffff <-
42 0005000a 90013000
42 00050012 90014400
42 0005001a 90015800
02 0005001a 90ffffff
42 00050022 90019000
42 0005002a 9001a400
42 00050032 9001b800
02 00050032 90ffffff
42 0005003a 9001d000
42 00050042 9001e400
42 0005004a 9001f800
02 0005004a 90ffffff
(AudioFire2 with firmware version 5.7.)
$ dmesg
snd-fireworks fw1.0: Detect discontinuity of CIP: 00 02
These models, AudioFire8 (since Jul 2009 ) and Gibson Robot Interface
Pack series uses the same ARM binary as their firmware. Thus, this
quirk may be observed among them.
This commit adds a new member for AMDTP structure. This member represents
the value of dbc field in a first AMDTP packet. Drivers can set it with
a preferred value according to model's quirk.
Tested-by: Johannes Oertei <johannes.oertel@uni-due.de>
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Cc: <stable@vger.kernel.org>
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>
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>
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>
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>
Add a new helper function snd_pcm_stop_xrun() to the standard sequnce
lock/snd_pcm_stop(XRUN)/unlock by a single call, and replace the
existing open codes with this helper.
The function checks the PCM running state to prevent setting the wrong
state, too, for more safety.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
In IEC 61883-6, one data block transfers one event. In ALSA, the event equals one PCM frame,
hence one data block transfers one PCM frame. But Dice has a quirk at higher sampling rate
(176.4/192.0 kHz) that one data block transfers two PCM frames.
Commit 10550bea44 ("ALSA: dice/firewire-lib: Keep dualwire mode but obsolete
CIP_HI_DUALWIRE") moved some codes related to this quirk into Dice driver. But the commit
forgot to add arrangements for PCM period interrupts and DMA pointer updates. As a result, Dice
driver cannot work correctly at higher sampling rate.
This commit adds 'double_pcm_frames' parameter to amdtp structure for this quirk. When this
parameter is set, PCM period interrupts and DMA pointer updates occur at double speed than in
IEC 61883-6.
Reported-by: Daniel Robbins <drobbins@funtoo.org>
Fixes: 10550bea44 ("ALSA: dice/firewire-lib: Keep dualwire mode but obsolete CIP_HI_DUALWIRE")
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Cc: <stable@vger.kernel.org> # 3.16
Signed-off-by: Takashi Iwai <tiwai@suse.de>
According to AM824 in IEC 61883-6:2002, 2 bits in LSB of label for Raw Audio
data means Valid Length Code (VBL). Ths value is:
- b00 for 24 bits sample (label is 0x40)
- b01 for 20 bits sample (label is 0x41)
- b10 for 16 bits sample (label is 0x42)
But current firewire-lib apply 24 bits label for both of 16/24 bits samples.
As long as developers investigate BeBoB/Fireworks/OXFW/Dice, all of them
have a behaviour to ignore the label. They can generate correct sound even
if firewire-lib gives wrong label (i.e. 0xff). On BeBoB, this is not only
for Raw Audio data channel, but also for IEC 60958 Conformant data channel.
So there is little possibility of regression.
Acked-by: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This commit fixes a big for loop count with array. The limitation of loop
count should be calcurated with the number of elements in the array, not
with the number of bytes.
Aditionally, this commit apply the same declaration as a prototype in header
for the array.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
M-Audio Firewire 1814 has a quirk, ProjectMix I/O also has. They transmit
empty packet with wrong value of dbc incremented by 8 at high sampling rate.
According to IEC 61883-1, this value should be the same as the one in
previous packet.
This commit adds a flag named as CIP_EMPTY_HAS_WRONG_DBC. With flag, the value
of dbc in empty packet is overwittern by an expected value.
This is an example of this quirk:
CIP Header 0 CIP Header 1 Payload size
010D0000 9004F759 210
010D0010 90040B59 210
010D0020 90042359 210
01020028 9004FFFF 2 <-
010D0030 90043759 210
010D0040 90044B59 210
010D0050 90046359 210
01020058 9004FFFF 2 <-
010D0060 90047759 210
010D0070 90048B59 210
010D0080 9004A359 210
01020088 9004FFFF 2 <-
010D0090 9004B759 210
010D00A0 9004CB59 210
010D00B0 9004E359 210
010200B8 9004FFFF 2 <-
010D00C0 9004F759 210
010D00D0 90040B59 210
010D00E0 90042359 210
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Normal BeBoB firmware has a quirk. When receiving bus reset, it transmits
packets with discontinuous value in dbc field.
This causes two situation, one is to abort streaming by firewire-lib as a
result of detecting the discontinuity. Another is to call driver's .update()
because of bus reset. These two is generated independently. (The former
depends on isochronous stream and the latter depends on IEEE1394 bus driver.)
When BeBoB driver works with XRUN-recoverable applications, this situation
looks like stream_start_duplex() call followed by stream_update_duplex() call
because applications will call snd_pcm_prepare() immediately at XRUN.
To update connections and streams at first, this commit use completion. When
queueing error occurs, stream_start_duplex() is forced to wait maximum
1000msec. During this, when .update() is called, the completion is waken and
stream_start_duplex() is processed without breaking connections.
At bus reset, stream_start_duplex() shouldn't break/establish connections and
stream_update_duplex() should update connections because a caller of
fw_iso_resources_allocate() is responsible for calling
fw_iso_resources_update() on bus reset.
This commit also adds a flag, which has an effect to skip checking continuity
for first packet. This flag is useful for BeBoB quirk to start handling packets
during streaming.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Fireworks has a quirk to ignore MIDI messages in data blocks more than 8.
This commit adds a flag for this quirk and codes to skip 8 or more data
blocks to transfer MIDI messages.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Fireworks has a quirk to reset data block counter at bus reset.
This commit adds a flag of CIP_SKIP_DBC_ZERO_CHECK. This flag has an effect
to skip checking dbc continuity when dbc is zero.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Fireworks firmware version 5.5 reports fix interval for dbc in each packet.
For example, AudioFire4:
CIP0 CIP1 Payload
00070000 900484FF 72
00070008 9004A8FF 72
00070008 90FFFFFF 02
00070010 9004D0FF 72
00070018 9004C4FF 72
00070020 9004E8FF 72
00070020 90FFFFFF 02
00070028 900410FE 72
The interval of each dbc should be 16 except for empty packet but it's still 8.
This commit adds a flag for this quirk and codes to refer to a fixed value.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
One of Fireworks firmware, named as 'AudioFire9', seems to transmit
packets with wrong value of dbs. It's always 0x11 but actual size of
data block is different.
This commit adds a flag for this quirk and some codes to calculate
correct size.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Fireworks has a quirk for the value of dbc field in transmitted packets.
For Fireworks, dbc means the end of events in current packet. This is out
of specification.
For example, AudioFire4:
CIP0 CIP1 Payload
01070092 90FFFFFF 02
0107009A 9001E17B 3A <-
010700A2 9001F6E5 3A
010700A2 90FFFFFF 02
010700AA 9001104F 3A <-
010700B2 900125B9 3A
010700BA 90013B23 3A
010700BA 90FFFFFF 02
010700C2 9001548E 3A <-
010700CA 900169F8 3A
010700CA 90FFFFFF 02
010700D2 90018362 3A <-
010700DA 900198CC 3A
According to IEC 61883-1/6, a packet following to empty packet has the same
value for its dbc. But for Fireworks, it's incremented and empty packet has
the same value as previous packet in dbc field.
This commit adds a flag for Fireworks and some codes to checking dbc continuity.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Fireworks has a quirk to transmit empty packets with TAG0. This commit
adds handling this quirk for full duplex stream synchronization.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This commit adds three commands, which may be used by some firewire device
drivers. These commands are defined in 'AV/C Digital Interface Command Set
General Specification Version 4.2 (2004006, 1394TA)'.
1. PLUG INFO command (clause 10.1)
2. INPUT PLUG SIGNAL FORMAT command (clause 10.10)
3. OUTPUT PLUG SIGNAL FORMAT command (clause 10.11)
By the command 1, the drivers can get the number of plugs for AV/C unit or
subunit.
By the command 2 and 3, the drivers can get/set sampling frequency.
The 'firewire-speakers' already uses INPUT PLUG SIGNAL FORMAT command to set
sampling rate. So this commit also affects the driver.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Currently, drivers can bring XRUN state for PCM substreams when error to
queue packets or detecting discontinuity of packet. The application may try to
recover this state by calling snd_pcm_prepare().
Depending on each driver, .prepare() includes restart streaming. Then there
is a state that PCM substreams are running but isochronous contexts are
stopped. In this case, when .pointer() is called, it refers to error pointer.
This commit is for a prevention of this bug.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This commit adds common PCM constraints according to current firewire-lib
implementation.
1.Maximum width for each sample is limited by 24.
AM824 in IEC 61883-6 can deliver 24bit data.
2. Minimum time for period is 5msec.
Apply the old value. For shorter latency, further works are needed.
3. In blocking mode, frames per period/buffer is aligned to 32.
Each packet can include some frames depending on its sampling rate. In
blocking mode, the number equals to SYT_INTERVAL. Currently firewire-lib
can schedule snd_pcm_period_elapsed() for each packet. So, for accurate
PCM interrupt, the number of frames per period/buffer should be aligned
to SYT_INTERVAL.
Currently firewire-lib is lack of better rules to achieve this. So LCM of
each value of SYT_INTERVALs (=32) is applied. This can be improved for
further work.
[Fixed the compile error due to the missing "&" by tiwai]
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
In previous commit, AMDTP functionality in firewire-lib supports mapping
for PCM data channels. With this mapping, firewire-lib can obsolete
a flag, CIP_HI_DUALWIRE, but Dice driver still keeps dual wire mode.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Some devices arrange the position of PCM/MIDI data channel in AMDTP packet.
This commit allows drivers to set channel mapping.
To be simple, the mapping table is an array with fixed length. Then the number
of channels for PCM is restricted by 64 channels.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Generally, the devices can synchronize to handle 'presentation timestamp'
in CIP packets. This commit adds functionality to pick up this timestamp from
in-packets transmitted by the device, then use it for out packets.
In current implementation, this module generated the timestamp by itself. This
is 'SYT Match' mode. Then drivers with this module acts as synchronization
master. This commit allows this module to act as synchronization slave.
This commit restricts this mechanism is only available in blocking mode because
handling the timestamp in non-blocking mode is more complicated than in
blocking mode.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
For duplex streams with synchronization, drivers should pick up
'presentation timestamp' from in-packets and use the timestamp for
out-packets. This commit is preparation for this.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
For capturing/playbacking MIDI messages, this commit adds one MIDI conformant
data channel. This data channel has multiplexed 8 MIDI data streams. So this
data channel can transfer messages from/to 8 MIDI ports.
And this commit allows to set PCM format even if AMDTP streams already start.
I suppose the case that PCM substreams are going to be joined into AMDTP
streams when AMDTP streams are already started for MIDI substreams. Each
driver must count how many PCM/MIDI substreams use AMDTP streams to stop
AMDTP streams.
There are differences between specifications about MIDI conformant data.
About the multiplexing, IEC 61883-6:2002, itself, has no information. It
describes labels and bytes for MIDI messages and refers to MMA/AMEI RP-027
for 'successfull implementation'. MMA/AMEI RP-027 describes 8 MPX-MIDI data
streams for one MIDI conformant data channel. IEC 61883-6:2005 adds
'sequence multiplexing' and apply this way and describe incompatibility
between 2002 and 2005.
So this commit applies IEC 61883-6:2005. When we find some devices compliant
to IEC 61883-6:2002, then this difference should be handles as device quirk
in additional work.
About the number of bytes in an MIDI conformant data, IEC 61883-6:2002 describe
0,1,2,3 bytes. MMA/AMEI RP-027 describes 'MIDI1.0-1x-SPEED', 'MIDI1.0-2x-SPEED',
'MIDI1.0-3x-SPEED' modes and the maximum bytes for each mode corresponds to 1,
2, 3 bytes. The 'MIDI1.0-2x/3x-SPEED' modes are accompanied with 'negotiation
procedure' and 'encapsulation details' but there is no specifications for them.
So this commit implements 'MIDI1.0-1x-SPEED' mode for playback, but allows
to pick up 1-3 bytes for capturing.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
For capturing PCM, this commit adds the functionality to handle in-stream.
This is also applied for dual-wire mode.
Currently, capturing 32bit samples are supported.
When the sequence of in-packet has discontinuity of dbc, in-stream isn't handled
and amdtp_streaming_error() returns true.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Some codes can be reused to handle in-stream. This commit adds new functions.
This commit also renames some functions to keep naming consistency.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This patch adds 'direction' member to amdtp_stream structure to indicate its
direction. This patch also adds 'direction' argument to amdtp_stream_init()
function to determine its direction.
The amdtp_stream_init() function is exported and used by firewire-speakers and
dice so this patch also affects them.
This patch just add them. Actual implementation will be done by followed
patches.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This patch adds some macros instead of fixed value for AMDTP according to
IEC 61883-1/6. These macros will also be used by followed patches.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This patch renames some functions, a structure and its member to reuse them
in both AMDTP in/out stream.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This commit fix out of specification about the value of FDF field in out packet
with 'no data'. This affects blocking mode.
According to IEC 61883-6, there is two way to generate AMDTP packets include no
data in blocking mode.
Way 1. an empty packet defined in IEC 61883-1
- Size of packet is 2 quadlets.
- The value of FDF is sfc.
- The packet includes only CIP headers
Way 2. a special non-empty packet defined in IEC 61883-6
- Size of packet is following to blocking mode
- The value of FDF is 0xff. This value is 'NO-DATA'. This means 'The receiver'
must ignore all the data in a CIP with this FDF code'.
- The packet includes dummy data.
But current implementation is a combination of them.
- Size of packet is 2 (way 1)
- FDF = 0xff (way 2)
This causes BeBoB chipset cannot sound.
This patch applies Way 1.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Cc: Acked-by: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Change the AMDTP streaming code to handle the non-standard stream format
that DICE devices use at sample rates greater than 96 kHz.
Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Introduce the helper function amdtp_out_stream_running(). This makes
many checks in amdtp.c clearer and frees the device drivers from having
to track this with a separate variable.
Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Allow AMDTP output streams to use blocking mode.
Use it for DICE devices, because the old DICE-II chip will in some cases
not be able to lock to non-blocking streams (erratum E7).
Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Calculating frame bytes can be replaced with inline function in
include/sound/pcm.h.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Trying to flush completed packets is pointless when the pointer
callback was called from the packet completion callback; avoid it.
Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
By flushing all completed but not yet reported packets before reading
the PCM hardware position, the granularity of the pointer is improved
from the interrupt interval to the packet size.
Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Takashi Sakamoto