Calling snd_pcm_oss_write directly.

Calling snd_pcm_oss_write directly.

[Shaju Abraham]

Hi all,
          I am in a situation where I intend to call snd_pcm_oss_write
directly.

What exactly happens is - the open and all the initial ioctl calls are
done by the oss application. But the write call of the oss application
is not done but it is done by some other task.

        So what I do is, when snd_pcm_oss_open gets called, I store the
-- struct file *file -- in my own pointer, say, gfile.

Then I use this pointer, -gfile- in snd_pcm_oss_write() when I call the
function directly.  But apparently this much is not enough. The direct
write call crashes.  If you can please tell me what else needs to be
done for the call to get through, it will be of great help.

--Shaju Abraham



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Calling snd_pcm_oss_write directly.

[Paul Davis]

>          I am in a situation where I intend to call snd_pcm_oss_write
>directly.

AFAIK, this is not a supported use of the alsa-lib API. There is no
guarantee that your application will continue to work in future
versions of alsa-lib.

>What exactly happens is - the open and all the initial ioctl calls are
>done by the oss application. But the write call of the oss application
>is not done but it is done by some other task.

there is still no reason to be using snd_pcm_<type>_<function> directly.

if you insist on using the OSS API (a big error, IMHO) then you can
just use the OSS API in the other task.

--p


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Calling snd_pcm_oss_write directly.

[Shaju Abraham]

Hi all,
        I took the advice and used write()  from the other task.  It
promptly returned with < 0 error.
I do not know how the oss emulation in ALSA happens, so I do not know what
exactly went wrong.
Any more suggestions are welcome.

        Again, continuing my experiment with calling snd_pcm_oss_write
directly,  I traced the crash to few fns called from fn snd_pcm_prepare in
pcm_native.c   . These fns seem to be making few ioctls like
..._IOCTL_PREPARE  and  ..._IOCTL_DRAIN. (more fns name ..ioctl than
ioctl() call itself).   what are these fns doing and is it normal that they
are called after snd_pcm_oss_write has already been called.

--shaju abraham



Paul Davis wrote:

> >          I am in a situation where I intend to call snd_pcm_oss_write
> >directly.
>
> AFAIK, this is not a supported use of the alsa-lib API. There is no
> guarantee that your application will continue to work in future
> versions of alsa-lib.
>
> >What exactly happens is - the open and all the initial ioctl calls are
> >done by the oss application. But the write call of the oss application
> >is not done but it is done by some other task.
>
> there is still no reason to be using snd_pcm_<type>_<function> directly.
>
> if you insist on using the OSS API (a big error, IMHO) then you can
> just use the OSS API in the other task.
>
> --p



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Calling snd_pcm_oss_write directly.

[Jaroslav Kysela]

On Wed, 24 Jul 2002, Shaju Abraham wrote:

> Hi all,
>           I am in a situation where I intend to call snd_pcm_oss_write
> directly.
> 
> What exactly happens is - the open and all the initial ioctl calls are
> done by the oss application. But the write call of the oss application
> is not done but it is done by some other task.
> 
>         So what I do is, when snd_pcm_oss_open gets called, I store the
> -- struct file *file -- in my own pointer, say, gfile.
> 
> Then I use this pointer, -gfile- in snd_pcm_oss_write() when I call the
> function directly.  But apparently this much is not enough. The direct
> write call crashes.  If you can please tell me what else needs to be
> done for the call to get through, it will be of great help.

Why you do these very ugly things? It seems that you're calling internal 
functions of the OSS emulation in the kernel space.

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project  http://www.alsa-project.org
SuSE Linux    http://www.suse.com



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf