https://bugzilla.kernel.org/show_bug.cgi?id=218544 --- Comment #13 from Alan Stern (stern@xxxxxxxxxxxxxxxxxxx) --- This raises an obvious question: What is the point of supporting 96 kHz operation on the output channel but only going up to 48 kHz on the input channel? That's weird. That maxpacket value for the output channel does look very strange. To support 96 kHz operation, 16-bits should use 384 bytes and 24-bits should use 576. (You wrote 458 but that was obviously a typo, copying the number in the line below.) The 768 value just seems wrong. I don't believe the device does 2-ms buffering. And no, isochronous packets do not have to use the full maxpacket size, but there's no reason to set the maxpacket size larger than necessary. I bet that 768 really ought to be 384, and it's a mistake in the device's firmware. I don't understand why unbinding fails to remove the HID's endpoint bandwidth usage. That might be a bug. While I haven't looked at the details of microframe scheduling in a long time, I don't think it would be valid to schedule the interrupt endpoint to start in microframe 6. Certainly if it were valid, it would require the use of FSTN nodes, which the driver does not support. Given that the device will require the entire 96 kHz output bandwidth even when it's running at only 48 kHz, scheduling is bound to be difficult or impossible. Things would be easier if there were separate alternate settings for 48 kHz and 96 kHz operation. Part of the scheduling problem arises because it's generally better to put the isochronous packets in the earlier microframes and the interrupt packets after them. However, the driver schedules each endpoint for the earliest feasible position, and apparently the interrupt endpoint gets started first. That's why it ends up in its non-optimal position at the beginning of the frame. In theory it's possible to change the 16-bit output maxpacket value in the kernel, setting it to 384. I don't know that this would be a good idea in general, but you could try it for your own use. It's not clear that you would want to spend the time and effort to do this, however. -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
