At Fri, 6 Oct 2006 08:41:35 -0400, Eduardo Valentin wrote: > > Hello Takashi, > > > Thanks for your response. > > On 10/5/06, Takashi Iwai <tiwai@xxxxxxx> wrote: > > At Thu, 5 Oct 2006 10:26:18 -0400, > > Eduardo Valentin wrote: > > > > > > Hello all, > > > > > > > > > I'd like to announce an alsa plugin project to add support for > > > ALSA application on nokia 770. I'd like also to ask you comments and > > > suggestions about the code. > > > > > > Although n770 hasn't ALSA kernel driver, it is possible to write a > > > user-space driver to communicate with n770's audio system. > > > > Great, does the plugin work well? > > > yes, it does. I tested it with aplay, arecord, alsamixer, amixer, > mplayer and alsaplayer. Good to hear :) > Of course, there are some issues. There is a list of limitations in > the end of REAME file. I'll put it here: > > - Some application does not recognize the plugin > (ekiga, for example). I think that they look for real card. This is a generic problem right now. We'll need an device enumeration API for covering this issue. > These are related to the n770 audio system: > > - While the plugin is using a pcm task node, another applications, > for example gstreamer, can not use the same task node. This will cause > unexpected behaviour. The software-mixing of plugins is another issue to fix... > - To prevent more than one application access per task node, I need to do > a processes synchronization. I did it using semaphores from libc (sys/sem.h). > However, If an application does not close alsa device properly, this plugin > will not have chance to release all reserved resouces. One expected > behaviour in this case is to have -EBUSY error for following applications > whose try to open the same alsa device. This issue was partialy solved > (version 0.6) > with __attribute__((destructor)) functions. But if the application > receives an uncaught signal, resources may be kept unreleased. Hm, this sounds not too easy. > - If many requests to volume information read / write is done in the > same alsa device while it is being used to do playback, this playback > could be affected and some little stops can be heard. So, some kind of QoS is needed here. > > Do you think of merging this to upstream (likely in alsa-plugins > > repository)? > > It would be a great. But how would it happen? What is the > process/requirements to merge it? Simply send us patches, alsa-devel ML (and Cc to developer(s) would be appreciated). We'll review the code and merge to ALSA HG tree. It'll be included in the released version eventually later. The further changes after merge are done by sending patches to us, too. Preferred patch formats are with unified-diff together with changelog and signed-off-by lines just like the kernel patch. Since your plugin requires no special library, no extra check wouldn't be necessary for configure.in. Just add directory including Makefile.am and sources, and add that directory in AC_OUTPUT_FILES in configure.in. The document should go to doc directory. Thanks, Takashi ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/alsa-devel
