On Tue, 26 Mar 2013, Daniel Mack wrote:
On 24.03.2013 23:49, Eldad Zack wrote:
On Wed, 6 Feb 2013, Clemens Ladisch wrote:
Can you try using jackd -d alsa -d hw:x with the device and see if that works for you?
That works. This means that there is a race condition in the driver, or that the different open/hw_params/prepare order trips it up.
Yes, and also on closing (close/hw_free). I finally had some time to look into this - patch below adds some checks and with it:
Starting playback, waiting, starting capture: capture doesn't start, playback continues without breaking.
Starting capture, waiting, starting playback: playback doesn't start, capture breaks - but it is possible to restart the streams afterwards. [On my setup (with xhci), when the streams break I must restart my box to get them to work again with current code].
Starting both - no change, works good.
This is the order the ops get called when both are start at once, if it helps anyone:
playback capture open open hw_params set_format prepare set_format hw_params set_format prepare set_format prepare set_format prepare set_format trigger trigger
I'll try to figure out why capture breaks next. I still quite slow around the code and don't understand some parts of it so this might take me a while.
Thanks for looking into this!
@Daniel, do you have any hints for this case (capture breaking when starting playback)?
Give me some time to catch up and rebuild my FTU setup please. I hope I'll be able to get back to you by the end of this week.
Cool, thank you!
And it just remembered something. I tried to make the "in use" check non-fatal (return 0) and with a couple of more changes (very hacky) I got it to start in both orders.
But the problem was that when I stopped the playback* stream my kernel "exploded" (hard lock up). But if I stopped the capture, it was ok. Playback didn't even stop. (It might have been the other way around, but I think it was playback)
I can find that branch when I find some time if you think it might help.
Cheers, Eldad