[sf-lug] USB mic not working under 14.04

[Rick Moen]

Quoting Christian Einfeldt (einfeldt at gmail.com):

> Hi Rick, thanks for your reply.  I am bottom posting....

Yr. very welcome.

> Wow, that's weird...  It does not look at all like that device.  It looks
> like this:
> 
> https://www.amazon.com/gp/product/B0009VV8JC/ref=s9_acsd_hps_bw_c_x_4_w


Aha!  (If I could do a credible Hercule Poirot imitation, this would be
where I'd do a bit of shtick about my 'leetle grey cells'.)

As I suspected.  So, either the *buntu box has a wrong USB IDs database
resulting in wrong data returned for an otherwise correct hex ID, or two
very different USB devices erroneously share the same hex ID combo,
right?  More about that below.

> Yeah, I don't know what to think.  This mic works on a Chromebook
> immediately and without any fuss.  ChromeOS is a type of Linux, right, so
> there must be an answer somewhere, I am hoping.

So, here's a somewhat rhetorical question (because I'm aware you
probably don't have the Chromebook at your disposal on short notice):
What does lsusb on the Chromebook say about the device?  Same USB ID
numbers?  Different description entirely?  (If so, what?)

Unless I'm badly mistaken (which, hey, is always possible), my
understanding is that lsusb works very similarly to the way lspci works,
which is:  Send a query to an interface chip, asking "What'cha got?"

In the case of lspci, the query goes to the PCI controller chip.  In the
case of lsusb, the query goes to the USB controller chip.  In both
cases, the answer is a set of lines in hexadecimal, one inventoried
device per line, giving device ID numbers.  Both of the Linux admin tools
include that device ID number in their output.

Both of those tools return not _just_ the hexadecimal device IDs, but
also corresponding data from a lookup table that then returns "Oh, this
is from manufacturer [foo] and is product [bar].'  

So, to review, the report is sort of a two-phase process.  Phase 1 is 
querying the controller chip and getting the vendor/device ID strings in
hex.  Phase 2 is using those hex pairings to look up plain English text
manufacturer/model inforamtion from a lookup database file.

It's difficult for me to imagine Phase 1 going badly wrong, because it's
really extremely simple, and I'd expect it to either work correctly or
not at all.  Phase 2 relies on correct information in the lookup file,
obviously.

It would useful to know if the microphone always and everywhere
registered as the same vendor/device ID hexadecimal combo.