* Re: Re: [Jackit-devel] alsa_driver_wait -> libasound?
2003-01-14 14:38 ` [Jackit-devel] alsa_driver_wait -> libasound? Paul Davis
@ 2003-01-14 16:31 ` Jaroslav Kysela
2003-01-14 16:42 ` Paul Davis
2003-01-14 18:55 ` Josh Haberman
2003-01-14 16:32 ` Takashi Iwai
2003-01-14 19:04 ` Josh Haberman
2 siblings, 2 replies; 13+ messages in thread
From: Jaroslav Kysela @ 2003-01-14 16:31 UTC (permalink / raw)
To: Paul Davis
Cc: Josh Haberman, jackit-devel@lists.sourceforge.net,
alsa-devel@lists.sourceforge.net
On Tue, 14 Jan 2003, Paul Davis wrote:
>
> [ cc'ed to alsa-devel ]
>
> >I think I've asked something to this effect before, but is there any
> >reason why the polling portion of alsa_driver_wait should not be in
> >libasound? It's a very complicated piece of code that performs an
> >operation that many programs are likely to want. What if it was written
> >as a companion function to snd_pcm_wait():
> >
> > int snd_pcm_wait_many( snd_pcm_t **handles, int num_handles,
> > int timeout);
> >
> >...not that JACK would have to give up its version with extra error
> >reporting and timing, but for programs with simpler needs it would be a
> >lot nicer than having to set and test all those poll conditions for all
> >of the pfds on all the handles.
> >
> >I should probably ask this on the ALSA list, but I'm more familiar with
> >the people here. Any reason why this couldn't go into libasound?
>
> seems like a good idea to me, although there is a small problem. the
> current snd_pcm_wait function waits till the handles is
> readable/writable, whereas the JACK code waits till the handles all
> have a certain minimum amount of data/space. this is a subtle but
> rather important difference.
>
> that said, i think it would be great if this found its way into libasound.
I wonder why to implement this function when one can link more pcm streams
with "snd_pcm_link()" together? Then polling one stream is sufficient when
streams are hardware synchronized.
Jaroslav
-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SuSE Labs
-------------------------------------------------------
This SF.NET email is sponsored by: FREE SSL Guide from Thawte
are you planning your Web Server Security? Click here to get a FREE
Thawte SSL guide and find the answers to all your SSL security issues.
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Re: [Jackit-devel] alsa_driver_wait -> libasound?
2003-01-14 16:31 ` Jaroslav Kysela
@ 2003-01-14 16:42 ` Paul Davis
2003-01-14 19:35 ` Jaroslav Kysela
2003-01-14 18:55 ` Josh Haberman
1 sibling, 1 reply; 13+ messages in thread
From: Paul Davis @ 2003-01-14 16:42 UTC (permalink / raw)
To: Jaroslav Kysela
Cc: Josh Haberman, jackit-devel@lists.sourceforge.net,
alsa-devel@lists.sourceforge.net
>> that said, i think it would be great if this found its way into libasound.
>
>I wonder why to implement this function when one can link more pcm streams
>with "snd_pcm_link()" together? Then polling one stream is sufficient when
>streams are hardware synchronized.
why don't you go read the function in question and then consider
whether that would actually accomplish anything like what it does? i
say that because i don't think its even close.
--p
-------------------------------------------------------
This SF.NET email is sponsored by: FREE SSL Guide from Thawte
are you planning your Web Server Security? Click here to get a FREE
Thawte SSL guide and find the answers to all your SSL security issues.
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Re: [Jackit-devel] alsa_driver_wait -> libasound?
2003-01-14 16:42 ` Paul Davis
@ 2003-01-14 19:35 ` Jaroslav Kysela
2003-01-14 20:23 ` Paul Davis
0 siblings, 1 reply; 13+ messages in thread
From: Jaroslav Kysela @ 2003-01-14 19:35 UTC (permalink / raw)
To: Paul Davis
Cc: Josh Haberman, jackit-devel@lists.sourceforge.net,
alsa-devel@lists.sourceforge.net
On Tue, 14 Jan 2003, Paul Davis wrote:
> >> that said, i think it would be great if this found its way into libasound.
> >
> >I wonder why to implement this function when one can link more pcm streams
> >with "snd_pcm_link()" together? Then polling one stream is sufficient when
> >streams are hardware synchronized.
>
> why don't you go read the function in question and then consider
> whether that would actually accomplish anything like what it does? i
> say that because i don't think its even close.
Why not? In the perfect world, when the hardware supports paralel start of
multiple streams and application sets all equal parameters for all
streams, the pointers to ring buffer are equal. Thus checking of only one
stream is quite sufficient before r/w operation.
When hardware does not support paralel start, but the parts are running at
same clock, then you can expect that last started stream in serialized
start sequence (as ALSA driver does) has valid position and all other
streams, too.
And if clock are not synced, you cannot expect nothing and your code will
fail later (when you don't do clock corrections), too.
So resume:
1) use snd_pcm_link to link all streams
2) start first linked stream (thus all in paralel or serial or combination
sequence)
3) poll the last stream handle for valid position
And you don't need your complicate function.
Jaroslav
-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SuSE Labs
-------------------------------------------------------
This SF.NET email is sponsored by: Take your first step towards giving
your online business a competitive advantage. Test-drive a Thawte SSL
certificate - our easy online guide will show you how. Click here to get
started: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0027en
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Re: [Jackit-devel] alsa_driver_wait -> libasound?
2003-01-14 19:35 ` Jaroslav Kysela
@ 2003-01-14 20:23 ` Paul Davis
2003-01-16 0:14 ` Josh Haberman
0 siblings, 1 reply; 13+ messages in thread
From: Paul Davis @ 2003-01-14 20:23 UTC (permalink / raw)
To: Jaroslav Kysela
Cc: Josh Haberman, jackit-devel@lists.sourceforge.net,
alsa-devel@lists.sourceforge.net
>So resume:
>
>1) use snd_pcm_link to link all streams
we already have hardware that doesn't support linkage between
playback+capture.
>2) start first linked stream (thus all in paralel or serial or combination
> sequence)
>3) poll the last stream handle for valid position
>
>And you don't need your complicate function.
i just can't agree with that. on return from JACK's alsa_driver_wait, the
caller knows:
* how many frames are available (rounded to whole periods)
* what delay was encountered in waiting for the data/space
* whether an xrun occured
* if some other error occured
your proposed snd_pcm_wait_many() doesn't do any of that.
i think that josh's point was perhaps a little different than you are
thinking. i don't think he was suggesting a version of snd_pcm_wait()
that waited on multiple handles instead of just one. i think he was
suggesting a function that does something that most applications need:
to wait until a known-sized chunk of data/space (or multiple thereof)
is ready on *all* handles being used. since doing this involves much
more than just calling poll(), which is fundamentally all that
snd_pcm_wait() does, so would the multi-handle version.
--p
-------------------------------------------------------
This SF.NET email is sponsored by: Take your first step towards giving
your online business a competitive advantage. Test-drive a Thawte SSL
certificate - our easy online guide will show you how. Click here to get
started: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0027en
^ permalink raw reply [flat|nested] 13+ messages in thread* Re: Re: [Jackit-devel] alsa_driver_wait -> libasound?
2003-01-14 20:23 ` Paul Davis
@ 2003-01-16 0:14 ` Josh Haberman
0 siblings, 0 replies; 13+ messages in thread
From: Josh Haberman @ 2003-01-16 0:14 UTC (permalink / raw)
To: jackit-devel, alsa-devel
On Tue, 2003-01-14 at 12:23, Paul Davis wrote:
> >2) start first linked stream (thus all in paralel or serial or combination
> > sequence)
> >3) poll the last stream handle for valid position
> >
> >And you don't need your complicate function.
>
> i just can't agree with that. on return from JACK's alsa_driver_wait, the
> caller knows:
>
> * how many frames are available (rounded to whole periods)
> * what delay was encountered in waiting for the data/space
> * whether an xrun occured
> * if some other error occured
>
> your proposed snd_pcm_wait_many() doesn't do any of that.
>
> i think that josh's point was perhaps a little different than you are
> thinking. i don't think he was suggesting a version of snd_pcm_wait()
> that waited on multiple handles instead of just one. i think he was
> suggesting a function that does something that most applications need:
>
> to wait until a known-sized chunk of data/space (or multiple thereof)
> is ready on *all* handles being used. since doing this involves much
> more than just calling poll(), which is fundamentally all that
> snd_pcm_wait() does, so would the multi-handle version.
You're right, that is really what I'm looking for. Maybe I could have
avoided confusion by not comparing it with snd_pcm_wait to begin with.
More than anything else, what I want to avoid having to do is set up and
interpret the results of poll() manually. For example, I infer by
reading the JACK code that POLLERR means an xrun was detected. It would
be much easier to receive this information from an ALSA function.
So perhaps a revised function signature could be:
int snd_pcm_poll( snd_pcm_t **handles, int num_handles, int timeout )
returns:
the number of frames available on all handles, or negative if an
error occured. -EPIPE if an xrun occured, -ETIMEDOUT if not all
handles were ready before timeout.
Originally I was going to write "returns the number of frames on all
handles, rounded down to the greatest complete period," but I realized
that the period size could be different for different handles.
Josh
-------------------------------------------------------
This SF.NET email is sponsored by: A Thawte Code Signing Certificate
is essential in establishing user confidence by providing assurance of
authenticity and code integrity. Download our Free Code Signing guide:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0028en
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Re: [Jackit-devel] alsa_driver_wait -> libasound?
2003-01-14 16:31 ` Jaroslav Kysela
2003-01-14 16:42 ` Paul Davis
@ 2003-01-14 18:55 ` Josh Haberman
2003-01-14 19:25 ` Jaroslav Kysela
1 sibling, 1 reply; 13+ messages in thread
From: Josh Haberman @ 2003-01-14 18:55 UTC (permalink / raw)
To: alsa-devel@lists.sourceforge.net
On Tue, 2003-01-14 at 08:31, Jaroslav Kysela wrote:
> I wonder why to implement this function when one can link more pcm streams
> with "snd_pcm_link()" together? Then polling one stream is sufficient when
> streams are hardware synchronized.
This reminds me of another question I had: can any two streams be linked
together or do they need to be on the same device? Is it reasonable to
assume that linking two streams will always succeed?
Josh
-------------------------------------------------------
This SF.NET email is sponsored by: Take your first step towards giving
your online business a competitive advantage. Test-drive a Thawte SSL
certificate - our easy online guide will show you how. Click here to get
started: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0027en
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Re: [Jackit-devel] alsa_driver_wait -> libasound?
2003-01-14 18:55 ` Josh Haberman
@ 2003-01-14 19:25 ` Jaroslav Kysela
0 siblings, 0 replies; 13+ messages in thread
From: Jaroslav Kysela @ 2003-01-14 19:25 UTC (permalink / raw)
To: Josh Haberman; +Cc: alsa-devel@lists.sourceforge.net
On 14 Jan 2003, Josh Haberman wrote:
> On Tue, 2003-01-14 at 08:31, Jaroslav Kysela wrote:
> > I wonder why to implement this function when one can link more pcm streams
> > with "snd_pcm_link()" together? Then polling one stream is sufficient when
> > streams are hardware synchronized.
>
> This reminds me of another question I had: can any two streams be linked
> together or do they need to be on the same device? Is it reasonable to
> assume that linking two streams will always succeed?
There are no restrictions, except - if you don't have clock sync in
hardware, there is no guarantee that streams will have same positions.
Also, when hardware does not allow synchronized start (paralel) then the
start sequence is serialized (thus some streams might be started a bit
later).
The software (application) needs to handle these situations.
Jaroslav
-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SuSE Labs
-------------------------------------------------------
This SF.NET email is sponsored by: Take your first step towards giving
your online business a competitive advantage. Test-drive a Thawte SSL
certificate - our easy online guide will show you how. Click here to get
started: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0027en
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Re: [Jackit-devel] alsa_driver_wait -> libasound?
2003-01-14 14:38 ` [Jackit-devel] alsa_driver_wait -> libasound? Paul Davis
2003-01-14 16:31 ` Jaroslav Kysela
@ 2003-01-14 16:32 ` Takashi Iwai
2003-01-14 16:47 ` Paul Davis
2003-01-14 19:04 ` Josh Haberman
2 siblings, 1 reply; 13+ messages in thread
From: Takashi Iwai @ 2003-01-14 16:32 UTC (permalink / raw)
To: Paul Davis; +Cc: Josh Haberman, jackit-devel, alsa-devel
At Tue, 14 Jan 2003 09:38:51 -0500,
Paul Davis wrote:
>
>
> [ cc'ed to alsa-devel ]
>
> >I think I've asked something to this effect before, but is there any
> >reason why the polling portion of alsa_driver_wait should not be in
> >libasound? It's a very complicated piece of code that performs an
> >operation that many programs are likely to want. What if it was written
> >as a companion function to snd_pcm_wait():
> >
> > int snd_pcm_wait_many( snd_pcm_t **handles, int num_handles,
> > int timeout);
> >
> >...not that JACK would have to give up its version with extra error
> >reporting and timing, but for programs with simpler needs it would be a
> >lot nicer than having to set and test all those poll conditions for all
> >of the pfds on all the handles.
> >
> >I should probably ask this on the ALSA list, but I'm more familiar with
> >the people here. Any reason why this couldn't go into libasound?
>
> seems like a good idea to me, although there is a small problem. the
> current snd_pcm_wait function waits till the handles is
> readable/writable, whereas the JACK code waits till the handles all
> have a certain minimum amount of data/space. this is a subtle but
> rather important difference.
i thought that snd_pcm_wait() waits until data/space of
swparams->avail_min become available, too?
>
> that said, i think it would be great if this found its way into libasound.
is the below code ok?
int snd_pcm_wait_many(snd_pcm_t **handles, int num_handles, int timeout)
{
struct pollfd *pfds;
int i, err;
pfds = (struct pollfd *)alloca(sizeof(*pfds) * num_handles);
if (! pfds)
reutrn -ENOMEM;
for (i = 0; i < num_handles; i++) {
err = snd_pcm_poll_descriptors(handles[i], &pfds[i], 1);
assert(err == 1);
}
err = poll(pfds, num_handles, timeout);
if (err < 0)
return -errno;
return err > 0 ? 1 : 0;
}
Takashi
-------------------------------------------------------
This SF.NET email is sponsored by: FREE SSL Guide from Thawte
are you planning your Web Server Security? Click here to get a FREE
Thawte SSL guide and find the answers to all your SSL security issues.
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en
^ permalink raw reply [flat|nested] 13+ messages in thread* Re: Re: [Jackit-devel] alsa_driver_wait -> libasound?
2003-01-14 16:32 ` Takashi Iwai
@ 2003-01-14 16:47 ` Paul Davis
2003-01-14 17:03 ` Takashi Iwai
0 siblings, 1 reply; 13+ messages in thread
From: Paul Davis @ 2003-01-14 16:47 UTC (permalink / raw)
To: Takashi Iwai; +Cc: Josh Haberman, jackit-devel, alsa-devel
>> that said, i think it would be great if this found its way into libasound.
>
>is the below code ok?
>
>int snd_pcm_wait_many(snd_pcm_t **handles, int num_handles, int timeout)
>{
> struct pollfd *pfds;
> int i, err;
> pfds = (struct pollfd *)alloca(sizeof(*pfds) * num_handles);
> if (! pfds)
> reutrn -ENOMEM;
> for (i = 0; i < num_handles; i++) {
> err = snd_pcm_poll_descriptors(handles[i], &pfds[i], 1);
> assert(err == 1);
> }
> err = poll(pfds, num_handles, timeout);
> if (err < 0)
> return -errno;
> return err > 0 ? 1 : 0;
>}
this isn't even close. the function in question waits until each and
every handle is ready. that means reentering poll over and over again
until each handle is ready, making sure to only poll on the handles
that are not yet ready (because otherwise poll returns immediately).
the semantics are not "wait for any one many", its "wait for all or an
error".
if someone wants to write the function that joshua was thinking of, i
would suggest starting with the JACK alsa function and explain how it
can be made simpler.
--p
-------------------------------------------------------
This SF.NET email is sponsored by: FREE SSL Guide from Thawte
are you planning your Web Server Security? Click here to get a FREE
Thawte SSL guide and find the answers to all your SSL security issues.
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en
^ permalink raw reply [flat|nested] 13+ messages in thread* Re: Re: [Jackit-devel] alsa_driver_wait -> libasound?
2003-01-14 16:47 ` Paul Davis
@ 2003-01-14 17:03 ` Takashi Iwai
0 siblings, 0 replies; 13+ messages in thread
From: Takashi Iwai @ 2003-01-14 17:03 UTC (permalink / raw)
To: Paul Davis; +Cc: Josh Haberman, jackit-devel, alsa-devel
At Tue, 14 Jan 2003 11:47:58 -0500,
Paul Davis wrote:
>
> >> that said, i think it would be great if this found its way into libasound.
> >
> >is the below code ok?
> >
> >int snd_pcm_wait_many(snd_pcm_t **handles, int num_handles, int timeout)
> >{
> > struct pollfd *pfds;
> > int i, err;
> > pfds = (struct pollfd *)alloca(sizeof(*pfds) * num_handles);
> > if (! pfds)
> > reutrn -ENOMEM;
> > for (i = 0; i < num_handles; i++) {
> > err = snd_pcm_poll_descriptors(handles[i], &pfds[i], 1);
> > assert(err == 1);
> > }
> > err = poll(pfds, num_handles, timeout);
> > if (err < 0)
> > return -errno;
> > return err > 0 ? 1 : 0;
> >}
>
> this isn't even close. the function in question waits until each and
> every handle is ready. that means reentering poll over and over again
> until each handle is ready, making sure to only poll on the handles
> that are not yet ready (because otherwise poll returns immediately).
>
> the semantics are not "wait for any one many", its "wait for all or an
> error".
ah, now got the meaning. so, something like that...
// set up pfds...
...
for (;;) {
err = poll(pfds, num_handles, timeout);
if (err < 0)
return -errno;
else if (err == 0)
return 0;
i = 0;
while (i < num_handles) {
if (pfds[i].revents & POLLOUT) {
num_handles--;
memmove(pfds + i + 1, pfds + i,
sizeof(*pfds) * (num_handles - i));
} else
i++;
}
}
return 1;
Takashi
-------------------------------------------------------
This SF.NET email is sponsored by: FREE SSL Guide from Thawte
are you planning your Web Server Security? Click here to get a FREE
Thawte SSL guide and find the answers to all your SSL security issues.
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Re: [Jackit-devel] alsa_driver_wait -> libasound?
2003-01-14 14:38 ` [Jackit-devel] alsa_driver_wait -> libasound? Paul Davis
2003-01-14 16:31 ` Jaroslav Kysela
2003-01-14 16:32 ` Takashi Iwai
@ 2003-01-14 19:04 ` Josh Haberman
2003-01-14 19:20 ` Paul Davis
2 siblings, 1 reply; 13+ messages in thread
From: Josh Haberman @ 2003-01-14 19:04 UTC (permalink / raw)
To: Paul Davis; +Cc: jackit-devel, alsa-devel
On Tue, 2003-01-14 at 06:38, Paul Davis wrote:
> [ cc'ed to alsa-devel ]
>
> >I think I've asked something to this effect before, but is there any
> >reason why the polling portion of alsa_driver_wait should not be in
> >libasound? It's a very complicated piece of code that performs an
> >operation that many programs are likely to want. What if it was written
> >as a companion function to snd_pcm_wait():
> >
> > int snd_pcm_wait_many( snd_pcm_t **handles, int num_handles,
> > int timeout);
> >
> >...not that JACK would have to give up its version with extra error
> >reporting and timing, but for programs with simpler needs it would be a
> >lot nicer than having to set and test all those poll conditions for all
> >of the pfds on all the handles.
> >
> >I should probably ask this on the ALSA list, but I'm more familiar with
> >the people here. Any reason why this couldn't go into libasound?
>
> seems like a good idea to me, although there is a small problem. the
> current snd_pcm_wait function waits till the handles is
> readable/writable, whereas the JACK code waits till the handles all
> have a certain minimum amount of data/space.
It does? Reading the function, I cannot find where it checks to make
sure that a minimum number of frames are available. The main loop is
while( need_capture || need_playback ), and these two conditions are
satisfied simply by having the poll() not time out on the appropriate
pfds. Later it checks to see how many frames are available, but never
branches based on the number.
Josh
-------------------------------------------------------
This SF.NET email is sponsored by: Take your first step towards giving
your online business a competitive advantage. Test-drive a Thawte SSL
certificate - our easy online guide will show you how. Click here to get
started: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0027en
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Re: [Jackit-devel] alsa_driver_wait -> libasound?
2003-01-14 19:04 ` Josh Haberman
@ 2003-01-14 19:20 ` Paul Davis
0 siblings, 0 replies; 13+ messages in thread
From: Paul Davis @ 2003-01-14 19:20 UTC (permalink / raw)
To: Josh Haberman; +Cc: jackit-devel, alsa-devel
>> seems like a good idea to me, although there is a small problem. the
>> current snd_pcm_wait function waits till the handles is
>> readable/writable, whereas the JACK code waits till the handles all
>> have a certain minimum amount of data/space.
>
>It does? Reading the function, I cannot find where it checks to make
>sure that a minimum number of frames are available. The main loop is
>while( need_capture || need_playback ), and these two conditions are
>satisfied simply by having the poll() not time out on the appropriate
>pfds. Later it checks to see how many frames are available, but never
>branches based on the number.
i'm sorry, you're right about that. it returns the minimum number of frames
that are available modulo the period size (i.e. the number of whole
periods that can be processed at this time, expressed in frames). this
is quite different than the current function of snd_pcm_wait(), which
merely waits till a handle is ready (or has an error) according to poll.
--p
-------------------------------------------------------
This SF.NET email is sponsored by: Take your first step towards giving
your online business a competitive advantage. Test-drive a Thawte SSL
certificate - our easy online guide will show you how. Click here to get
started: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0027en
^ permalink raw reply [flat|nested] 13+ messages in thread