Commit Graph

4 Commits

Author SHA1 Message Date
Takashi Sakamoto
86c8dd7f4d ALSA: firewire-digi00x: delayed registration of sound card
When some digi00x units are connected sequentially, userspace
applications are involved at bus-reset state on IEEE 1394 bus. In the
state, any communications can be canceled. Therefore, sound card
registration should be delayed till the bus gets calm.

This commit achieves it.

Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2016-03-31 15:36:20 +02:00
Takashi Sakamoto
b47f525f76 ALSA: firewire-digi00x: add support of asynchronous transaction for outgoing MIDI messages to physical controls
In previous commit, asynchronous transaction for incoming MIDI messages
from physical controls is supported. The physical controls may be
controlled by receiving MIDI messages at a certain address.

This commit supports asynchronous transaction for this purpose.

Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2015-10-11 18:26:14 +02:00
Takashi Sakamoto
3646a54acd ALSA: firewire-digi00x: add support of asynchronous transaction for incoming MIDI messages from physical controls
Digi 00x series has two types of model; rack and console. The console
models have physical controls. The model can transmit control messages.
These control messages are transferred by asynchronous transactions to
registered address.

This commit supports the asynchronous transaction.

Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2015-10-11 18:26:09 +02:00
Takashi Sakamoto
44b7308871 ALSA: firewire-digi00x: add support for asynchronous messaging
Digi 002/003 family uses asynchronous transaction for messaging.
The address to transmit this message is stored on a certain register.

This commit allocates a range of address on OHCI 1394 host controller
to handle the messaging. As long as I know, the purpose of this message
seems to notify lost of synchronization. While, the meaning of content
of the message is not clear.

Actual examples of this messaging:
 * When clock source is set as internal:
 - 0x00007051
 - 0x00007052
 - 0x00007054
 - 0x00007057
 - 0x00007058
 * When clock source is set as somewhat external:
 - 0x00009000
 - 0x00009010
 - 0x00009020
 - 0x00009021
 - 0x00009022

The lost often occurs when using internal clock source. In this case,
users hear sounds with quite short gap every several minutes. In fact,
the lost is recovered temporarily.

When using with external clock source, the lost seems not to occur. The
mechanism is not clear yet.

Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2015-09-30 15:37:55 +02:00