[Sound-open-firmware] [PATCH v2] volume: support 8-channel feature

[zhigangw]

On 2018年06月19日 15:44, Seppo Ingalsuo wrote:
>
>
> On 19.06.2018 09:10, Wu Zhigang wrote:
>>   const struct comp_func_map func_map[] = {
>>       {SOF_IPC_FRAME_S16_LE, SOF_IPC_FRAME_S16_LE, 2, 
>> vol_s16_to_s16_2ch},
>>       {SOF_IPC_FRAME_S16_LE, SOF_IPC_FRAME_S32_LE, 2, 
>> vol_s16_to_s32_2ch},
>> @@ -485,6 +837,17 @@ const struct comp_func_map func_map[] = {
>>       {SOF_IPC_FRAME_S32_LE, SOF_IPC_FRAME_S24_4LE, 4, 
>> vol_s32_to_s24_4ch},
>>       {SOF_IPC_FRAME_S24_4LE, SOF_IPC_FRAME_S32_LE, 4, 
>> vol_s24_to_s32_4ch},
>>       {SOF_IPC_FRAME_S24_4LE, SOF_IPC_FRAME_S24_4LE, 4, 
>> vol_s24_to_s24_4ch},
>> +#ifdef CONFIG_APOLLOLAKE
>> +    {SOF_IPC_FRAME_S16_LE, SOF_IPC_FRAME_S16_LE, 8, 
>> vol_s16_to_s16_8ch},
>> +    {SOF_IPC_FRAME_S16_LE, SOF_IPC_FRAME_S32_LE, 8, 
>> vol_s16_to_s32_8ch},
>> +    {SOF_IPC_FRAME_S32_LE, SOF_IPC_FRAME_S16_LE, 8, 
>> vol_s32_to_s16_8ch},
>> +    {SOF_IPC_FRAME_S32_LE, SOF_IPC_FRAME_S32_LE, 8, 
>> vol_s32_to_s32_8ch},
>> +    {SOF_IPC_FRAME_S16_LE, SOF_IPC_FRAME_S24_4LE, 8, 
>> vol_s16_to_s24_8ch},
>> +    {SOF_IPC_FRAME_S24_4LE, SOF_IPC_FRAME_S16_LE, 8, 
>> vol_s24_to_s16_8ch},
>> +    {SOF_IPC_FRAME_S32_LE, SOF_IPC_FRAME_S24_4LE, 8, 
>> vol_s32_to_s24_8ch},
>> +    {SOF_IPC_FRAME_S24_4LE, SOF_IPC_FRAME_S32_LE, 8, 
>> vol_s24_to_s32_8ch},
>> +    {SOF_IPC_FRAME_S24_4LE, SOF_IPC_FRAME_S24_4LE, 8, 
>> vol_s24_to_s24_8ch},
> The code size gets quite big with all the channel count versions of 
> generic C volume control. This is probably OK for now since it's for 
> larger APL DSP but all volume variants should be possible to handle 
> efficiently with 1/2/4 dividable channels count volume handlers 
> versions and with Intrinsics code maybe just 1/2. There will be in 
> future also float data so this approach is suffering from combinatory 
> explosion.
>
> Thanks,
> Seppo
>
I definitely agree with you.
Intrinsic instruction is good for the performance, but it is bad for the 
portable.
If we do not care about the portable, we also could try the compiler 
option. it is also another choice.
we have to do some experiments in future to balance the code size and 
performance.
thanks
~zhigang
> _______________________________________________
> Sound-open-firmware mailing list
> Sound-open-firmware at alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/sound-open-firmware