Re: [PATCH] pcm: fix wrong document references to PCM APIs which perform direct memory access with frame copying

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, 13 Dec 2016 00:18:04 +0100,
Takashi Iwai wrote:
> 
> On Tue, 13 Dec 2016 00:06:56 +0100,
> Takashi Sakamoto wrote:
> > 
> > Hi,
> > 
> > On Dec 13 2016 06:36, Takashi Iwai wrote:
> > > On Sun, 11 Dec 2016 12:31:38 +0100,
> > > Takashi Sakamoto wrote:
> > >>
> > >> In a design of ALSA PCM interface, for PCM frame transmission to/from
> > >> kernel space, applications can select from two options; direct memory access
> > >> or ioctl(2). Available options are decided depending on device capacity and
> > >> machine architecture. Applications can get available options by the first
> > >> entry of 'struct snd_pcm_hw_params.masks'.
> > >>
> > >> When the mask includes 'SNDRV_PCM_ACCESS_MMAP_xxx', applications can use
> > >> direct memory access. For this use case, userspace library has two types
> > >> of PCM API. One is to expose a pointer over the memory to start
> > >> reading/writing PCM frames. Another is to copy PCM frames between the
> > >> memory and a given buffer.
> > >>
> > >> Current documentation includes wrong references to these APIs to describe
> > >> their advantages/disadvantages. This confuses application developers
> > >> because the references indicate PCM APIs to execute ioctl(2) operation to
> > >> read/write PCM frames.
> > >>
> > >> This commit fixes the bug.
> > >>
> > >> Signed-off-by: Takashi Sakamoto <o-takashi@xxxxxxxxxxxxx>
> > >
> > > Applied, thanks.
> > 
> > Thanks.
> > 
> > Additionally, I'm pleased if you apply below patches to fix some
> > compiler warnings which topology features recently got. I guess Intel
> > developers are under their holidays.
> 
> I leave these, as they are basically harmless.
> I'll take once when I get acks from Intel people.

Actually I took the second one (the removal of unused variables), as
it's a good cleanup.

But the first one, the change of the type, is in a gray zone, and I'd
like to leave such a thing.  Changing the loop variable like i to
unsigned int is rather confusing, and it may be a source of bugs if
anyone reuses i for another loop.  The warning is merely an annoyance,
and IMO, we just should suppress the compile warning like the kernel
does.

The third patch, the removal of the unused table, is postponed because
I don't know whether it's intentional or overlook unless confirmation
from Intel people.


Takashi

> 
> 
> thanks,
> 
> Takashi
> 
> 
> >  [PATCH][alsa-lib] topology: fix sign-compare warning
> > introduced to set_link_hw_config() and tplg_add_link_object()
> > http://mailman.alsa-project.org/pipermail/alsa-devel/2016-November/115245.html
> > 
> >  [PATCH][alsa-lib] topology: fix unused-variable warnings
> > introduced to build_link()
> > http://mailman.alsa-project.org/pipermail/alsa-devel/2016-November/115246.html
> > 
> >  [PATCH][alsa-lib] topology: fix unused-const-variable warning
> > http://mailman.alsa-project.org/pipermail/alsa-devel/2016-November/115247.html
> > 
> > 
> > Regards
> > 
> > Takashi Sakamoto
> > 
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel



[Index of Archives]     [ALSA User]     [Linux Audio Users]     [Kernel Archive]     [Asterisk PBX]     [Photo Sharing]     [Linux Sound]     [Video 4 Linux]     [Gimp]     [Yosemite News]

  Powered by Linux