On 21.10.2012 16:57, Artem S. Tashkinov wrote:
>> On Oct 21, 2012, Daniel Mack  wrote: 
>>
>> [Cc: alsa-devel]
>>
>> On 21.10.2012 14:30, Artem S. Tashkinov wrote:
>>> On Oct 21, 2012, Daniel Mack wrote: 
>>>
>>>> A hint at least. How did you enable the audio record exactly? Can you
>>>> reproduce this with arecord?
>>>>
>>>> What chipset are you on? Please provide both "lspci -v" and "lsusb -v"
>>>> dumps. As I said, I fail to reproduce that issue on any of my machines.
>>>
>>> All other applications can read from the USB audio without problems, it's
>>> just something in the way Adobe Flash polls my audio input which causes
>>> a crash.
>>>
>>> Just video capture (without audio) works just fine in Adobe Flash.
>>
>> Ok, so that pretty much rules out the host controller. I just wonder why
>> I still don't see it here, and I haven't heard of any such problem from
>> anyone else.
>>
>> Some more questions:
>>
>> - Which version of Flash are you running?
> 
> Google Chrome has its own version of Adobe Flash:
> 
> Name: Shockwave Flash
> Description:  Shockwave Flash 11.4 r31
> Version:      11.4.31.110

So that's the same that I'm using.

>> - Does this also happen with Firefox?
> 
> No, Adobe Flash in Firefox is an older version (Shockwave Flash 11.1 r102), 
> it shows
> just two input devices instead of three which the newer Flash players sees.
> 
> * HDA Intel PCH
> * USB Device 0x46d:0x81d

And that works, I assume? Does the second choice in the newer Flash
version work maybe?

>> - Does flash access the device directly or via PulseAudio?
> 
> PA is not installed on my computer, so Flash accesses it directly via ALSA 
> calls.

Ok, Same here.

>> - Could you please apply the attached patch and see what it spits out to
>> dmesg once Flash opens the device? It returns -EINVAL in the hw_params
>> callback to prevent the actual streaming. On my machine with Flash
>> 11.4.31.110, I get values of 2/44800/1/32768/2048/0, which seems sane.
>> Or does your machine still crash before anything is written to the logs?
> 
> I will try it a bit later.

Yes, we need to trace the call chain and see at which point the trouble
starts. What could help is tracing the google-chrome binary with strace
maybe. At least we would see the ioctl command sequence, if the log file
survives the crash.

As the usb list is still in Cc: - Artem's lcpci dump shows that his
machine features XHCI controllers. Can anyone think of a relation to
this problem?

And Artem, is there any way you boot your system on an older machine
that only has EHCI ports? Thinking about it, I wonder whether the freeze
in VBox and the crashes on native hardware have the same root cause. In
that case, would it be possible to share that VBox image?


Daniel

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to