[ 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 _______________________________________________ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
