On Thu, Aug 28, 2014 at 3:33 PM, Daniel Mack <daniel@xxxxxxxxxx> wrote: > On 08/28/2014 11:33 AM, Jassi Brar wrote: >> On Wed, Aug 27, 2014 at 10:39 PM, Daniel Mack <zonque@xxxxxxxxx> wrote: > >>> diff --git a/drivers/usb/gadget/function/f_uac2.c b/drivers/usb/gadget/function/f_uac2.c >>> index 246a778..a5a27a5 100644 >>> --- a/drivers/usb/gadget/function/f_uac2.c >>> +++ b/drivers/usb/gadget/function/f_uac2.c >>> @@ -92,6 +92,15 @@ struct snd_uac2_chip { >>> >>> struct snd_card *card; >>> struct snd_pcm *pcm; >>> + >>> + /* timekeeping for the playback endpoint */ >>> + unsigned int p_interval; >>> + unsigned int p_residue; >>> + >>> + /* pre-calculated values for playback iso completion */ >>> + unsigned int p_pktsize; >>> + unsigned int p_pktsize_residue; >>> + unsigned int p_framesize; >>> }; >>> >> I admire Alan's simple algo. I couldn't have matched that. >> >> However I am not sure how worth is the implementation if it requires 3 >> more members to avoid calculations simple enough to cause no >> noticeable overhead. Once every millisecond is perfectly bearable IMO. > > Alan is right. If we can avoid that, we should. > It started with avoiding storing values (even lesser overhead) and doing things in runtime (code looking elegant). >> 5 members in uac2 structure for only playback, look ugly. > > It's still superior to a number of unnecessary calculations done every > millisecond which will come up with the same result every time. So I > clearly favor that approach. Three more ints in a struct don't hurt > really for something that's usually not instantiated more than once per > system. > > Anyway, I'll leave it to Felipe whether to merge v5 or v6 :) > Please wait, let me cook up a patch that uses (a) Alan's algo, (b) cause lesser churn and (c) is even 'faster'. -jassi -- 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