BMC/Intel-BMC/linux.git/sound/usb, branch v4.4

ALSA: usb-audio: Add sample rate inquiry quirk for AudioQuest DragonFly

2015-12-14T09:13:17+00:00

Avoid getting sample rate on AudioQuest DragonFly as it is unsupported and causes noisy "cannot get freq at ep 0x1" messages when playback starts. Signed-off-by: Anssi Hannula Cc: Signed-off-by: Takashi Iwai

ALSA: usb-audio: Add a more accurate volume quirk for AudioQuest DragonFly

2015-12-14T09:13:17+00:00

AudioQuest DragonFly DAC reports a volume control range of 0..50 (0x0000..0x0032) which in USB Audio means a range of 0 .. 0.2dB, which is obviously incorrect and would cause software using the dB information in e.g. volume sliders to have a massive volume difference in 100..102% range. Commit 2d1cb7f658fb ("ALSA: usb-audio: add dB range mapping for some devices") added a dB range mapping for it with range 0..50 dB. However, the actual volume mapping seems to be neither linear volume nor linear dB scale, but instead quite close to the cubic mapping e.g. alsamixer uses, with a range of approx. -53...0 dB. Replace the previous quirk with a custom dB mapping based on some basic output measurements, using a 10-item range TLV (which will still fit in alsa-lib MAX_TLV_RANGE_SIZE). Tested on AudioQuest DragonFly HW v1.2. The quirk is only applied if the range is 0..50, so if this gets fixed/changed in later HW revisions it will no longer be applied. v2: incorporated Takashi Iwai's suggestion for the quirk application method Signed-off-by: Anssi Hannula Cc: Signed-off-by: Takashi Iwai

ALSA: usb-audio: work around CH345 input SysEx corruption

2015-11-16T07:59:29+00:00

One of the many faults of the QinHeng CH345 USB MIDI interface chip is that it does not handle received SysEx messages correctly -- every second event packet has a wrong code index number, which is the one from the last seen message, instead of 4. For example, the two messages "FE F0 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E F7" result in the following event packets: correct: CH345: 0F FE 00 00 0F FE 00 00 04 F0 01 02 04 F0 01 02 04 03 04 05 0F 03 04 05 04 06 07 08 04 06 07 08 04 09 0A 0B 0F 09 0A 0B 04 0C 0D 0E 04 0C 0D 0E 05 F7 00 00 05 F7 00 00 A class-compliant driver must interpret an event packet with CIN 15 as having a single data byte, so the other two bytes would be ignored. The message received by the host would then be missing two bytes out of six; in this example, "F0 01 02 03 06 07 08 09 0C 0D 0E F7". These corrupted SysEx event packages contain only data bytes, while the CH345 uses event packets with a correct CIN value only for messages with a status byte, so it is possible to distinguish between these two cases by checking for the presence of this status byte. (Other bugs in the CH345's input handling, such as the corruption resulting from running status, cannot be worked around.) Signed-off-by: Clemens Ladisch Cc: stable@vger.kernel.org Signed-off-by: Takashi Iwai

ALSA: usb-audio: prevent CH345 multiport output SysEx corruption

2015-11-16T07:59:24+00:00

The CH345 USB MIDI chip has two output ports. However, they are multiplexed through one pin, and the number of ports cannot be reduced even for hardware that implements only one connector, so for those devices, data sent to either port ends up on the same hardware output. This becomes a problem when both ports are used at the same time, as longer MIDI commands (such as SysEx messages) are likely to be interrupted by messages from the other port, and thus to get lost. It would not be possible for the driver to detect how many ports the device actually has, except that in practice, _all_ devices built with the CH345 have only one port. So we can just ignore the device's descriptors, and hardcode one output port. Signed-off-by: Clemens Ladisch Cc: stable@vger.kernel.org Signed-off-by: Takashi Iwai

ALSA: usb-audio: add packet size quirk for the Medeli DD305

2015-11-16T07:59:09+00:00

Signed-off-by: Clemens Ladisch Cc: Signed-off-by: Takashi Iwai

ALSA: usb: Add native DSD support for Aune X1S

2015-11-09T13:14:47+00:00

This patch adds native DSD support for the Aune X1S 32BIT/384 DSD DAC Signed-off-by: Jurgen Kramer Cc: Signed-off-by: Takashi Iwai

ALSA: USB-audio: Remove mixer entry from Zoom R16/24 quirk

2015-10-19T10:38:10+00:00

The device has no mixer (and identifies itself as such), so just skip the mixer definition. Signed-off-by: Ricard Wanderlof Signed-off-by: Takashi Iwai

ALSA: USB-audio: Adjust max packet size calculation for tx_length_quirk

2015-10-19T10:38:10+00:00

For the Zoom R16/24 (tx_length_quirk set), when calculating the maximum sample frequency, consideration must be made for the fact that four bytes of the packet contain a length descriptor and consequently must not be counted as part of the audio data. This is corroborated by the wMaxPacketSize for this device, which is 108 bytes according for the USB playback endpoint descriptor. The frame size is 8 bytes (2 channels of 4 bytes each), and the 108 bytes thus work out as 13 * 8 + 4, i.e. corresponding to 13 frames plus the additional 4 byte length descriptor. Signed-off-by: Ricard Wanderlof Signed-off-by: Takashi Iwai

ALSA: USB-audio: Add quirk for Zoom R16/24 playback

2015-10-19T10:38:09+00:00

The Zoom R16/24 have a nonstandard playback format where each isochronous packet contains a length descriptor in the first four bytes. (Curiously, capture data does not contain this and requires no quirk.) The quirk involves adding the extra length descriptor whenever outgoing isochronous packets are generated, both in pcm.c (outgoing audio) and endpoint.c (silent data). In order to make the quirk as unintrusive as possible, for pcm.c:prepare_playback_urb(), the isochronous packet descriptors are initially set up in the same way no matter if the quirk is enabled or not. Once it is time to actually copy the data into the outgoing packet buffer (together with the added length descriptors) the isochronous descriptors are adjusted in order take the increased payload length into account. For endpoint.c:prepare_silent_urb() it makes more sense to modify the actual function, partly because the function is less complex to start with and partly because it is not as time-critical as prepare_playback_urb() (whose bulk is run with interrupts disabled), so the (minute) additional time spent in the non-quirk case is motivated by the simplicity of having a single function for all cases. The quirk is controlled by the new tx_length_quirk member in struct snd_usb_substream and struct snd_usb_audio, which is conveyed to pcm.c and endpoint.c from quirks.c in a similar manner to the txfr_quirk member in the same structs. In contrast to txfr_quirk however, the quirk is enabled directly in quirks.c:create_standard_audio_quirk() by checking the USB ID in that function. Another option would be to introduce a new QUIRK_AUDIO_ZOOM_INTERFACE or somesuch, which would have made the quirk very plain to see in the quirk table, but it was felt that the additional code needed to implement it this way would just make the implementation more complex with no real gain. Tested with a Zoom R16, both by doing capture and playback separately using arecord and aplay (8 channel capture and 2 channel playback, respectively), as well as capture and playback together using Ardour, as well as Audacity and Qtractor together with jackd. The R24 is reportedly compatible with the R16 when used as an audio interface. Both devices share the same USB ID and have the same number of inputs (8) and outputs (2). Therefore "R16/24" is mentioned throughout the patch. Regression tested using an Edirol UA-5 in both class compliant (16-bit) and "advanced" (24 bit, forces the use of quirks) modes. Signed-off-by: Ricard Wanderlof Tested-by: Panu Matilainen Signed-off-by: Takashi Iwai

ALSA: USB-audio: Add offset parameter to copy_to_urb()

2015-10-19T10:38:08+00:00

Preparation for adding Zoom R16/24 quirk. No functional change. Signed-off-by: Ricard Wanderlof Signed-off-by: Takashi Iwai