This patch is the result of a lot of trial and error, since there are no specs
available for the device.

Full duplex support is provided, i.e. playback and recording in stereo.
The format is hardcoded at 48000Hz @ 24 bit, which is the maximum that the
device supports.  Also, MIDI in and MIDI out both work.

Users will notice that the S/PDIF light also flashes when playback or recording
is active.  I believe this means that S/PDIF input/output is simultaneously
activated with the analogue i/o during use.
But this particular functionality remains untested.

Note that this particular version of the patch is so far untested on the
physical hardware because I have not compiled a full kernel with the changes.
However, extensive testing has been done by many users of the hardware
who believe other versions of my patch have worked since circa 2009.

[Modified to make a function static by tiwai]
Signed-off-by: NDamien Zammit <damien@zamaudio.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

As Joe Cooper <swelljoe@gmail.com> reported, "On most HP Envy laptops
the snd-usb-audio module causes the system to become unresponsive and
Gnome Shell 3 to crash.".
See also:
 http://mailman.alsa-project.org/pipermail/alsa-devel/2012-December/057729.html

Add a quirk to ignore this device (for now) to solve the instability
issue and allow other USB audio devices to be used.
Reported-by: NJoe Cooper <swelljoe@gmail.com>
Tested-by: NIsaac Smith <hunternet93@gmail.com>
Signed-off-by: NEldad Zack <eldad@fogrefinery.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The only required change is to extend the existing Xonar U1
mixer quirks to the U3, which seems to be controlled the same
way.
Signed-off-by: NDenis Washington <denisw@online.de>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The patch below prevents the 6fire usb driver going into panic state
when stopping playing. On some systems the urb in handler
(usb6fire_pcm_in_urb_handler) is being called while urbs are being
killed off, this causes the driver to set panic state and can result in
the kernel warning 'URB %p submitted while active'.
Signed-off-by: NJurgen Kramer <gtmkramer@xs4all.nl>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

CONFIG_HOTPLUG is going away as an option.  As result the __dev*
markings will be going away.

Remove use of __devinit, __devexit_p, __devinitdata, __devinitconst,
and __devexit.
Signed-off-by: NBill Pemberton <wfp5p@virginia.edu>
Acked-by: NDaniel Mack <zonque@gmail.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

CONFIG_HOTPLUG is going away as an option.  As result the __dev*
markings will be going away.

Remove use of __devinit, __devexit_p, __devinitdata, __devinitconst,
and __devexit.
Signed-off-by: NBill Pemberton <wfp5p@virginia.edu>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Commit 947d2996 , "ALSA: snd-usb:
properly initialize the sync endpoint", while correcting the
initialization of the sync endpoint when opening just the data
endpoint, prevents devices that has a sync endpoint, with a channel
number different than that of the data endpoint, from functioning.
Due to a different channel and period bytes count, attempting to
initialize the sync endpoint will fail at the usb host driver.
For example, when using xhci:

 cannot submit urb 0, error -90: internal error

With this patch, if a sync endpoint has multiple audioformats, a
matching audioformat is preferred. An audioformat must be found
with at least one channel and support the requested sample rate
and PCM format, otherwise the stream will not be opened.

If the number of channels differ between the selected audioformat
and the requested format, adjust the period bytes count accordingly.
It is safe to perform the calculation on the basis of the channel
count, since the requested PCM audio format and the rate must be
supported by the selected audioformat.

Cc: Jeffrey Barish <jeff_barish@earthlink.net>
Cc: Daniel Mack <zonque@gmail.com>
Signed-off-by: NEldad Zack <eldad@fogrefinery.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The commit [88a8516a: ALSA: usbaudio: implement USB autosuspend] added
the support of autopm for USB MIDI output, but it didn't take the MIDI
input into account.

This patch adds the following for fixing the autopm:
- Manage the URB start at the first MIDI input stream open, instead of
  the time of instance creation
- Move autopm code to the common substream_open()
- Make snd_usbmidi_input_start/_stop() more robust and add the running
  state check
Reviewd-by: NClemens Ladisch <clemens@ladisch.de>
Tested-by: NClemens Ladisch <clemens@ladisch.de>
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Add a similar protection against the disconnection race and the
invalid use of usb instance after disconnection, as well as we've done
for the USB audio PCM.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=51201Reviewd-by: NClemens Ladisch <clemens@ladisch.de>
Tested-by: NClemens Ladisch <clemens@ladisch.de>
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

A lot of headsets/headphones have a "Speaker" mixer control. This confuses
PulseAudio to think it is a speaker instead of a headphone/headset.
Therfore, we rename it to "Headphone".

We determine if something is a headphone similar to how udev determines
form factor (see 78-sound-card.rules).

BugLink: https://bugs.launchpad.net/bugs/1082357Signed-off-by: NDavid Henningsson <david.henningsson@canonical.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The playback endpoint uses implicit feedback mode, similar
to the M-Audio FTU. Like with the FTU, we need to associate
the sync pipe ourselves.
Signed-off-by: NEldad Zack <eldad@fogrefinery.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Add a mixer quirks for the M-Audio Fast Track C400
and create the following:

* Volume controls
* Effect Type (reusing FTU controls)
* Effect Volume
* Effect Send/Return
* Effect Program
* Effect Feedback
Signed-off-by: NEldad Zack <eldad@fogrefinery.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Add ranges for various Fast Track C400 controls, as observed
while using the vendor's mixer control software (res values
are an estimation).
Signed-off-by: NEldad Zack <eldad@fogrefinery.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Adds a quirks table for the M-Audio Fast Track C400.
Thanks to Clemens Ladisch <clemens@ladisch.de> for pointing out that
the table must be sorted.

Based on the following patch from the alsa-devel list:
http://mailman.alsa-project.org/pipermail/alsa-devel/2012-May/051676.html

See also:
http://mailman.alsa-project.org/pipermail/alsa-devel/2012-April/051219.htmlSigned-off-by: NEldad Zack <eldad@fogrefinery.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Adds the unit ID and the control as parameters to the creation of the
effect unit control for the M-Audio Fast Track Ultra. This allows the
code to be shared with other devices that use different unit ID and
control, such as the M-Audio Fast Track C400.
Signed-off-by: NEldad Zack <eldad@fogrefinery.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Current code mishandles the case where the device is a UAC2
and the bDescriptorSubtype is a UAC2 Effect Unit (0x07).
It tries to parse it as a Processing Unit (which is similar to two
other UAC1 units with overlapping subtypes), but since the structure
is different (See: 4.7.2.10, 4.7.2.11 in UAC2 standard), the parsing
is done incorrectly and prevents the device from initializing.
For now, just ignore the unit.
Signed-off-by: NEldad Zack <eldad@fogrefinery.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Currently, channel IDs exceeding 31 (0x1f) cannot be used.
The channel ID is derived from the cmask. Extending cmask
to a 64-bit type would only allow it to go up to 63 (0x3f).
Some devices have channel IDs exceeding that as well.
To address that, add an offset to the mixer element which
is then accounted for in the UAC set/get functions.
Signed-off-by: NEldad Zack <eldad@fogrefinery.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

For implicit feedback endpoints, the number of bytes for each packet
is matched by the corresponding synchronizing endpoint.
The size is calculated by taking the actual size and dividing it by
the stride - currently by the endpoint's stride, but we should use the
synchronization source's stride.
This is evident when the number of channels differ between the
synchronization source and the implicitly fed-back endpoint, as with
M-Audio Fast Track C400 - the synchronization source (capture)
has 4 channels, while the implicit feedback mode endpoint has 6.
Signed-off-by: NEldad Zack <eldad@fogrefinery.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

In this context, 0x01 is USB_ENDPOINT_XFER_ISOC.
Signed-off-by: NEldad Zack <eldad@fogrefinery.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Add the support for channel maps of the PCM streams on USB audio
devices.  The channel map information is already found in
ChannelConfig descriptor entries, which haven't been referred until
now.

Each chmap entry is added to audioformat list entry and copied to TLV
dynamically instead of creating a whole chmap array.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

When a playback stream is paused, the stream isn't actually stopped,
thus we still need to take care of the in-flight data amount for the
delay calculation.  Otherwise the value of subs->last_delay is no
longer reliable and can give a bogus value after resuming from pause.
This will result in "delay: estimated XX, actual YY" error messages.

Also, during pause after all in flight data are processed
(i.e. last_delay = 0), we don't have to calculate the actual delay
from the current frame.  Give a short path in such a case.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

It doesn't make sense to calculate the delay for capture streams in
the current implementation.  It's always zero, so we should skip the
computation in snd_usb_pcm_pointer() in the case of capture.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Jeffrey Barish reported an obvious bug in the pcm part of the usb-audio
driver which causes the code to not initialize the sync endpoint from
configure_endpoint().
Reported-by: NJeffrey Barish <jeff_barish@earthlink.net>
Signed-off-by: NDaniel Mack <zonque@gmail.com>
Cc: stable@kernel.org [3.5+]
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

PCM hw_free and close should wait until all the pending stop
operations have been finished.  Basically only PCM trigger callback
should use non-wait calls.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

As we are stopping the endpoints asynchronously now, it's better to
trigger the stop of both data and sync endpoints and wait for pending
stopping operations, instead of the sequential trigger-and-wait
procedure.

So the wait argument in snd_usb_endpoint_stop() is dropped, and it's
expected that the caller synchronizes explicitly by calling
snd_usb_endpoint_sync_pending_stop().  (Actually there is only one
place calling this, so it was safe to change.)
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

For further code simplification, drop the conditional call for
usb_kill_urb() with can_wait argument in deactivate_urbs(), and use
only usb_unlink_urb() and wait_clear_urbs() pairs.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Reduce the redundant arguments for snd_usb_endpoint_start() and
snd_usb_endpoint_stop().  Also replaced from int to bool.

No functional changes by this commit.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The async unlink behavior has been working over years.  The option was
provided only as a workaround for 2.4.x kernel.  Let's get rid of it.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Also, silences the following smatch warning:
sound/usb/format.c:170 parse_audio_format_rates_v1() warn:
returning -1 instead of -ENOMEM is sloppy
Signed-off-by: NSachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

'rt' was dereferenced before the NULL check.
Moved the code after the check.
Signed-off-by: NSachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Commit 88a8516a (ALSA: usbaudio: implement USB autosuspend) added
autosuspend code to all files making up the snd-usb-audio driver.
However, midi.c is part of snd-usb-lib and is also used by other
drivers, not all of which support autosuspend.  Thus, calls to
usb_autopm_get_interface() could fail, and this unexpected error would
result in the MIDI output being completely unusable.

Make it work by ignoring the error that is expected with drivers that do
not support autosuspend.
Reported-by: NColin Fletcher <colin.m.fletcher@googlemail.com>
Reported-by: NDevin Venable <venable.devin@gmail.com>
Reported-by: NDr Nick Bailey <nicholas.bailey@glasgow.ac.uk>
Reported-by: NJannis Achstetter <jannis_achstetter@web.de>
Reported-by: NRui Nuno Capela <rncbc@rncbc.org>
Cc: Oliver Neukum <oliver@neukum.org>
Cc: 2.6.39+ <stable@vger.kernel.org>
Signed-off-by: NClemens Ladisch <clemens@ladisch.de>

Use bitmap_weight to count the total number of bits set in bitmap.
Signed-off-by: NJoe Perches <joe@perches.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The recent change for USB-audio disconnection race fixes introduced a
mutex deadlock again.  There is a circular dependency between
chip->shutdown_rwsem and pcm->open_mutex, depicted like below, when a
device is opened during the disconnection operation:

A. snd_usb_audio_disconnect() ->
     card.c::register_mutex ->
       chip->shutdown_rwsem (write) ->
         snd_card_disconnect() ->
           pcm.c::register_mutex ->
             pcm->open_mutex

B. snd_pcm_open() ->
     pcm->open_mutex ->
       snd_usb_pcm_open() ->
         chip->shutdown_rwsem (read)

Since the chip->shutdown_rwsem protection in the case A is required
only for turning on the chip->shutdown flag and it doesn't have to be
taken for the whole operation, we can reduce its window in
snd_usb_audio_disconnect().
Reported-by: NJiri Slaby <jslaby@suse.cz>
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Probing this device currently fails in snd_usb_audio_probe() because
the call to snd_usb_create_mixer() fails.  This is due to unknown or
non-standard interface descriptor subtypes in parse_audio_unit():

  usbaudio: unit 51: unexpected type 0x09
  snd-usb-audio: probe of 1-8:1.0 failed with error -5

Some people are working around this by recompiling usb-audio with the
call to snd_usb_create_mixer() commented out.  It would be nice to
avoid that.

While the best idea would be to look into the mixer creation failure,
a reasonable short-term solution is to use quirks to only probe the
trouble-free interfaces.  This allows audio and MIDI interfaces to be
used without any obvious issues.

Interface 0 is the main one to ignore.  It contains lots of
control-fu, including the unexpected interface descriptor subtypes.
Interface 5 is for firmware updates and I'm not sure how to get
support for this.  Interface 3 is some sort of control interface that
I don't understand:

    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        3
      bAlternateSetting       0
      bNumEndpoints           0
      bInterfaceClass         1 Audio
      bInterfaceSubClass      1 Control Device
      bInterfaceProtocol      0
      iInterface              0
      AudioControl Interface Descriptor:
        bLength                 9
        bDescriptorType        36
        bDescriptorSubtype      1 (HEADER)
        bcdADC               1.00
        wTotalLength            9
        bInCollection           1
        baInterfaceNr( 0)       1
Signed-off-by: NMartin Schwenke <martin@meltin.net>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

There are bug reports of a crash with USB-audio devices when PCM
prepare is performed immediately after the stream is stopped via
trigger callback.  It turned out that the problem is that we don't
wait until all URBs are killed.

This patch adds a new function to synchronize the pending stop
operation on an endpoint, and calls in the prepare callback for
avoiding the crash above.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=49181Reported-and-tested-by: NArtem S. Tashkinov <t.artem@lycos.com>
Cc: <stable@vger.kernel.org> [v3.6]
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Similar like the previous commit, cover with chip->shutdown_rwsem
and chip->shutdown checks.
Reported-by: NMatthieu CASTET <matthieu.castet@parrot.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Replace mutex with rwsem for codec->shutdown protection so that
concurrent accesses are allowed.

Also add the protection to snd_usb_autosuspend() and
snd_usb_autoresume(), too.
Reported-by: NMatthieu CASTET <matthieu.castet@parrot.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Close some races at disconnection of a USB audio device by adding the
chip->shutdown_mutex and chip->shutdown check at appropriate places.

The spots to put bandaids are:
- PCM prepare, hw_params and hw_free
- where the usb device is accessed for communication or get speed, in
 mixer.c and others; the device speed is now cached in subs->speed
 instead of accessing to chip->dev

The accesses in PCM open and close don't need the mutex protection
because these are already handled in the core PCM disconnection code.

The autosuspend/autoresume codes are still uncovered by this patch
because of possible mutex deadlocks.  They'll be covered by the
upcoming change to rwsem.

Also the mixer codes are untouched, too.  These will be fixed in
another patch, too.
Reported-by: NMatthieu CASTET <matthieu.castet@parrot.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

This config item has not carried much meaning for a while now and is
almost always enabled by default. As agreed during the Linux kernel
summit, remove it.
Signed-off-by: NKees Cook <keescook@chromium.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The Reloop Audio needs a fixed endpoint quirk with S24_3LE format and
UAC_EP_CS_ATTR_SAMPLE_RATE attribute.
Signed-off-by: NDidier Villevalois <ptitjes@free.fr>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>