On 10/6/06, David Brownell <[EMAIL PROTECTED]> wrote: > > My other points still stand. This patch is necessitated by the other > > patches. > > Did one of them cause EL2NSYNC to get reported differently then?
No, I mean that standard usage patterns will reliably cause an EL2NSYNC when my new scheduler patches are applied. Having the new scheduler patches, but not the usbaudio patch, will mean that usbaudio stops working. This is all due to my changes. EL2NSYNC happened before, but exceedingly rarely. With my patches, eg, apps using OSS will hit it every time. > You seem to have missed a key point of splitting a monster patch > into a sequence of independent patches ... the independence! I would assert the key point is being able to see each change in isolation clearly. > That is, in any series of patches 1..N it's a goal that later > patches be independent of earlier ones ... in the sense that > dropping the later ones not break anything, since the series > as a whole is _functionally_ incremental. Not only should the > system build with just the first N patches, but it should WORK > that way too. (And depending on the patches, a given patch > might not actually depend on preceding patches. It's good to > factor patches to minimize dependencies, when you can.) That argues against any attempt to split up this patch given that the chages are, by their nature, mostly interdependent. But it was an asserted requirement and I complied. > I don't think I disagreed with (b), although I think (a) must > then be obviously wrong ... otherwise it'd be impossible for > (b) to be true! :) I was conflating xrun with loss of sync as several others noted. We couldn't detect loss of sync, and in the case of xrun, we release the bandwidth allocation (which is making the error worse). > However my point was that this is the wrong fix. Since it's > already broken, and the issue seems unrelated to the patches > you've posted, it's reasonable to hold out for the right fix. It's clear the Big Patchset is also going to require changes. And that usbaudio does indeed need a fix (more than one in fact). However, having #15 is better than not having #15 if #1-14 are applied. > The patch you posted may make an OK workaround for certain > configurations though. Well, it sounds like EL2NSYNC has to go away as it wasn't the proper established channel for reporting the missed slots, and higher level drivers aren't expecting it because it wasn't documented (if, in fact, it ever did what I though it did, which apparently it didn't) Well, at least this argument is finally feeling like it wasn't a waste. Monty ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel