summaryrefslogtreecommitdiffstats
path: root/sound/firewire
AgeCommit message (Collapse)AuthorFilesLines
2019-11-07Merge branch 'for-linus' into for-nextTakashi Iwai1-0/+3
Merge 5.4-devel branch for applying the further ALSA timer fixes. Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-11-06ALSA: firewire: Convert to the common vmalloc memallocTakashi Iwai9-47/+40
The recent change (*) in the ALSA memalloc core allows us to drop the special vmalloc-specific allocation and page handling. This patch coverts to the common code. (*) 1fe7f397cfe2: ALSA: memalloc: Add vmalloc buffer allocation support 7e8edae39fd1: ALSA: pcm: Handle special page mapping in the default mmap handler Link: https://lore.kernel.org/r/20191105151856.10785-11-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-11-04ALSA: bebob: fix to detect configured source of sampling clock for Focusrite ↵Takashi Sakamoto1-0/+3
Saffire Pro i/o series For Focusrite Saffire Pro i/o, the lowest 8 bits of register represents configured source of sampling clock. The next lowest 8 bits represents whether the configured source is actually detected or not just after the register is changed for the source. Current implementation evaluates whole the register to detect configured source. This results in failure due to the next lowest 8 bits when the source is connected in advance. This commit fixes the bug. Fixes: 25784ec2d034 ("ALSA: bebob: Add support for Focusrite Saffire/SaffirePro series") Cc: <stable@vger.kernel.org> # v3.16+ Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20191102150920.20367-1-o-takashi@sakamocchi.jp Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-11-02ALSA: bebob: link the order of establishing connections and Syt-match clock modeTakashi Sakamoto1-29/+22
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>
2019-11-02ALSA: bebob: expand delay of start for IR context just for version 3 firmwareTakashi Sakamoto1-4/+10
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>
2019-11-02ALSA: bebob: expand sleep just after breaking connections for protocol version 1Takashi Sakamoto1-5/+6
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>
2019-10-30ALSA: firewire-motu: Correct a typo in the clock proc stringTakashi Iwai1-1/+1
Just fix a typo of "S/PDIF" in the clock name string. Fixes: 4638ec6ede08 ("ALSA: firewire-motu: add proc node to show current statuc of clock and packet formats") Acked-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20191030100921.3826-1-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-10-30ALSA: firewire-motu: add support for MOTU UltraLiteTakashi Sakamoto1-0/+14
UltraLite was shipped in 2005 by MOTU, and already discontinued. This model consists of below ICs: - Texus Instruments TSB41AB2 for physical layer of IEEE 1394 bus - Xilinx Spartan XC35S200 for link layer of IEEE 1394 bus, protocol layer and signal processing This commit adds support for this model. Like the other MOTU models, ALSA firewire MOTU driver fails to drive the device for stable sampling clock and generate noisy sound. $ python2 crpp < /sys/bus/firewire/devices/fw1/config_rom ROM header and bus information block ----------------------------------------------------------------- 400 04107574 bus_info_length 4, crc_length 16, crc 30068 404 31333934 bus_name "1394" 408 20001000 irmc 0, cmc 0, isc 1, bmc 0, cyc_clk_acc 0, max_rec 1 (4) 40c 0001f200 company_id 0001f2 | 410 0007b82d device_id 000007b82d | EUI-64 0001f2000007b82d root directory ----------------------------------------------------------------- 414 0004c65c directory_length 4, crc 50780 418 030001f2 vendor 41c 0c0083c0 node capabilities per IEEE 1394 420 8d000006 --> eui-64 leaf at 438 424 d1000001 --> unit directory at 428 unit directory at 428 ----------------------------------------------------------------- 428 0003d80a directory_length 3, crc 55306 42c 120001f2 specifier id 430 1300000d version 434 17100800 model eui-64 leaf at 438 ----------------------------------------------------------------- 438 00024566 leaf_length 2, crc 17766 43c 0001f200 company_id 0001f2 | 440 0007b82d device_id 000007b82d | EUI-64 0001f2000007b82d Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20191030080644.1704-7-o-takashi@sakamocchi.jp Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-10-30ALSA: firewire-motu: code refactoring to handle model specific switch for ↵Takashi Sakamoto3-44/+43
protocol v2 In MOTU FireWire series, devices which support protocol version 2 have several types of hardware design to process audio data frames for isoc packet. Roughly devices are categorized into three groups: - 828mkII - Traveler/896HD - UltraLite/8pre FireWire Some bit flags in register addressed by 0x'ffff'f000'0b14 includes device-specific effects. This commit cleanups implementation of protocol v2 in this point. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20191030080644.1704-6-o-takashi@sakamocchi.jp Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-10-30ALSA: firewire-motu: minor code refactoring for protocol version 2Takashi Sakamoto1-26/+39
This commit adds some helper functions to parse register value for source of sampling clock and nominal sampling transmission frequency. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20191030080644.1704-5-o-takashi@sakamocchi.jp Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-10-30ALSA: firewire-motu: detect SPH source of sampling clockTakashi Sakamoto5-1/+9
In MOTU FireWire series, devices have a mode to generate sampling clock from a sequence of source packet header (SPH) included in each data block of received packet. This mode is used for several purposes such as mode for SMPTE time code, sync to the other sound cards and so on. This commit adds support for the SPH mode. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20191030080644.1704-4-o-takashi@sakamocchi.jp Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-10-30ALSA: firewire-motu: print for unknown source of sampling clockTakashi Sakamoto1-0/+1
When unknown source is detected for sampling clock, corresponding label was not added for node on procfs. This commit adds it. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20191030080644.1704-3-o-takashi@sakamocchi.jp Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-10-30ALSA: firewire-motu: fix wrong spelling for macroTakashi Sakamoto4-7/+7
Just replace 'SEPARETED' with 'SEPARATED' for macro. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20191030080644.1704-2-o-takashi@sakamocchi.jp Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-10-28Merge branch 'for-linus' into for-nextTakashi Iwai1-2/+1
Back-merge the development process for catching up the HD-audio fix (and apply a new one on top of that). Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-10-26ALSA: bebob: Fix prototype of helper function to return negative valueTakashi Sakamoto1-2/+1
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>
2019-10-19ALSA: firewire-lib: postpone to start IR contextTakashi Sakamoto10-15/+98
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>
2019-10-19ALSA: firewire-lib: handle several AMDTP streams in callback handler of IRQ ↵Takashi Sakamoto2-46/+140
target This commit changes AMDTP domain to run on an IT context of 1394 OHCI as IRQ target. No hardware interrupt is scheduled for the other isoc contexts. All of the isoc context are processed in a callback for an isoc context of IRQ target. The IRQ target is automatically selected from a list of AMDTP streams, thus users of AMDTP domain should add an AMDTP stream for IT context at least. The reason to select IT context as IRQ target is that the IT context runs on local 1394 OHCI controller and it can be used as reliable, constant IRQ generator. On the other hand, IR context can include skip cycle according to isoc packet transferred by device. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20191018061911.24909-6-o-takashi@sakamocchi.jp Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-10-19ALSA: firewire-lib: cancel flushing isoc context in the laste step to ↵Takashi Sakamoto1-4/+0
process context callback The aim of AMDTP domain is to process several isoc context in the same time. However, current implementation is against this idea because it flushes each isoc context in the end of processing context callback. This commit cancels it. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20191018061911.24909-5-o-takashi@sakamocchi.jp Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-10-19ALSA: firewire-lib: replace ack callback to flush isoc contexts in AMDTP domainTakashi Sakamoto10-26/+33
An isoc context for AMDTP stream is flushed to queue packet by a call of pcm.ack. This commit extends this for AMDTP domain. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20191018061911.24909-4-o-takashi@sakamocchi.jp Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-10-19ALSA: firewire-lib: replace pointer callback to flush isoc contexts in AMDTP ↵Takashi Sakamoto10-42/+56
domain An isoc context for AMDTP stream is flushed to queue packet by a call of pcm.pointer. This commit extends this for AMDTP domain. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20191018061911.24909-3-o-takashi@sakamocchi.jp Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-10-19ALSA: firewire-lib: add irq_target member into amdtp_domain structTakashi Sakamoto1-0/+2
This commit is a preparation to handle several IR/IT contexts in the same domain by tasklet context for one of the IT context. Such IT context is stored to AMDTP domain structure as 'irq_target'. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20191018061911.24909-2-o-takashi@sakamocchi.jp Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-10-18ALSA: firewire-lib: tune the minimum available size of PCM periodTakashi Sakamoto1-1/+13
In IEC 61883-1/6, one isoc packet can transfer events up to the value of syt interval. This comes from the interval of isoc cycle. As 1394 OHCI controller can generate hardware IRQ per isoc packet, the interval is calculated as 125 usec. In IEC 61883-1/6, two ways of transmission is described; blocking and non-blocking methods. In blocking method, the sequence of packet includes 'empty' or 'NODATA' packets which include no events. In non-blocking method, the number of events per packet is variable up to the syt interval. This commit uses double of the value of syt interval as minimum available size of PCM period due to the above protocol design. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20191017155424.885-13-o-takashi@sakamocchi.jp Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-10-18ALSA: firewire-lib: tune the maximum available size of PCM periodTakashi Sakamoto1-11/+18
Linux driver for 1394 OHCI controller voluntarily flushes isoc context when total size of accumulated context header reached PAGE_SIZE. This kicks tasklet for the isoc context. This is inconvenient to process runtime of PCM substream. This commit adds a restriction of the maximum size of PCM period to avoid this behaviour. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20191017155424.885-12-o-takashi@sakamocchi.jp Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-10-18ALSA: firewire-lib: schedule hardware IRQ according to the size of PCM periodTakashi Sakamoto2-15/+58
ALSA IEC 61883-1/6 packet streaming engine controls 1394 OHCI controller to generate hardware IRQ for fixed number of isochronous packets (=16) since its first commit. This commit allow the engine to generate it for variable period according to the number of event to handle. For outgoing stream, internal calculator is used to check the accumulated events. For incoming stream, the number of data block in the packet of stream is used to check the accumulated events. When it's unavailable, fixed number of packet roughly calculated in advance is used instead of event counting. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20191017155424.885-11-o-takashi@sakamocchi.jp Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-10-18ALSA: fireface: share PCM buffer size for both directionTakashi Sakamoto3-4/+17
This commit allows ALSA fireface 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-10-o-takashi@sakamocchi.jp Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-10-18ALSA: firewire-motu: share PCM buffer size for both directionTakashi Sakamoto4-5/+17
This commit allows ALSA firewire-motu 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-9-o-takashi@sakamocchi.jp Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-10-18ALSA: firewire-tascam: share PCM buffer size for both directionTakashi Sakamoto3-4/+16
This commit allows ALSA firewire-tascam 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-8-o-takashi@sakamocchi.jp Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-10-18ALSA: firewire-digi00x: share PCM buffer size for both directionTakashi Sakamoto4-5/+17
This commit allows ALSA firewire-digi00x 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-7-o-takashi@sakamocchi.jp Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-10-18ALSA: dice: share PCM buffer size for both directionTakashi Sakamoto4-7/+23
This commit allows ALSA dice 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-6-o-takashi@sakamocchi.jp Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-10-18ALSA: oxfw: share PCM buffer size for both directionTakashi Sakamoto4-7/+22
This commit allows ALSA oxfw 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-5-o-takashi@sakamocchi.jp Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-10-18ALSA: fireworks: share PCM buffer size for both directionTakashi Sakamoto4-5/+17
This commit allows ALSA fireworks 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-4-o-takashi@sakamocchi.jp Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-10-18ALSA: bebob: share PCM buffer size for both directionTakashi Sakamoto4-5/+17
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>
2019-10-18ALSA: firewire-lib: use variable size of queue for isoc packets instead of ↵Takashi Sakamoto10-26/+41
fixed size 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>
2019-10-17ALSA: fireface: use the same size of period for PCM substreams in AMDTP streamsTakashi Sakamoto1-6/+23
In current implementation, when opening a PCM substream, it's needed to check whether the opposite PCM substream runs. This is to assign effectual constraints (e.g. sampling rate) to opened PCM substream. The number of PCM substreams on AMDTP streams in domain is recorded in own structure. Usage of this count is an alternative of the above check. This is better because the count is incremented in pcm.hw_params earlier than pcm.trigger. This commit replaces the check with the substream count and the value for the size of PCM period. Unlike the other drivers in ALSA firewire stack, no MIDI substream is multiplexed into AMDTP stream. I note that Fireface AMDTP protocol has a quirk that tx stream includes blank isochronous cycle. The packet for blank cycle is equivalent to empty or NODATA packet in IEC 61883-6, thus the protocol is similar to blocking transmission method of IEC 61883-6. On the other hand, rx stream adopts non-blocking transmission method. Although the difference of transmission method between tx/rx streams precisely brings different timing for a certain amount of events due to their different calculation for data blocks per packet, it's possible to approximate enough amount of events mostly has the same timing. Actually current ALSA IEC 61883-1/6 engine uses large amount of data blocks for each hardware IRQ (=16 packets). Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20191007110532.30270-18-o-takashi@sakamocchi.jp Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-10-17ALSA: firewire-motu: use the same size of period for PCM substream in AMDTP ↵Takashi Sakamoto1-8/+21
streams In current implementation, when opening a PCM substream, it's needed to check whether the opposite PCM substream runs. This is to assign effectual constraints (e.g. sampling rate) to opened PCM substream. The number of PCM substreams and MIDI substreams on AMDTP streams in domain is recorded in own structure. Usage of this count is an alternative of the above check. This is better because the count is incremented in pcm.hw_params earlier than pcm.trigger. This idea has one issue because it's incremented for MIDI substreams as well. In current implementation, for a case that any MIDI substream run and a PCM substream is going to start, PCM application to start the PCM substream can decide hardware parameters by restart packet streaming. Just checking the substream count can brings regression. Now AMDTP domain structure has a member for the size of PCM period in PCM substream which starts AMDTP streams in domain. When the value has zero and the substream count is greater than 1, it means that any MIDI substream starts AMDTP streams in domain. Usage of the value can resolve the above issue. This commit replaces the check with the substream count and the value for the size of PCM period. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20191007110532.30270-17-o-takashi@sakamocchi.jp Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-10-17ALSA: firewire-tascam: use the same size of period for PCM substream in ↵Takashi Sakamoto1-8/+26
AMDTP streams In current implementation, when opening a PCM substream, it's needed to check whether the opposite PCM substream runs. This is to assign effectual constraints (e.g. sampling rate) to opened PCM substream. The number of PCM substreams on AMDTP streams in domain is recorded in own structure. Usage of this count is an alternative of the above check. This is better because the count is incremented in pcm.hw_params earlier than pcm.trigger. This commit replaces the check with the substream count and the value for the size of PCM period. Unlike the other drivers in ALSA firewire stack, no MIDI substream is multiplexed into AMDTP stream. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20191007110532.30270-16-o-takashi@sakamocchi.jp Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-10-17ALSA: firewire-digi00x: use the same size of period for PCM substream in ↵Takashi Sakamoto1-7/+28
AMDTP streams In current implementation, when opening a PCM substream, it's needed to check whether the opposite PCM substream runs. This is to assign effectual constraints (e.g. sampling rate) to opened PCM substream. The number of PCM substreams and MIDI substreams on AMDTP streams in domain is recorded in own structure. Usage of this count is an alternative of the above check. This is better because the count is incremented in pcm.hw_params earlier than pcm.trigger. This idea has one issue because it's incremented for MIDI substreams as well. In current implementation, for a case that any MIDI substream run and a PCM substream is going to start, PCM application to start the PCM substream can decide hardware parameters by restart packet streaming. Just checking the substream count can brings regression. Now AMDTP domain structure has a member for the size of PCM period in PCM substream which starts AMDTP streams in domain. When the value has zero and the substream count is greater than 1, it means that any MIDI substream starts AMDTP streams in domain. Usage of the value can resolve the above issue. This commit replaces the check with the substream count and the value for the size of PCM period. I note that DOT AMDTP protocol has a quirk to use different transmission method of IEC 61883-6 for tx/rx streams; non-blocking in tx stream and blocking in rx stream. Although the difference of transmission method between tx/rx streams precisely brings different timing for a certain amount of events due to their different calculation for data blocks per packet, it's possible to approximate enough amount of events mostly has the same timing. Actually current ALSA IEC 61883-1/6 engine uses large amount of data blocks for each hardware IRQ (=16 packets). Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20191007110532.30270-15-o-takashi@sakamocchi.jp Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-10-17ALSA: dice: use the same size of period for PCM substream in AMDTP streamsTakashi Sakamoto1-12/+31
In current implementation, when opening a PCM substream, it's needed to check whether the opposite PCM substream runs. This is to assign effectual constraints (e.g. sampling rate) to opened PCM substream. The number of PCM substreams and MIDI substreams on AMDTP streams in domain is recorded in own structure. Usage of this count is an alternative of the above check. This is better because the count is incremented in pcm.hw_params earlier than pcm.trigger. This idea has one issue because it's incremented for MIDI substreams as well. In current implementation, for a case that any MIDI substream run and a PCM substream is going to start, PCM application to start the PCM substream can decide hardware parameters by restart packet streaming. Just checking the substream count can brings regression. Now AMDTP domain structure has a member for the size of PCM period in PCM substream which starts AMDTP streams in domain. When the value has zero and the substream count is greater than 1, it means that any MIDI substream starts AMDTP streams in domain. Usage of the value can resolve the above issue. This commit replaces the check with the substream count and the value for the size of PCM period. Dice hardware has a quirk called as 'Dual Wire'. For a case of higher sampling transmission frequency, this commit performs calculations between the number of PCM frames and the number of events in AMDTP stream. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20191007110532.30270-14-o-takashi@sakamocchi.jp Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-10-17ALSA: oxfw: use the same size of period for PCM substream in AMDTP streamsTakashi Sakamoto1-11/+28
In current implementation, when opening a PCM substream, it's needed to check whether the opposite PCM substream runs. This is to assign effectual constraints (e.g. sampling rate) to opened PCM substream. The number of PCM substreams and MIDI substreams on AMDTP streams in domain is recorded in own structure. Usage of this count is an alternative of the above check. This is better because the count is incremented in pcm.hw_params earlier than pcm.trigger. This idea has one issue because it's incremented for MIDI substreams as well. In current implementation, for a case that any MIDI substream run and a PCM substream is going to start, PCM application to start the PCM substream can decide hardware parameters by restart packet streaming. Just checking the substream count can brings regression. Now AMDTP domain structure has a member for the size of PCM period in PCM substream which starts AMDTP streams in domain. When the value has zero and the substream count is greater than 1, it means that any MIDI substream starts AMDTP streams in domain. Usage of the value can resolve the above issue. This commit replaces the check with the substream count and the value for the size of PCM period. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20191007110532.30270-13-o-takashi@sakamocchi.jp Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-10-17ALSA: fireworks: use the same size of period for PCM substream in AMDTP streamsTakashi Sakamoto1-11/+28
In current implementation, when opening a PCM substream, it's needed to check whether the opposite PCM substream runs. This is to assign effectual constraints (e.g. sampling rate) to opened PCM substream. The number of PCM substreams and MIDI substreams on AMDTP streams in domain is recorded in own structure. Usage of this count is an alternative of the above check. This is better because the count is incremented in pcm.hw_params earlier than pcm.trigger. This idea has one issue because it's incremented for MIDI substreams as well. In current implementation, for a case that any MIDI substream run and a PCM substream is going to start, PCM application to start the PCM substream can decide hardware parameters by restart packet streaming. Just checking the substream count can brings regression. Now AMDTP domain structure has a member for the size of PCM period in PCM substream which starts AMDTP streams in domain. When the value has zero and the substream count is greater than 1, it means that any MIDI substream starts AMDTP streams in domain. Usage of the value can resolve the above issue. This commit replaces the check with the substream count and the value for the size of PCM period. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20191007110532.30270-12-o-takashi@sakamocchi.jp Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-10-17ALSA: bebob: use the same size of period for PCM substream in AMDTP streamsTakashi Sakamoto1-12/+27
In current implementation, when opening a PCM substream, it's needed to check whether the opposite PCM substream runs. This is to assign effectual constraints (e.g. sampling rate) to opened PCM substream. The number of PCM substreams and MIDI substreams on AMDTP streams in domain is recorded in own structure. Usage of this count is an alternative of the above check. This is better because the count is incremented in pcm.hw_params earlier than pcm.trigger. This idea has one issue because it's incremented for MIDI substreams as well. In current implementation, for a case that any MIDI substream run and a PCM substream is going to start, PCM application to start the PCM substream can decide hardware parameters by restart packet streaming. Just checking the substream count can brings regression. Now AMDTP domain structure has a member for the size of PCM period in PCM substream which starts AMDTP streams in domain. When the value has zero and the substream count is greater than 1, it means that any MIDI substream starts AMDTP streams in domain. Usage of the value can resolve the above issue. This commit replaces the check with the substream count and the value for the size of PCM period. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20191007110532.30270-11-o-takashi@sakamocchi.jp Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-10-17ALSA: fireface: register the size of PCM period to AMDTP domainTakashi Sakamoto3-3/+14
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-10-o-takashi@sakamocchi.jp Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-10-17ALSA: firewire-motu: register the size of PCM period to AMDTP domainTakashi Sakamoto4-4/+16
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-9-o-takashi@sakamocchi.jp Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-10-17ALSA: firewire-tascam: register the size of PCM period to AMDTP domainTakashi Sakamoto3-3/+15
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-8-o-takashi@sakamocchi.jp Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-10-17ALSA: firewire-digi00x: register the size of PCM period to AMDTP domainTakashi Sakamoto4-4/+16
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-7-o-takashi@sakamocchi.jp Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-10-17ALSA: dice: register the size of PCM period to AMDTP domainTakashi Sakamoto4-4/+16
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-6-o-takashi@sakamocchi.jp Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-10-17ALSA: oxfw: register the size of PCM period to AMDTP domainTakashi Sakamoto4-6/+19
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-5-o-takashi@sakamocchi.jp Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-10-17ALSA: fireworks: register the size of PCM period to AMDTP domainTakashi Sakamoto4-4/+16
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-4-o-takashi@sakamocchi.jp Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-10-17ALSA: bebob: register the size of PCM period to AMDTP domainTakashi Sakamoto4-4/+16
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>
2019-10-17ALSA: firewire-lib: add a member into AMDTP domain for events per periodTakashi Sakamoto2-0/+14
In IEC 61883-6, it's called as 'event' what has presentation time represented by timestamp in CIP header. Although the ratio of the number of event against the number of data block is different depending on event data type represented by the specific field in CIP header, it's just one in the most cases supported by ALSA IEC 61883-1/6 engine. In 1394 OHCI specification, applications can schedule hardware IRQ by configuring descriptor with IRQ flag for packet against each isochronous cycle. For future commit, I use the hardware IRQ for isoc IT context to acknowledge the elapse of PCM period for both playback/capture directions on AMDTP streams in the same domain. This commit is a preparation for the above idea. This commit adds a member into AMDTP domain structure to record the number of PCM frames. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20191007110532.30270-2-o-takashi@sakamocchi.jp Signed-off-by: Takashi Iwai <tiwai@suse.de>
generated by cgit v1.2.3 (git 2.39.1) at 2024-11-02 12:40:36 +0000