10 Dec, 2015

4 commits

  • commit a91e627e3f0ed820b11d86cdc04df38f65f33a70 upstream.

    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
    Signed-off-by: Takashi Iwai
    Signed-off-by: Greg Kroah-Hartman

    Clemens Ladisch
     
  • commit 1ca8b201309d842642f221db7f02f71c0af5be2d upstream.

    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
    Signed-off-by: Takashi Iwai
    Signed-off-by: Greg Kroah-Hartman

    Clemens Ladisch
     
  • commit 98d362becb6621bebdda7ed0eac7ad7ec6c37898 upstream.

    Signed-off-by: Clemens Ladisch
    Signed-off-by: Takashi Iwai
    Signed-off-by: Greg Kroah-Hartman

    Clemens Ladisch
     
  • commit 16771c7c704769c5f3d70c024630b6e5b3eafa67 upstream.

    This patch adds native DSD support for the Aune X1S 32BIT/384 DSD DAC

    Signed-off-by: Jurgen Kramer
    Signed-off-by: Takashi Iwai
    Signed-off-by: Greg Kroah-Hartman

    Jurgen Kramer
     

30 Sep, 2015

1 commit


14 Sep, 2015

2 commits

  • commit 9544f8b6e2ee9ed02d2322ff018837b185f51d45 upstream.

    This patch adds native DSD support for the Gustard DAC-X20U.

    Signed-off-by: Jurgen Kramer
    Signed-off-by: Takashi Iwai
    Signed-off-by: Greg Kroah-Hartman

    Jurgen Kramer
     
  • commit 9003ebb13f61e8c78a641e0dda7775183ada0625 upstream.

    The fix for deadlock in PM in commit [1ee23fe07ee8: ALSA: usb-audio:
    Fix deadlocks at resuming] introduced a new check of in_pm flag.
    However, the brainless patch author evaluated it in a wrong way
    (logical AND instead of logical OR), thus usb_autopm_get_interface()
    is wrongly called at probing, leading to unbalance of runtime PM
    refcount.

    This patch fixes it by correcting the logic.

    Reported-by: Hans Yang
    Fixes: 1ee23fe07ee8 ('ALSA: usb-audio: Fix deadlocks at resuming')
    Signed-off-by: Takashi Iwai
    Signed-off-by: Greg Kroah-Hartman

    Takashi Iwai
     

11 Aug, 2015

3 commits

  • commit 2d1cb7f658fb9c3ba8f9dab8aca297d4dfdec835 upstream.

    Add the correct dB ranges of Bose Companion 5 and Drangonfly DAC 1.2.

    Signed-off-by: Yao-Wen Mao
    Signed-off-by: Takashi Iwai
    Signed-off-by: Greg Kroah-Hartman

    Yao-Wen Mao
     
  • commit 4d0e677523a999e1dec28e55cc314c47ba09ca12 upstream.

    When a monitor stream is active, the next PCM stream access results in
    EBUSY error because of the check in line6_stream_start(). Fix this by
    just skipping the submission of pending URBs when the stream is
    already running instead.

    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=101431
    Signed-off-by: Takashi Iwai
    Signed-off-by: Greg Kroah-Hartman

    Takashi Iwai
     
  • commit 0689a86ae814f39af94a9736a0a5426dd82eb107 upstream.

    The Steinberg MI2 and MI4 interfaces are compatible with the USB class
    audio spec, but the MIDI part of the devices is reported as a vendor
    specific interface.

    This patch adds entries to quirks-table.h to recognize the MIDI
    endpoints. Audio functionality was already working and is unaffected by
    this change.

    Signed-off-by: Dominic Sacré
    Signed-off-by: Albert Huitsing
    Acked-by: Clemens Ladisch
    Signed-off-by: Takashi Iwai
    Signed-off-by: Greg Kroah-Hartman

    Dominic Sacré
     

08 Jun, 2015

1 commit


03 Jun, 2015

2 commits

  • The driver worked around an error in the MAYA44 USB(+)'s mixer unit
    descriptor by aborting before parsing the missing field. However,
    aborting parsing too early prevented parsing of the other units
    connected to this unit, so the capture mixer controls would be missing.

    Fix this by moving the check for this descriptor error after the parsing
    of the unit's input pins.

    Reported-by: nightmixes
    Tested-by: nightmixes
    Signed-off-by: Clemens Ladisch
    Cc:
    Signed-off-by: Takashi Iwai

    Clemens Ladisch
     
  • Add mixer control names for the ESI Maya44 USB+ (which appears to be
    identical width the AudioTrak Maya44 USB).

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

    Clemens Ladisch
     

30 May, 2015

1 commit

  • This quirk allows us to avoid the noisy:

    current rate 0 is different from the runtime rate

    message every time playback starts. While USB DAC in the RR2150
    supports reading the sample rate, it never returns a sample rate
    other than zero in my observation with common sample rates.

    Signed-off-by: Eric Wong
    Cc: Joe Turner
    Cc:
    Signed-off-by: Takashi Iwai

    Eric Wong
     

29 May, 2015

1 commit


24 May, 2015

1 commit


19 May, 2015

1 commit


21 Apr, 2015

1 commit

  • Roland SC-D70 reports its device class as vendor specific class and
    the quirk QUIRK_AUDIO_FIXED_ENDPOINT was used for audio output.

    In the quirks table the sampling rate was hard-coded to 44100 Hz
    and therefore not worked when the sound module was in 48000 Hz mode.

    In this change the quirk is changed to QUIRK_AUDIO_STANDARD_INTERFACE
    but as the sound module reports incorrect bSubframeSize in its
    descriptors, additional change is made in format.c to detect it and
    to override it (which uses the existing code for Edirol SD-90).

    Tested both when the sound module was in 44100 Hz mode and 48000 Hz
    mode and both audio input and output. MIDI related part of the driver
    is not touched.

    Signed-off-by: Takamichi Horikawa
    Signed-off-by: Takashi Iwai

    Takamichi Horikawa
     

13 Apr, 2015

1 commit


12 Apr, 2015

1 commit

  • Adds Microsoft LifeCam Cinema USB ID to the snd_usb_get_sample_rate_quirk list as the Lifecam Cinema does not appear to support getting the sample rate.

    Fixes the issue where the LifeCam Cinema would wait for USB timeout and log the message "cannot get freq at ep 0x82" when accessed.

    Addresses bug report https://bugzilla.kernel.org/show_bug.cgi?id=95961.

    Signed-off-by: Adam Honse
    Cc:
    Signed-off-by: Takashi Iwai

    Adam Honse
     

09 Apr, 2015

1 commit


08 Apr, 2015

1 commit


04 Apr, 2015

1 commit

  • Adding this quirk allows us to avoid the noisy
    "cannot get freq at ep 0x1" message in dmesg output every time
    playback starts.

    This ought to affect other Benchmark DAC1 variations using the same
    "Microchip Technology, Inc." chip as well, but I have only tested
    with the "Pre" variant.

    Signed-off-by: Eric Wong
    Cc: Joe Turner
    Signed-off-by: Takashi Iwai

    Eric Wong
     

16 Mar, 2015

1 commit


12 Mar, 2015

1 commit

  • The device complies to the UAC1 standard but hides that fact with
    proprietary descriptors. The autodetect quirk for Roland devices
    catches the audio interface but misses the MIDI part, so a specific
    quirk is needed.

    Signed-off-by: Daniel Mack
    Reported-by: Rafa Lafuente
    Tested-by: Raphaël Doursenaud
    Cc:
    Signed-off-by: Takashi Iwai

    Daniel Mack
     

09 Mar, 2015

1 commit


05 Mar, 2015

1 commit


04 Mar, 2015

1 commit


18 Feb, 2015

1 commit

  • Fix problem where playback of Denon DA-300USB DAC sometimes does not
    start and leads to error messages like "clock source 41 is not valid,
    cannot use".

    Solution: Treat this device the same as other Denon/Marantz devices in
    sound/usb/quirks.c.

    Tested with both PCM and DSD formats.

    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=93261
    Signed-off-by: Frank C Guenther
    Cc:
    Signed-off-by: Takashi Iwai

    Frank C Guenther
     

17 Feb, 2015

1 commit

  • Adds a quirk to disable the check that the sample rate has been set correctly, as the Lifecam does not support getting the sample rate.

    This means that we don't need to wait for the USB timeout when attempting to get the sample rate. Waiting for the timeout causes problems in some applications, which give up on the device acquisition process before it has had time to complete, resulting in no sound.

    [minor tidy up by tiwai]

    Signed-off-by: Joe Turner
    Signed-off-by: Takashi Iwai

    Joe Turner
     

12 Feb, 2015

1 commit


11 Feb, 2015

5 commits


09 Feb, 2015

1 commit

  • The first URBs are submitted during the prepare stage. When .trigger is
    called, the ALSA core saves a trigger tstamp that doesn't correspond to
    the actual time when the samples are submitted. The trigger_tstamp is
    now updated when the first data are submitted to avoid any time offsets.

    A usb-specific trigger_tstamp_pending_update flag is used for now,
    at some point the flag would need to move to the ALSA core, USB
    is not the only interface where silent block transfers are programmed
    as part of the prepare stage, with actual data enabled when .trigger
    is called.

    Signed-off-by: Pierre-Louis Bossart
    Signed-off-by: Takashi Iwai

    Pierre-Louis Bossart
     

08 Feb, 2015

3 commits