[alsa-devel] Accessing alsa user space buffer from external io type plugin

sandeep lahane sandeep.lahane at gmail.com
Tue Mar 25 02:41:03 CET 2008


On Mon, Mar 24, 2008 at 4:17 PM, Pharaoh . <pharaoh137 at gmail.com> wrote:

>
>
> On Mon, Mar 24, 2008 at 4:13 PM, sandeep lahane <sandeep.lahane at gmail.com>
> wrote:
>
> > Hello,
> >
> > I am debugging an userspace external io type plugin, written for an ARM
> > based board where the plugin
> > interacts with DSP directly using shared memory.
> >
> > Every time I have to send period_size data to the DSP, I have my own
> > write/read methods to do so.
> >
> > I am having a problem accessing the alsa ring buffer, my transfer
> > function
> > looks like following.
> >
> >
> > static   char * temp;
> > static snd_pcm_sframes_t alsa_transfer(snd_pcm_ioplug_t *io,
> >                   const snd_pcm_channel_area_t *areas,
> >                   snd_pcm_uframes_t offset,
> >                   snd_pcm_uframes_t size)
> > {
> >
> >           ......
> >
> >         temp = malloc(period_size);
> >         memcpy(temp,  unsigned char *)areas->addr + (areas->first +
> > areas->step * offset) / 8, period_size);
> >          write_to_dsp(temp, period_size);
> >          .......
> > }
> >
> > All the book keeping is done properly, the first chunk of data is sent
> > properly to DSP and pointer() returns correct value,
> > next time when transfer is called, the memcpy gives segfault. ALSA
> > buffer is
> > an interleaved buffer and I am not using mmap
> > mode. Any idea what might be wrong?
> >
> > When I do something like this:
> >        memcpy(temp,  "test data test data", period_size);
> > the data is sent properly to DSP, but alsa buffer data is not getting
> > accessed properly.
> >
> >
> >
> >
> >
> >
> > Regards,
> > Sandeep.
> > _______________________________________________
> > Alsa-devel mailing list
> > Alsa-devel at alsa-project.org
> > http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
> >
>
>
>
> temp is actually malloc'd in hw_params and freed properly, so please
> ignore the details like whether it is freed etc or not.
>



If I change the optimization level to O3, all the values passed from alsa
upper layer to my plugin are wrong. The reason I tried changing optimization
levels is that I have faced problems with ARM gcc 4.1.1. before when
compiled at O levels more than zero.  Are there any known problems with ARM
gcc 4.1.1 and alsa-lib 1.0.13?

-- 

Regards,
Sandeep.


More information about the Alsa-devel mailing list