kernel/git/stable/linux.git/sound/usb, branch linux-3.5.y

ALSA: USB: Support for (original) Xbox Communicator

2012-10-12T20:47:14+00:00

commit c05fce586d4da2dfe0309bef3795a8586e967bc3 upstream. Added support for Xbox Communicator to USB quirks. Signed-off-by: Marko Friedemann Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman

ALSA: usb - disable broken hw volume for Tenx TP6911

2012-10-12T20:47:14+00:00

commit c10514394ef9e8de93a4ad8c8904d71dcd82c122 upstream. While going through Ubuntu bugs, I discovered this patch being posted and a confirmation that the patch works as expected. Finding out how the hw volume really works would be preferrable to just disabling the broken one, but this would be better than nothing. Credit: sndfnsdfin (qawsnews) BugLink: https://bugs.launchpad.net/bugs/559939 Signed-off-by: David Henningsson Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman

ALSA: snd-usb: fix next_packet_size calls for pause case

2012-10-02T17:40:02+00:00

commit 8dce30c89113e314d29d3b8f362aadff8087fccb upstream. Also fix the calls to next_packet_size() for the pause case. This was missed in 245baf983 ("ALSA: snd-usb: fix calls to next_packet_size"). Signed-off-by: Daniel Mack Reviewed-by: Takashi Iwai Reported-and-tested-by: Christian Tefzer [ Taking directly because Takashi is on vacation - Linus ] Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman

ALSA: usb-audio: Fix bogus error messages for delay accounting

2012-10-02T17:39:00+00:00

commit 1213a205f9ed27d97de3d5bed28fb085ef4853e2 upstream. 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 Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman

ALSA: snd-usb: fix cross-interface streaming devices

2012-09-14T16:59:41+00:00

commit 2e4a263ca80a203ac6109f5932722a716c265395 upstream. 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 Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman

ALSA: snd-usb: fix calls to next_packet_size

2012-09-14T16:59:40+00:00

commit 245baf983cc39524cce39c24d01b276e6e653c9e upstream. 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 Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman

ALSA: snd-usb: restore delay information

2012-09-14T16:59:40+00:00

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

ALSA: snd-usb: use list_for_each_safe for endpoint resources

2012-09-14T16:59:39+00:00

commit 03d2f44e967b3c2cf79a6dfb904c8880616c7f83 upstream. snd_usb_endpoint_free() frees the structure that contains its argument. Signed-off-by: Pavel Roskin Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman

ALSA: snd-usb: Fix URB cancellation at stream start

2012-09-14T16:59:39+00:00

commit 015618b902ae8e28705b7af9b4668615fea48ddd upstream. 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 Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman

ALSA: usb-audio: Fix scheduling-while-atomic bug in PCM capture stream

2012-09-14T16:59:37+00:00

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