Re: [Jackit-devel] alsa_driver_wait -> libasound?

Re: [Jackit-devel] alsa_driver_wait -> libasound?

[Paul Davis]

 [ 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.

--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

Re: Re: [Jackit-devel] alsa_driver_wait -> libasound?

[Jaroslav Kysela]

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

Re: Re: [Jackit-devel] alsa_driver_wait -> libasound?

[Paul Davis]

>> 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

Re: Re: [Jackit-devel] alsa_driver_wait -> libasound?

[Jaroslav Kysela]

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

Re: Re: [Jackit-devel] alsa_driver_wait -> libasound?

[Paul Davis]

>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

Re: Re: [Jackit-devel] alsa_driver_wait -> libasound?

[Josh Haberman]

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

Re: Re: [Jackit-devel] alsa_driver_wait -> libasound?

[Josh Haberman]

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

Re: Re: [Jackit-devel] alsa_driver_wait -> libasound?

[Jaroslav Kysela]

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

Re: Re: [Jackit-devel] alsa_driver_wait -> libasound?

[Takashi Iwai]

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

Re: Re: [Jackit-devel] alsa_driver_wait -> libasound?

[Paul Davis]

>> 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

Re: Re: [Jackit-devel] alsa_driver_wait -> libasound?

[Takashi Iwai]

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

Re: Re: [Jackit-devel] alsa_driver_wait -> libasound?

[Josh Haberman]

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

Re: Re: [Jackit-devel] alsa_driver_wait -> libasound?

[Paul Davis]

>> 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