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
