[alsa-devel] usbaudio: Support for USB audio v2.0 devices

[Daniel Mack]

On Tue, Apr 27, 2010 at 07:29:52PM +0400, The Source wrote:
> 27.04.2010 18:07, Daniel Mack пишет:
> >On Tue, Apr 27, 2010 at 05:31:35PM +0400, The Source wrote:
> >>Perhaps I should've posted my problem in this thread earlier. Here's the
> >>summary:
> >>Creative X-Fi Notebook stopped working after upgrading from 1.0.22.1 to
> >>1.0.23 (worked just fine before).
> >>dmesg gives the following:
> >>
> >>usb 8-2: new full speed USB device using uhci_hcd and address 2
> >>usb 8-2: New USB device found, idVendor=041e, idProduct=30d2
> >>usb 8-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
> >>usb 8-2: Product: SB X-Fi Notebook
> >>usb 8-2: Manufacturer: Creative Technology Ltd
> >>usb 8-2: configuration #1 chosen from 1 choice
> >>input: Creative Technology Ltd SB X-Fi Notebook as
> >>/devices/pci0000:00/0000:00:1d.2/usb8/8-2/8-2:1.3/input/input11
> >>generic-usb 0003:041E:30D2.0002: input,hidraw1: USB HID v1.11 Device
> >>[Creative Technology Ltd SB X-Fi Notebook] on usb-0000:00:1d.2-2/input3
> >>input: Creative Technology Ltd SB X-Fi Notebook as
> >>/devices/pci0000:00/0000:00:1d.2/usb8/8-2/8-2:1.4/input/input12
> >>generic-usb 0003:041E:30D2.0003: input,hidraw2: USB HID v1.11 Keyboard
> >>[Creative Technology Ltd SB X-Fi Notebook] on usb-0000:00:1d.2-2/input4
> >>ALSA pcm.c:174: 2:1:1: endpoint lacks sample rate attribute bit, cannot
> >>set.
> >>ALSA pcm.c:174: 2:2:1: endpoint lacks sample rate attribute bit, cannot
> >>set.
> >And you say this is a regression from earlier versions? Would you be
> >able to bisect this problem?
> >
> >Daniel
> >
> Gladly, if you just tell me how :)

You would check out the latest mainline sources:

  $ git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
  $ cd linux-2.6

Then create a branch and merge the latest ALSA patches:

  $ git checkout -b alsa
  $ git pull git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6.git

Then build and install the kernel and verify it still shows the error.
Start the bisect and mark the current revision as 'bad':

  $ git bisect start
  $ git bisect bad

Assuming that v2.6.34-rc5 (before the merge) still works, you would mark
this as 'good':

  $ git bisect good v2.6.34-rc5

git will now iterate you thru the changes and drop you off at chosen
points. Just compile the tree you get, and tell git whether this is a
good or bad one:

  $ git bisect good
  or
  $ git bisect bad

Then recompile and test again After some steps, it will tell you which
commit precisely broke it.

HTH,
Daniel