ALSA: oxfw: add Mackie Onyx Satellite quirk to inform wrong value in 'dbs' field in tx CIP header
Mackie Onyx Satellite has two usage; standalone and with base station. These two modes has different stream formats. In standalone mode, rx data block includes 2 Multi Bit Linear Audio (MBLA) data channels and tx data block includes 2. With base station, they're 6 and 2. Although, with base station, the actual tx packet include wrong value in 'dbs' field in its CIP header. This quirk causes packet streaming layer to detect packet discontinuity and to stop PCM substream. This is a response of 'single' subfunction 'extended stream format information' command in AV/C Stream Format Information Specification 1.1. It means that a data block in tx packets includes 2 MBLA data channels. $ ./firewire-request /dev/fw1 fcp 0x01ffbfc001000000ffffffff response: 000: 0c ff bf c0 01 00 00 00 ff 00 90 40 03 02 01 02 response: 010: 06 Current OXFW driver parses the response and detects stream formats correctly. $ cat /proc/asound/card1/firewire/formation ... Output Stream from device: Rate PCM MIDI * 48000 2 0 44100 2 0 88200 2 0 96000 2 0 On the other hand, in actual tx CIP, the 'dbs' field has 6. But the number of quadlets in CIP payload is not multiple of 6. Seeing the subtraction of two successive payload quadlets, it should be multiple of 2. payload CIP CIP quadlets header0 header1 24 00060052 9002ffff 24 0006005e 9002ffff 26 0006006a 9002ffff 24 00060077 9002ffff 24 00060083 9002ffff 26 0006008f 9002ffff 24 0006009c 9002ffff 24 000600a8 9002ffff 26 000600b4 9002ffff 24 000600c1 9002ffff This commit adds support for this quirk to OXFW driver, by using CIP_WRONG_DBS flag. When this flag is set, packet streaming layer uses the value of its 'data_block_quadlets' member instead of the value in CIP header. This value is already set by OXFW driver and no discontinuity is detected. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
Please register or sign in to comment