On Thu, Sep 16, 2010 at 8:32 AM, Clemens Ladisch <clemens@xxxxxxxxxx> wrote: > Monty Montgomery wrote: >> When I offered a fixed version, there was relatively little interest in >> accepting it (it needed a shakedown and debugging period; big change). > > Could you point me to the last version of this patch? Sure. I think the latest monolithic version of the patch is: http://web.mit.edu/xiphmont/Public/ehci-sched-2.6.17-20060809.patch I give it zero chance of working on a modern 2.6 kernel. [The problem was that upstream would not accept the patch as the EHCI scheduler rewrite it was... they wanted individual 'funcitonal changes' so I had to replace the driver a tiny piece at a time... it was about 50 seperate patches if I remember correctly. And every time someone submitted a small conflicting change, they dropped my patch set and told me to regenerate it from scratch. After three or four rounds of this I gave up.] This new driver *did* have bugs, and there were good reasons it could not have gone mainline as is; regardless I ran it for years. It also doesn't solve problems like momentary starvation causing the higher level Linux USB stack to revoke your bandwidth allocation, which there's no guarantee you can get back. This is a fundamental aspect of the (weird) way the Linux USB stack is designed. It makes low-latency nearly impossible, as any time the USB stack pulls the last submission off the queue, it takes it as an implicit request to shut the device down. You must have URBs in flight at all times to keep running, so that doubles [minimum] the necessary playback latency on Linux, which is already high. Monty _______________________________________________ Linux-audio-user mailing list Linux-audio-user@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/listinfo/linux-audio-user
