Commit Graph

9 Commits

Author SHA1 Message Date
Takashi Sakamoto 76ea468877 ALSA: fireface: code refactoring to handle multiplier mode
Fireface 400/800 use three modes against the number of data channels in
data block for both tx/rx packets.

This commit adds refactoring for it. Some enumerators are added to
represent each of mode and a function is added to calculate the mode
from sampling frequency code (sfc).

Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2018-12-16 10:18:25 +01:00
Takashi Sakamoto 3c3b892b37 ALSA: fireface: share helper function to get current sampling rate and clock source
As long as investigating packet dumps from Fireface 400/800, bits on
status registers for clock synchronization are the same.

This commit moves a parser for a register of clock configuration to
obsolete model-specific operations.

Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2018-12-11 14:56:20 +01:00
Takashi Iwai fa84cf094e ALSA: pcm: Nuke snd_pcm_lib_mmap_vmalloc()
snd_pcm_lib_mmap_vmalloc() was supposed to be implemented with
somewhat special for vmalloc handling, but in the end, this turned to
just the default handler, i.e. NULL.  As the situation has never
changed over decades, let's rip it off.

Reviewed-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2018-07-18 08:24:29 +02:00
Markus Elfring af43173c80 ALSA: fireface: Use common error handling code in pcm_open()
Add a jump target so that a bit of exception handling can be better reused
at the end of this function.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
Reviewed-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2017-08-23 15:52:44 +02:00
Takashi Sakamoto 55799c5ab9 ALSA: firewire: arrange common PCM info/constraints for AMDTP engine applications
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>
2017-06-08 09:15:44 +02:00
Takashi Sakamoto d2dc2a96de ALSA: fireface: constify ALSA specific operations
ALSA fireface driver has ALSA specific operations for MIDI/PCM data.
Structured data for the operations can be constified. Additionally,
The structured data can be function local.

Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2017-06-07 07:55:15 +02:00
Takashi Sakamoto 875becf841 ALSA: firewire: process packets in 'struct snd_pcm_ops.ack' callback
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>
2017-06-07 07:53:32 +02:00
Takashi Sakamoto f656edd5fb ALSA: fireface: add hwdep interface
This commit adds hwdep interface so as the other drivers for audio and
music units on IEEE 1394 have.

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>
2017-04-05 21:31:49 +02:00
Takashi Sakamoto 4b316436ab ALSA: fireface: add support for PCM functionality
This commit adds PCM functionality to transmit/receive PCM frames on
isochronous packet streaming. This commit enables userspace applications
to start/stop packet streaming via ALSA PCM interface.

Sampling rate requested by applications is used as sampling transmission
frequency of IEC 61883-1/6packet streaming. As I described in followed
commits, units in this series manages sampling clock frequency
independently of sampling transmission frequency, and they supports
resampling between their packet streaming/data block processing layer and
sampling data processing layer. This commit take this driver to utilize
these features for usability.

When internal clock is selected as source signal of sampling clock, this
driver allows user space applications to start PCM substreams at any rate
which packet streaming engine supports as sampling transmission frequency.
In this case, this driver expects units to perform resampling PCM frames
for rx/tx packets when sampling clock frequency and sampling transmission
frequency are mismatched. This is for daily use cases.

When any external clock is selected as the source signal, this driver
gets configured sampling rate from units, then restricts available
sampling rate to the rate for PCM applications. This is for studio use
cases.

Models in this series supports 64.0/128.0 kHz of sampling rate, however
these frequencies are not supported by IEC 61883-6 as sampling transmission
frequency. Therefore, packet streaming engine of ALSA firewire stack can't
handle them. When units are configured to use any external clock as source
signal of sampling clock and one of these unsupported rate is configured
as rate of the sampling clock, this driver returns EIO to user space
applications.

Anyway, this driver doesn't voluntarily configure parameters of sampling
clock. It's better for users to work with appropriate user space
implementations to configure the parameters in advance of usage.

Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2017-04-05 21:31:46 +02:00