29 Apr, 2013

1 commit


18 Apr, 2013

3 commits

  • There is quite some confusion around the bit-ordering in DSD samples,
    and no general agreement that defines whether hardware is supposed to
    expect the oldest sample in the MSB or the LSB of a byte.

    ALSA will hence set the rule that on the software API layer, bytes
    always carry the oldest bit in the most significant bit of a byte, and
    the driver has to translate that at runtime in order to match the
    hardware layout.

    This patch adds support for this by adding a boolean flag to the
    audio format struct.

    Signed-off-by: Daniel Mack
    Signed-off-by: Takashi Iwai

    Daniel Mack
     
  • In order to provide a compatibility way for pushing DSD
    samples through ordinary PCM channels, the "DoP open Standard" was
    invented. See http://www.dsd-guide.com for the official document.

    The host is required to stuff DSD marker bytes (0x05, 0xfa,
    alternating) in the MSB of 24 bit wide samples on the bus, in addition
    to the 16 bits of actual DSD sample payload.

    To support this, the hardware and software stride logic in the driver
    has to be tweaked a bit, as we make the userspace believe we're
    operating on 16 bit samples, while we in fact push one more byte per
    channel down to the hardware.

    The DOP runtime information is stored in struct snd_usb_substream, so
    we can keep track of our state across multiple calls to
    prepare_playback_urb_dsd_dop().

    Signed-off-by: Daniel Mack
    Signed-off-by: Takashi Iwai

    Daniel Mack
     
  • For normal PCM transfer, this change has no effect, as the endpoint's
    stride is always frame_bits/8. For DSD DOP streams, however, which is
    added later, the hardware stride differs from the software stride, and
    the endpoint has the correct information in these cases.

    Signed-off-by: Daniel Mack
    Signed-off-by: Takashi Iwai

    Daniel Mack
     

13 Apr, 2013

1 commit

  • When recording at 176.2KHz or 192Khz, the device adds a 32-bit length
    header to the capture packets, which obviously needs to be ignored for
    recording to work properly.

    Userspace expected: L0 L1 L2 R0 R1 R2
    ...but actually got: R2 L0 L1 L2 R0 R1

    Also, the last byte of the length header being interpreted as L0 of
    the first sample caused spikes every 0.5ms, resulting in a loud 16KHz
    tone (about the highest 'B' on a piano) being present throughout
    captures.

    Tested at all sample rates on an E-Mu 0404USB, and tested for
    regressions on a generic USB headset.

    Signed-off-by: Calvin Owens
    Cc:
    Signed-off-by: Takashi Iwai

    Calvin Owens
     

10 Apr, 2013

1 commit


04 Apr, 2013

2 commits


18 Mar, 2013

1 commit


11 Feb, 2013

1 commit

  • Adds quirks and mixer support for the M-Audio Fast Track C600 USB
    audio interface. This device is very similar to the C400 - the C600
    simply has some more inputs and outputs, so the existing C400 support
    is extended to support this device as well.

    Signed-off-by: Matt Gruskin
    Signed-off-by: Takashi Iwai

    Matt Gruskin
     

26 Jan, 2013

1 commit

  • Because currently snd_printd() and snd_printdd() macros are expanded
    to empty when CONFIG_SND_DEBUG=n, a compile warning like below
    appears sometimes, and we had to covert it by ugly ifdefs:
    sound/pci/hda/patch_sigmatel.c: In function ‘stac92hd71bxx_fixup_hp’:
    sound/pci/hda/patch_sigmatel.c:2434:24: warning: unused variable ‘spec’ [-Wunused-variable]

    For "fixing" these issues better, this patch replaces snd_printd() and
    snd_printdd() definitions with empty inline functions instead of
    macros. This should have the same effect but shut up warnings like
    above.

    But since we had already put ifdefs, changing to inline functions
    would trigger compile errors. So, such ifdefs is removed in this
    patch.

    In addition, snd_pci_quirk name field is defined only when
    CONFIG_SND_DEBUG_VERBOSE is set, and the reference to it in
    snd_printdd() argument triggers the build errors, too. For avoiding
    these errors, introduce a new macro snd_pci_quirk_name() that is
    defined no matter how the debug option is set.

    Reported-by: Stratos Karafotis
    Signed-off-by: Takashi Iwai

    Takashi Iwai
     

23 Jan, 2013

1 commit


11 Jan, 2013

1 commit

  • The commit [0d9741c0: ALSA: usb-audio: sync ep init fix for
    audioformat mismatch] introduced the correction of parameters to be
    set for sync EP. But since the new code assumes that the sync EP is
    always paired with the data EP of another direction, it triggers Oops
    when a device only with a single direction is used.

    This patch adds a proper check of sync EP type and the presence of the
    paired substream for avoiding the crash.

    Reported-and-tested-by: Jens Axboe
    Signed-off-by: Takashi Iwai

    Takashi Iwai
     

24 Dec, 2012

1 commit


04 Dec, 2012

1 commit

  • Commit 947d299686aa9cc8aecf749d54e8475c6e498956 , "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
    Cc: Daniel Mack
    Signed-off-by: Eldad Zack
    Signed-off-by: Takashi Iwai

    Eldad Zack
     

29 Nov, 2012

2 commits


23 Nov, 2012

4 commits


21 Nov, 2012

3 commits


08 Nov, 2012

2 commits


30 Oct, 2012

3 commits

  • ... for migrating the core changes for USB-audio disconnection fixes

    Takashi Iwai
     
  • 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: Matthieu CASTET
    Cc:
    Signed-off-by: Takashi Iwai

    Takashi Iwai
     
  • 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: Matthieu CASTET
    Cc:
    Signed-off-by: Takashi Iwai

    Takashi Iwai
     

21 Oct, 2012

1 commit


19 Sep, 2012

4 commits

  • The recent fix for USB suspend breakage moved the code to set up EP
    from hw_params to prepare, but it means also the EP setup might be
    called multiple times unnecessarily because the prepare callback can
    be called multiple times without starting the stream (e.g. OSS
    emulation).

    This patch adds a new flag to struct snd_usb_substream indicating
    whether the setup of EP is required, and do it only when necessary,
    i.e. right after hw_params or suspend.

    Signed-off-by: Takashi Iwai

    Takashi Iwai
     
  • Move interface and endpoint configuration from hw_params to prepare
    callback. During system suspend/resume when the USB device power isn't
    cycled the interface and endpoint configuration need to be set before
    audio playback can continue. Resume involves another call to prepare
    but not to hw_params, moving it here allows a playing stream to continue
    after resume.

    Signed-off-by: Dylan Reid
    Signed-off-by: Takashi Iwai

    Dylan Reid
     
  • Change the interface to configure an endpoint so that it doesn't require
    a hw_params struct. This will allow it to be called from prepare
    instead of hw_params, configuring it after system resume.

    Signed-off-by: Dylan Reid
    Signed-off-by: Takashi Iwai

    Dylan Reid
     
  • Set the peiod_bytes member of snd_usb_substream. It was no longer being
    set, but will be needed to resume properly in a future commit.

    Signed-off-by: Dylan Reid
    Signed-off-by: Takashi Iwai

    Dylan Reid
     

06 Sep, 2012

1 commit

  • The recent fix for the missing fine delayed time adjustment gives
    strange error messages at each start of the playback stream, such as
    delay: estimated 0, actual 352
    delay: estimated 353, actual 705

    These come from the sanity check in retire_playback_urb(). Before the
    stream is activated via start_endpoints(), a few silent packets have
    been already sent. And at this point the delay account is still in
    the state as if the new packets are just queued, so the driver gets
    confused and spews the bogus error messages.

    For fixing the issue, we just need to check whether the received
    packet is valid, whether it's zero sized or not.

    Reported-by: Markus Trippelsdorf
    Cc: [v3.5+]
    Signed-off-by: Takashi Iwai

    Takashi Iwai
     

01 Sep, 2012

3 commits

  • Commit 68e67f40b ("ALSA: snd-usb: move calls to usb_set_interface")
    saved us some unnecessary calls to snd_usb_set_interface() but ignored
    the fact that there is at least one device out there which operates on
    two endpoint in different interfaces simultaniously.

    Take care for this by catching the case where data and sync endpoints
    are located on different interfaces and calling snd_usb_set_interface()
    between the start of the two endpoints.

    Signed-off-by: Daniel Mack
    Reported-by: Robert M. Albrecht
    Cc: stable@kernel.org [v3.5+]
    Signed-off-by: Takashi Iwai

    Daniel Mack
     
  • In order to support devices with implicit feedback streaming models,
    packet sizes are now stored with each individual urb, and the PCM
    handling code which fills the buffers purely relies on the size fields
    now.

    However, calling snd_usb_audio_next_packet_size() for all possible
    packets in an URB at once, prior to letting the PCM code do its job
    does in fact not lead to the same behaviour than what the old code did:
    The PCM code will break its loop once a period boundary is reached,
    consequently using up less packets that it really could.

    As snd_usb_audio_next_packet_size() implements a feedback mechanism to
    the endpoints phase accumulator, the number of calls to that function
    matters, and when called too often, the data rate runs out of bounds.

    Fix this by making the next_packet function public, and call it from the
    PCM code as before if the packet data sizes are not defined.

    Signed-off-by: Daniel Mack
    Cc: stable@kernel.org [v3.5+]
    Signed-off-by: Takashi Iwai

    Daniel Mack
     
  • Parts of commit 294c4fb8 ("ALSA: usb: refine delay information with USB
    frame counter") were unfortunately lost during the refactoring of the
    snd-usb driver in 3.5.

    This patch adds them back, restoring the correct delay information
    behaviour.

    Signed-off-by: Daniel Mack
    Cc: Pierre-Louis Bossart
    Cc: stable@kernel.org [3.5+]
    Signed-off-by: Takashi Iwai

    Daniel Mack
     

30 Aug, 2012

1 commit

  • Commit e9ba389c5 ("ALSA: usb-audio: Fix scheduling-while-atomic bug in
    PCM capture stream") fixed a scheduling-while-atomic bug that happened
    when snd_usb_endpoint_start was called from the trigger callback, which
    is an atmic context. However, the patch breaks the idea of the endpoints
    reference counting, which is the reason why the driver has been
    refactored lately.

    Revert that commit and let snd_usb_endpoint_start() take care of the URB
    cancellation again. As this function is called from both atomic and
    non-atomic context, add a flag to denote whether the function may sleep.

    Signed-off-by: Daniel Mack
    Cc: stable@kernel.org [3.5+]
    Signed-off-by: Takashi Iwai

    Daniel Mack
     

16 Aug, 2012

1 commit

  • A PCM capture stream on usb-audio causes a scheduling-while-atomic
    BUG, as reported in the bugzilla entry below. It's because
    snd_usb_endpoint_start() is called at first at trigger START for a
    capture stream, and this function contains the left-over EP
    deactivation codes. The problem doesn't happen for a playback stream
    because the function is called at PCM prepare time, which can sleep.

    This patch fixes the BUG by moving the EP deactivation code into the
    PCM prepare callback.

    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=46011
    Cc: [v3.5+]
    Signed-off-by: Takashi Iwai

    Takashi Iwai