In ALSA firewire stack, 8 drivers uses IEC 61883-1/6 engine for data
transmission. They have common PCM info/constraints and duplicated codes.
This commit unifies the codes into fireiwre-lib.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
In recent commit for ALSA PCM core, some arrangement is done for
'struct snd_pcm_ops.ack' callback. This is called when appl_ptr is
explicitly moved in intermediate buffer for PCM frames, except for
some cases described later.
For drivers in ALSA firewire stack, usage of this callback has a merit to
reduce latency between time of PCM frame queueing and handling actual
packets in recent isochronous cycle, because no need to wait for software
IRQ context from isochronous context of OHCI 1394.
If this works well in a case that mapped page frame is used for the
intermediate buffer, user process should execute some commands for ioctl(2)
to tell the number of handled PCM frames in the intermediate buffer just
after handling them. Therefore, at present, with a combination of below
conditions, this doesn't work as expected and user process should wait for
the software IRQ context as usual:
- when ALSA PCM core judges page frame mapping is available for status
data (struct snd_pcm_mmap_status) and control data
(struct snd_pcm_mmap_control).
- user process handles PCM frames by loop just with 'snd_pcm_mmap_begin()'
and 'snd_pcm_mmap_commit()'.
- user process uses PCM hw plugin in alsa-lib to operate I/O without
'sync_ptr_ioctl' option.
Unfortunately, major use case include these three conditions.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
In IEC 61883-6, AM824 is described as format of data block. In this
format, one data block consists of several data channels, which is aligned
to 32 bit. One data channel has 8 bit label field and 24 bit data field.
PCM frames are transferred in Multi Bit Linear Audio (MBLA) data channel.
This channel can include 16/20/24 bit PCM sample.
As long as I know, models which support IEC 61883-1/6 doesn't allow to
switch bit length of PCM sample in MBLA data channel. They always
transmit/receive PCM frames of 24 bit length. This can be seen for the
other models which support protocols similar to IEC 61883-1/6.
On the other hand, current drivers for these protocols supports 16 bit
length PCM sample in playback substream. In this case, PCM sample is put
into the MBLA data channel with 8 bit padding in LSB side. Although 16
bit PCM sample is major because it's in CD format, this doesn't represent
device capability as is.
This commit removes support for 16 bit PCM samples in playback substream.
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 identifiers are referred just by one functions. In this case, they
can be put into the function definition. This brings two merits; readers
can easily follow codes related to the identifiers, developers are free
from name conflict.
This commit moves such identifiers to each function definition.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Check for snd_pcm_ops structures that are only stored in the ops field of a
snd_soc_platform_driver structure or passed as the third argument to
snd_pcm_set_ops. The corresponding field or parameter is declared const,
so snd_pcm_ops structures that have this property can be declared as const
also.
The semantic patch that makes this change is as follows:
(http://coccinelle.lip6.fr/)
// <smpl>
@r disable optional_qualifier@
identifier i;
position p;
@@
static struct snd_pcm_ops i@p = { ... };
@ok1@
identifier r.i;
struct snd_soc_platform_driver e;
position p;
@@
e.ops = &i@p;
@ok2@
identifier r.i;
expression e1, e2;
position p;
@@
snd_pcm_set_ops(e1, e2, &i@p)
@bad@
position p != {r.p,ok1.p,ok2.p};
identifier r.i;
struct snd_pcm_ops e;
@@
e@i@p
@depends on !bad disable optional_qualifier@
identifier r.i;
@@
static
+const
struct snd_pcm_ops i = { ... };
// </smpl>
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Reviewed-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 hwdep interface so as the other IEEE 1394 sound devices
has.
This interface is designed for mixer/control applications. 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>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This commit adds PCM functionality to transmit/receive PCM samples.
When one of PCM substreams are running or external clock source is
selected, current sampling rate is used. Else, the sampling rate is
changed as an userspace application requests.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Takashi Sakamoto