[alsa-devel] [PATCH 00/25 v2] ALSA: support AMDTP variants

Takashi Sakamoto o-takashi at sakamocchi.jp
Sat Aug 29 08:00:16 CEST 2015


On 2015年08月25日 21:03, Takashi Iwai wrote:
>> For all that, the last part of this patchset is a bot worse. I concide 
>> it, sorry. MIDI functionality of TASCAM FireWire series is enough 
>> complicated to me and I always have a headache at considering about is 
>> (then make some easy mistakes).
>>
>>> Also, I see quite a few code duplications in the series.  For example,
>>> PCM read/write/silence loop is almost identical except for a few lines
>>> of differences inside the loop.  Ditto for MIDI accessors.  Can they
>>> be shared somehow better?
>>
>> I think you mention about the codes in data block processing, such as 
>> read_pcm_s32() in sound/firewire/amdtp-am824.c (originally in amdtp.c). 
>> These functions are called as frequently as 8,000 times per second, thus 
>> it's preferrable to keep the size as small as possible for CPU usage.
>>
>> While, each data block processing includes quite similar codes. In this 
>> meaning, your idea is valid, indeed. But currently, I adhere to the way 
>> to implement different data block processing as what the shape is. 
>> There's no public specification about it and I prefer to keep the codes 
>> as easy to read as possible.
> 
> Well, if you provide simple ops like write_s32(), read_s32(),
> silence_s32(), etc, all codes can be same.  The inner loop calls one
> of this ops, which returns a BE32 value or convert to a native value,
> etc. The performance cost by such a function call isn't too tragic.

I don't like to discuss without actual patches, for this kind of issues.


Regards

Takashi Sakamoto


More information about the Alsa-devel mailing list