summaryrefslogtreecommitdiff
path: root/include
diff options
context:
space:
mode:
authorTakashi Sakamoto <o-takashi@sakamocchi.jp>2015-06-14 12:49:27 +0900
committerTakashi Iwai <tiwai@suse.de>2015-06-15 13:34:13 +0200
commit5a6688127082683f8c343da7d326dc22e45f4e4b (patch)
tree22bc08802000c9c0507136fe26ba5b2bfee1bee8 /include
parent88f1236bfa9586ca458b67abde8ce91665bba079 (diff)
ALSA: bebob: improve signal mode detection for clock source
With BeBoB version 3, current ALSA BeBoB driver detects the type of current clock signal source wrongly. This is due to a lack of proper implementation to parse the information. This commit renews the parser. As a result, this driver detects SYT-Match clock signal, thus it can start streams with two modes; SYT-Match mode and the others. SYT-Match mode will be supported in future commits. There's a constrain about detected internal/external clock source. When detecting external clock source, this driver allows userspace applications to use current sampling rate only. This is due to consider abour synchronization to external clock sources such as S/PDIF, ADAT or word-clock. According to several information from some devices, I guesss that the internal clock of most devices synchronize to IEEE 1394 cycle start packet. In this case, by a usual way, it's detect as 'Sync type of output Music Sub-Unit' connected to 'Sync type of PCR output Unit (oPCR)', and this driver judges it as internal clock. Therefore, userspace applications is allowed to request arbitrary supported sampling rates. On the other hand, several devices based on BeBoB version 3 have additional internal clock. In this case, by a usual way, it's detect as 'Sync/Additional type of External input Unit'. Unfortunately, there's no way to distinguish this sync type from the other external clock sources such as word-clock. In this case, this driver handles it as external and userspace applications is forced to use current sampling rate. I note that when the source of clock is detected as 'Isochronous stream type of input PCR[0]', it's under 'SYT-Match' mode. In this mode, the synchronization clock is generated according to SYT-series in received packets. In this case, this driver generates the series by myself. I experienced this mode often make the device silent suddenly during playbacking. This means that the mode is easy to lost synchronization. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
Diffstat (limited to 'include')
0 files changed, 0 insertions, 0 deletions