lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2fa1f433-326a-8eb6-b01e-e34ff82a2dd9@gmail.com>
Date:   Fri, 6 Oct 2023 19:02:56 +0100
From:   Ivan Orlov <ivan.orlov0322@...il.com>
To:     Jaroslav Kysela <perex@...ex.cz>, tiwai@...e.com
Cc:     alsa-devel@...a-project.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/2] ALSA: aloop: Add support for the non-interleaved
 access mode

On 10/5/23 08:23, Jaroslav Kysela wrote:
> On 27. 09. 23 13:35, Ivan Orlov wrote:
>> The current version of the loopback driver supports interleaved access
>> mode only. This patch introduces support for the non-interleaved
>> access mode.
>>
>> When in the interleaved mode, the 'copy_play_buf' function copies data
>> from the playback to the capture buffer using one memcpy call. This call
>> copies samples for multiple, interleaved channels.
>>
>> In the non-interleaved mode we have multiple channel buffers, so we have
>> to perform multiple memcpy calls to copy samples channel after channel.
>>
>> Add new function called 'copy_play_buf_part_n', which copies a part of
>> each channel buffer from playback to capture. Modify the 'copy_play_buf'
>> to use the corresponding memory copy function(just memcpy /
>> copy_play_buf_part_n) depending on the access mode.
>>
>> Signed-off-by: Ivan Orlov <ivan.orlov0322@...il.com>
> 
> Nice extension. Thank you.
> 
>> +static void copy_play_buf_part_n(struct loopback_pcm *play, struct 
>> loopback_pcm *capt,
>> +                 unsigned int size, unsigned int src_off, unsigned 
>> int dst_off)
> 
> I would probably prefer to have dst,src,size arguments to follow memcpy, 
> but it's really nitpicking.
> 
> Reviewed-by: Jaroslav Kysela <perex@...ex.cz>
> 
>                      Jaroslav
> 

Hi Jaroslav,

Thank you for the review!

I agree that parameters similar to the memcpy would look better than 
that, I'll keep it in mind when I send the next patch :)

--
Kind regards,
Ivan Orlov

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ