poll_descriptors_count

poll_descriptors_count

[Joshua Haberman]

Hello,

int snd_pcm_poll_descriptors_count(snd_pcm_t *pcm)
{
    assert(pcm);
    return 1;
}

I don't understand: why the abstraction for the number of poll
descriptors when it is always 1?  What could change in the future to
require more poll descriptors per stream?

Also, how should programs interpret multiple poll descriptors: if the
poll succeeds on some descriptors but not others, does this mean the
stream is only "partially" ready?

Also, is snd_pcm_poll_descriptors_revents() understood to return the
events that have triggered on just *one* poll descriptor or on *all*?  In
other words, are you ANDing bitmasks or ORing them?  Right now the
semantics are impossible to deduce because the function just returns the
revents verbatim since there is only one poll descriptor.

Josh


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

Re: poll_descriptors_count

[Paul Davis]

>int snd_pcm_poll_descriptors_count(snd_pcm_t *pcm)
>{
>    assert(pcm);
>    return 1;
>}
>
>I don't understand: why the abstraction for the number of poll
>descriptors when it is always 1?  What could change in the future to
>require more poll descriptors per stream?

it could already return more than 1 if the implementation of the
"shared" PCM type was altered. its that kind of reason that explains
the use of the abstraction, i think.

>Also, how should programs interpret multiple poll descriptors: if the
>poll succeeds on some descriptors but not others, does this mean the
>stream is only "partially" ready?

yes. see the internals of JACK's jack/drivers/alsa/alsa_driver.c

>Also, is snd_pcm_poll_descriptors_revents() understood to return the
>events that have triggered on just *one* poll descriptor or on *all*?  In
>other words, are you ANDing bitmasks or ORing them?  Right now the
>semantics are impossible to deduce because the function just returns the
>revents verbatim since there is only one poll descriptor.

The semantics are those of POSIX poll(2): it returns the status for
each file descriptor. ALSA's low level and mid level drivers don't
modify this in anyway. If there 3 fd's for playback and 2 for capture,
then the return data would indicate status for each of the 5 fd's
(assuming you asked for it for all 5).

--p



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

Re: poll_descriptors_count

[Joshua Haberman]

* Paul Davis (pbd@op.net) wrote:
> >Also, how should programs interpret multiple poll descriptors: if the
> >poll succeeds on some descriptors but not others, does this mean the
> >stream is only "partially" ready?
> 
> yes. see the internals of JACK's jack/drivers/alsa/alsa_driver.c

Honestly, I'm afraid to look at that file too carefully since it is GPL
and PortAudio is BSD.  This puts me in kind of a weird situation.

> >Also, is snd_pcm_poll_descriptors_revents() understood to return the
> >events that have triggered on just *one* poll descriptor or on *all*?  In
> >other words, are you ANDing bitmasks or ORing them?  Right now the
> >semantics are impossible to deduce because the function just returns the
> >revents verbatim since there is only one poll descriptor.
> 
> The semantics are those of POSIX poll(2): it returns the status for
> each file descriptor. ALSA's low level and mid level drivers don't
> modify this in anyway. If there 3 fd's for playback and 2 for capture,
> then the return data would indicate status for each of the 5 fd's
> (assuming you asked for it for all 5).

The prototype for this function is:

int snd_pcm_poll_descriptors_revents  ( snd_pcm_t *pcm,
                                        struct pollfd *pfds,
                                        unsigned int   nfds,
                                        unsigned short *   revents
                                      )

Are you saying that the revents paramter is treated as an array?  I was
under the impression that it is treated as a pointer to a single short.
This code fragment from test/pcm.c seems to confirm this interpretation:

static int wait_for_poll(snd_pcm_t *handle, struct pollfd *ufds, unsigned
                         int count)
{
    unsigned short revents;

    while (1) {
        poll(ufds, count, -1);
        snd_pcm_poll_descriptors_revents(handle, ufds, count, &revents);
        if (revents & POLLERR)
            return -EIO;
        if (revents & POLLOUT)
            return 0;
    }
}

This gives me the impression that snd_pcm_poll_descriptors_revents() is a
function that somehow "summarizes" all of the pfds into a single revents
that speaks to the status of the entire PCM handle.

Josh


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

Re: poll_descriptors_count

[Paul Davis]

>> yes. see the internals of JACK's jack/drivers/alsa/alsa_driver.c
>
>Honestly, I'm afraid to look at that file too carefully since it is GPL
>and PortAudio is BSD.  This puts me in kind of a weird situation.

nobody is going to come after you for an "extremely similar
implementation". the GPL doesn't prohibit intellectual inspiration -
you just can't copy & paste.

>> >Also, is snd_pcm_poll_descriptors_revents() understood to return the
>> >events that have triggered on just *one* poll descriptor or on *all*?  In
>> >other words, are you ANDing bitmasks or ORing them?  Right now the
>> >semantics are impossible to deduce because the function just returns the
>> >revents verbatim since there is only one poll descriptor.
>> 
>> The semantics are those of POSIX poll(2): it returns the status for

Drat! I missed that fact that you were talking about
snd_pcm_poll_descriptors_revents(), not poll(2) revents. 

I don't use this function at all, considering it something of it a
band-aid. 

>Are you saying that the revents paramter is treated as an array?  I was
>under the impression that it is treated as a pointer to a single short.
>This code fragment from test/pcm.c seems to confirm this interpretation:

You're right. But then again, I don't use wait_for_poll or the variant
on its theme that exists in alsa-lib, because its not written
correctly for multithreaded and some other code (mostly related to
handling errors while blocked on poll(2)).

>This gives me the impression that snd_pcm_poll_descriptors_revents() is a
>function that somehow "summarizes" all of the pfds into a single revents
>that speaks to the status of the entire PCM handle.

Yes, that's definitely the intent of the function.

--p







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

Re: poll_descriptors_count

[Jaroslav Kysela]

On Mon, 1 Jul 2002, Joshua Haberman wrote:

> * Paul Davis (pbd@op.net) wrote:
> > >Also, how should programs interpret multiple poll descriptors: if the
> > >poll succeeds on some descriptors but not others, does this mean the
> > >stream is only "partially" ready?
> > 
> > yes. see the internals of JACK's jack/drivers/alsa/alsa_driver.c
> 
> Honestly, I'm afraid to look at that file too carefully since it is GPL
> and PortAudio is BSD.  This puts me in kind of a weird situation.
> 
> > >Also, is snd_pcm_poll_descriptors_revents() understood to return the
> > >events that have triggered on just *one* poll descriptor or on *all*?  In
> > >other words, are you ANDing bitmasks or ORing them?  Right now the
> > >semantics are impossible to deduce because the function just returns the
> > >revents verbatim since there is only one poll descriptor.
> > 
> > The semantics are those of POSIX poll(2): it returns the status for
> > each file descriptor. ALSA's low level and mid level drivers don't
> > modify this in anyway. If there 3 fd's for playback and 2 for capture,
> > then the return data would indicate status for each of the 5 fd's
> > (assuming you asked for it for all 5).
> 
> The prototype for this function is:
> 
> int snd_pcm_poll_descriptors_revents  ( snd_pcm_t *pcm,
>                                         struct pollfd *pfds,
>                                         unsigned int   nfds,
>                                         unsigned short *   revents
>                                       )
> 
> Are you saying that the revents paramter is treated as an array?  I was
> under the impression that it is treated as a pointer to a single short.
> This code fragment from test/pcm.c seems to confirm this interpretation:
> 
> static int wait_for_poll(snd_pcm_t *handle, struct pollfd *ufds, unsigned
>                          int count)
> {
>     unsigned short revents;
> 
>     while (1) {
>         poll(ufds, count, -1);
>         snd_pcm_poll_descriptors_revents(handle, ufds, count, &revents);
>         if (revents & POLLERR)
>             return -EIO;
>         if (revents & POLLOUT)
>             return 0;
>     }
> }
> 
> This gives me the impression that snd_pcm_poll_descriptors_revents() is a
> function that somehow "summarizes" all of the pfds into a single revents
> that speaks to the status of the entire PCM handle.

Yes, it translates multiple revents into one for application. Please, use
this function for the library flexibility.

						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

Re: poll_descriptors_count

[Joshua Haberman]

On Mon, 1 Jul 2002, Joshua Haberman wrote:
> > This gives me the impression that snd_pcm_poll_descriptors_revents() is a
> > function that somehow "summarizes" all of the pfds into a single revents
> > that speaks to the status of the entire PCM handle.

* Paul Davis (pbd@op.net) wrote:
> I don't use this function at all, considering it something of it a
> band-aid.-

* Jaroslav Kysela (perex@suse.cz) wrote:
> Yes, it translates multiple revents into one for application. Please, use
> this function for the library flexibility.

Hmm.  What do I do now?  :-)

Jaroslav, is it true what Paul says about this function not being robust
in the case of multithreaded use and poll(2) errors?  Can it be made to
be more robust?

Looking at the implementation I infer that
snd_pcm_poll_descriptors_revents() is not designed to handle pfds from
more than one stream.  Is that correct?

Josh


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

Re: poll_descriptors_count

[Jaroslav Kysela]

On Mon, 1 Jul 2002, Joshua Haberman wrote:

> On Mon, 1 Jul 2002, Joshua Haberman wrote:
> > > This gives me the impression that snd_pcm_poll_descriptors_revents() is a
> > > function that somehow "summarizes" all of the pfds into a single revents
> > > that speaks to the status of the entire PCM handle.
> 
> * Paul Davis (pbd@op.net) wrote:
> > I don't use this function at all, considering it something of it a
> > band-aid.-
> 
> * Jaroslav Kysela (perex@suse.cz) wrote:
> > Yes, it translates multiple revents into one for application. Please, use
> > this function for the library flexibility.
> 
> Hmm.  What do I do now?  :-)
> 
> Jaroslav, is it true what Paul says about this function not being robust
> in the case of multithreaded use and poll(2) errors?  Can it be made to
> be more robust?

Paul talks about snd_pcm_wait() function. True, it has limited 
functionality and can be used only for simple applications.

> Looking at the implementation I infer that
> snd_pcm_poll_descriptors_revents() is not designed to handle pfds from
> more than one stream.  Is that correct?

Yes, but don't look to the implementation. It can slightly change in the 
future. The wait_for_poll() function in alsa-lib/test/pcm.c does really 
the correct poll sequence, so use this code and don't try to do things 
differently than designed like Paul often does ;-)

						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

Re: poll_descriptors_count

[Paul Davis]

>> Jaroslav, is it true what Paul says about this function not being robust
>> in the case of multithreaded use and poll(2) errors?  Can it be made to
>> be more robust?
>
>Paul talks about snd_pcm_wait() function. True, it has limited 
>functionality and can be used only for simple applications.

this is correct - i wasn't referring to
snd_pcm_poll_descriptors_revents(), and in fact, i plan to make JACK
use this now that i see what it does.

>> Looking at the implementation I infer that
>> snd_pcm_poll_descriptors_revents() is not designed to handle pfds from
>> more than one stream.  Is that correct?
>
>Yes, but don't look to the implementation. It can slightly change in the 
>future. The wait_for_poll() function in alsa-lib/test/pcm.c does really 
>the correct poll sequence, so use this code and don't try to do things 
>differently than designed like Paul often does ;-)

The sequence is correct, but the implementation is missing some
important details. There is no test for poll return an error, such as
EINTR, which means that there is no way to get a thread running this
loop to exit without sending it SIGKILL, which pthreads doesn't do
unless explicitly asked to (pthread_kill(3)).

Secondly, the loop is based on waiting for poll() to return with a
given state (i.e. POLLIN or POLLOUT or POLLHUP set), and doesn't allow
for a timeout.

Finally, the use of wait_for_poll() in the test program is based on
non-duplex operation. Its significantly more complex to make this work
for duplex, since there are two PCM handles, and its not necessary (or
desirable) to be calling poll with the descriptors for both of them
each time. if you do, then there are many cases where poll(2) will
return immediately because one handle's descriptor(s) are ready right
away, while the other's are not. This is very inefficient. I see this
all the time with my trident and tropez+ hardware, and its been show
on ensoniq pci h/w as well. I suspect its actually true for most h/w
except the hammerfall and its cousins.

That's why the code in JACK's alsa_driver is so complex, because in
the default (full duplex case) its waiting for playback *and* capture
at the same time. it has to continually check whether one or other or
both streams are ready, and if one is not, then re-enter poll to wait
just for that stream, and not the other. If what JACK is doing is not
"as designed", then perhaps you could fill me in on the intended
method of handling this situation.

--p




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

RME+Hammerfall+.asoundrc

[Patrick Shirkey]

I have made a page for an advanced .asoundrc setup which Jeremy Hall 
submitted for his RME cards.

http://alsa.opensrc.org/index.php?page=RME+Hammerfall+.asoundrc

Can those who understand this more fully please have a brief read to 
make sure I have got the facts right?

Thx.

-- 
Patrick Shirkey - Boost Hardware Ltd.
For the discerning hardware connoisseur
Http://www.boosthardware.com
Http://www.boosthardware.com/LAU/guide/
========================================



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