Clemens Ladisch <clemens-P6GI/4k7KOmELgA04lAiVw@xxxxxxxxxxxxxxxx>
writes:
> David Kastrup wrote:
>> I just got some older Bamster soundbar model (probably not a keeper)
>> that takes USB either for power (in which case it uses AUX in analog) or
>> also as USB soundcard. In the latter case, however, it just switches
>> itself off after a few seconds.
>>
>> [ 1201.960192] usb 5-2: new full-speed USB device number 5 using uhci_hcd
>> [ 1203.344305] usbhid 5-2:1.3: can't add hid device: -71
>> [ 1203.456336] usb 5-2: USB disconnect, device number 5
>
> I'd guess that the firmware tries to detect if it is connect to an actaual
> PC (as opposed to some charger), and that Linux doesn't look right.
It doesn't have batteries to charge. If I plug in the AUX cord, I can
switch it on and it stays on (without attempting to announce it on USB).
You sure that it's the Bamster taking the initiative here? If I wait
for just the right moment, I can see in cat /etc/asound/cards
dak@lola:/usr/local/tmp/lilypond$ cat /proc/asound/cards
0 [Intel ]: HDA-Intel - HDA Intel
HDA Intel at 0xfe020000 irq 29
1 [Audio ]: USB-Audio - USB Audio
ACTIONS USB Audio at usb-0000:00:1d.0-2, full speed
immediately before it switches itself off again.
This behavior just does not make sense. I cannot rule out that the
chipset might be used in devices where this would be part of more useful
behavior but with as little clue as I have it sounds more like Linux
does something bad here. Should it respond differently to any request?
--
David Kastrup
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@xxxxxxxxxxxxxxxxxxxx
https://lists.linuxaudio.org/listinfo/linux-audio-user
