Re: Regression in audio playback with USB DAC caused by "USB: EHCI: use the new clear_tt_buffer interface"

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, 16 Nov 2009, Javier Kohen wrote:

> I'm trying to find another hub to test, with no luck so far. However,
> even if the monitor's hub were buggy, I'm hoping there is a way to
> workaround the problem in the kernel, since said problem didn't exist
> a short time ago.

That's not entirely accurate.  The problem is that the hub stops
sending isochronous packets when it gets a Clear-TT-Buffer.  This
problem _did_ exist a short time ago -- it just wasn't triggered
because the kernel was erroneously failing to send Clear-TT-Buffer
requests when it should have sent them.

To tell the truth, I don't see any way to work around the problem at
the moment.  The Clear-TT-Buffer functionality is a fundamental part of
the workings of any high-speed hub.  If the hub doesn't implement it
correctly, there's not much we can do.

Of course, there's always the possibility of making the kernel stop
sending Clear-TT-Buffer requests entirely.  (Or at least, stop sending
them in response to STALLs, which is what you are receiving.)  But this
would violate the USB 2.0 specification (*), so it's not something I
would consider lightly.

Alan Stern

(*) The relevant sections are: Near the end of 11.17.1 (after Figure
11-51) where the text says

	If the host receives a STALL handshake, it performs endpoint 
	halt processing and will not issue any more split transactions
	for this full-/low-speed endpoint until the halt condition is
	removed.

and 11.17.5 where the text says

	When a bulk/control split transaction fails, it can leave the
	associated TT transaction buffer in a busy (ready/x) state.
	This buffer state will not allow the buffer to be reused for
	other bulk/control split transactions. Therefore, as part of
	endpoint halt processing for full-/low-speed endpoints
	connected via a TT, the host software must use the
	Clear_TT_Buffer request to the TT to ensure that the buffer is
	not in the busy state.

Admittedly, I don't see how a STALL handshake could be consistent with 
a busy transaction buffer, so maybe the spec is wrong in this respect.  
I still hesitate to violate it.

Besides, Clear-TT-Buffer is supposed to be harmless if the buffer isn't 
busy.  It certainly shouldn't affect periodic transfers.

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

[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux