snd_async_add_pcm_handler() and SND_PCM_ACCESS_MMAP_INTERLEAVED

snd_async_add_pcm_handler() and SND_PCM_ACCESS_MMAP_INTERLEAVED

[Peter Vollmer]

Hi all,

I am trying to use the mmap access method together with an async_handler 
function (ice1712 in multitrack mode),
but in a setting where multiple periods fit into a buffer, I get back the 
same address pointer to the accessible data in  snd_pcm_mmap_begin(...) in 
areas[x].addr multiple times (one for every period in the buffer, I guess) 
in the signal handler. I was following the pcm.c sinus generator demo more 
or less, but the combination of mmap/async_handler is not used there.

I was trying to dereference the appl.ptr and hw.ptr pointers from the 
snd_pcm_t handler to get exact information about the buffer pointers, but 
this does not work from my application since the struct type definition of 
snd_pcm_t seems to be hidden. What else can I use to get information about 
the pointers inside the capturing buffer ? Or did I simply fail to include 
the right header ?

Thanks for any hints

Peter



-------------------------------------------------------
Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
The only event dedicated to issues related to Linux enterprise solutions
www.enterpriselinuxforum.com

Re: snd_async_add_pcm_handler() and SND_PCM_ACCESS_MMAP_INTERLEAVED

[Jaroslav Kysela]

On Thu, 15 May 2003, Peter Vollmer wrote:

> Hi all,
> 
> I am trying to use the mmap access method together with an async_handler 
> function (ice1712 in multitrack mode),
> but in a setting where multiple periods fit into a buffer, I get back the 
> same address pointer to the accessible data in  snd_pcm_mmap_begin(...) in 
> areas[x].addr multiple times (one for every period in the buffer, I guess) 
> in the signal handler. I was following the pcm.c sinus generator demo more 
> or less, but the combination of mmap/async_handler is not used there.

I've added async_direct method to show you the right code. The updated 
pcm.c is in CVS.

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SuSE Labs



-------------------------------------------------------
Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
The only event dedicated to issues related to Linux enterprise solutions
www.enterpriselinuxforum.com

Re: snd_async_add_pcm_handler() and SND_PCM_ACCESS_MMAP_INTERLEAVED

[Paul Davis]

>I am trying to use the mmap access method together with an async_handler 
>function (ice1712 in multitrack mode),

i just want to remind anyone using the async handlers that the list of
system calls you can make in an async handler is extremely
limited. make sure you limit yourself to that list.


-------------------------------------------------------
Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
The only event dedicated to issues related to Linux enterprise solutions
www.enterpriselinuxforum.com

Re: snd_async_add_pcm_handler() and SND_PCM_ACCESS_MMAP_INTERLEAVED

[Peter Vollmer]

At 08:18 15.5.2003 -0400, you wrote:
> >I am trying to use the mmap access method together with an async_handler
> >function (ice1712 in multitrack mode),
>
>i just want to remind anyone using the async handlers that the list of
>system calls you can make in an async handler is extremely
>limited. make sure you limit yourself to that list.

thanks for the prompt response,
my goal is to copy captured data (ice1712 multitrack mode, 12 interleaved 
channels, S32_LE data) with low latency (max 50 ms) and as little overhead 
as possible, so my first thought was to use mmap and async handlers.

Now I found a recent thread about using async handlers
(http://www.geocrawler.com/mail/thread.php3?subject=%5BAlsa-devel%5D+Restarting+when+in+async+mode&list=12349) 

and I guess I have to think again about poll(2) and a multithreaded 
application. What would you suggest to be the fastest access method under 
these circumstances ?

Peter





-------------------------------------------------------
Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
The only event dedicated to issues related to Linux enterprise solutions
www.enterpriselinuxforum.com

Re: snd_async_add_pcm_handler() and SND_PCM_ACCESS_MMAP_INTERLEAVED

[Takashi Iwai]

At Thu, 15 May 2003 08:18:53 -0400,
Paul Davis wrote:
> 
> >I am trying to use the mmap access method together with an async_handler 
> >function (ice1712 in multitrack mode),
> 
> i just want to remind anyone using the async handlers that the list of
> system calls you can make in an async handler is extremely
> limited. make sure you limit yourself to that list.

IIRC, even ioctl is not allowed officially by POSIX.
that means, almost all actions of ALSA PCM...

in practice, they work fine, though :)

correct me if i'm wrong here.


Takashi


-------------------------------------------------------
Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
The only event dedicated to issues related to Linux enterprise solutions
www.enterpriselinuxforum.com

Re: snd_async_add_pcm_handler() and SND_PCM_ACCESS_MMAP_INTERLEAVED

[Paul Davis]

>my goal is to copy captured data (ice1712 multitrack mode, 12 interleaved 
>channels, S32_LE data) with low latency (max 50 ms) and as little overhead 
>as possible, so my first thought was to use mmap and async handlers.

sorry to sound like a broken record for so many people, but is there
any reason not to just use JACK? JACK goes down significantly below 50ms.

>Now I found a recent thread about using async handlers
>(http://www.geocrawler.com/mail/thread.php3?subject=%5BAlsa-devel%5D+Restartin
>g+when+in+async+mode&list=12349) 
>
>and I guess I have to think again about poll(2) and a multithreaded 
>application. What would you suggest to be the fastest access method under 
>these circumstances ?

the speed difference will be negligible. you have to trade off rather
limited "legal" functionality from an async handler with the
complexities and freedom of poll+threads.


-------------------------------------------------------
Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
The only event dedicated to issues related to Linux enterprise solutions
www.enterpriselinuxforum.com

Re: snd_async_add_pcm_handler() and SND_PCM_ACCESS_MMAP_INTERLEAVED

[Paul Davis]

>IIRC, even ioctl is not allowed officially by POSIX.
>that means, almost all actions of ALSA PCM...

yes, no ioctl. read/write/lseek/pipe/fork are OK. bizarre, eh?

>in practice, they work fine, though :)

until one day, someone does a significant and entirely legal kernel
hack that makes all ioctl syscalls fail when made from signal
handlers ...


-------------------------------------------------------
Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
The only event dedicated to issues related to Linux enterprise solutions
www.enterpriselinuxforum.com

Re: snd_async_add_pcm_handler() and SND_PCM_ACCESS_MMAP_INTERLEAVED

[Jaroslav Kysela]

On Thu, 15 May 2003, Paul Davis wrote:

> >IIRC, even ioctl is not allowed officially by POSIX.
> >that means, almost all actions of ALSA PCM...
> 
> yes, no ioctl. read/write/lseek/pipe/fork are OK. bizarre, eh?
> 
> >in practice, they work fine, though :)
> 
> until one day, someone does a significant and entirely legal kernel
> hack that makes all ioctl syscalls fail when made from signal
> handlers ...

Yes, but we can talk with the driver only using DMA buffer and mmaped ring 
buffer pointers, so the properly written program does not use ioctls.

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SuSE Labs



-------------------------------------------------------
Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
The only event dedicated to issues related to Linux enterprise solutions
www.enterpriselinuxforum.com

Re: snd_async_add_pcm_handler() and SND_PCM_ACCESS_MMAP_INTERLEAVED

[Paul Davis]

>On Thu, 15 May 2003, Paul Davis wrote:
>
>> >IIRC, even ioctl is not allowed officially by POSIX.
>> >that means, almost all actions of ALSA PCM...
>> 
>> yes, no ioctl. read/write/lseek/pipe/fork are OK. bizarre, eh?
>> 
>> >in practice, they work fine, though :)
>> 
>> until one day, someone does a significant and entirely legal kernel
>> hack that makes all ioctl syscalls fail when made from signal
>> handlers ...
>
>Yes, but we can talk with the driver only using DMA buffer and mmaped ring 
>buffer pointers, so the properly written program does not use ioctls.

i'd love to find a way to make JACK do that. unfortunately, it seems
to need to make a few system calls on returning from poll. unless i'm
just forgetting something, and the calls it makes all resolve to
operations on the mmapped buffer points. 


-------------------------------------------------------
Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
The only event dedicated to issues related to Linux enterprise solutions
www.enterpriselinuxforum.com