Re: [Alsa-devel] Status of ALSA documentation?
Paul sent me a revised edition of the alsa home page with more of a current feel than the previous version so you can find it here: http://www.boosthardware.com/LAU/alsa/index4-pd.html I have retained the link to the LAU-guide because I know it helps new users to find needed information. However for those of you who are anti my link to Boost Hardware being so prominent I have restructured the page slightly. I intend to start getting in knee deep on the alsa-howto wiki which Mark created. Once that is in more of a working condition I will add that and the new midi howto (at the linux doc project) to the LAU-guide too. I will also attempt to create a docbook version of all the info in the alsa-howto wiki. Once I get cosy with docbook markup. -- Patrick Shirkey - Boost Hardware Ltd For the discerning hardware connoisseur Http://www.boosthardware.com Http://www.boosthardware.com/LAU/Linux_Audio_Users_Guide/ _ Want a new web-based email account ? --- http://www.firstlinux.net _ You deserve a better email address! Get personalized email @yourname or @yourcompany from Everyone.net -- http://www.everyone.net?tag ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] Status of ALSA documentation?
--- Paul Davis [EMAIL PROTECTED] wrote: I disagree. I just went through the process of teaching a friend how to use li nux and he needed every piece of information I could give him. It is my opinio n that repetiton and hand holding is the key to success for all newbies. (Base d on teaching ESL for the past two years and teaching myself how to use linux for the past 3). well, then i'd use language like: edit the file /foo/bar/baz. you can use any text editor for this, including such programs as vi and emacs. you cannot usefully make a document on a specific audio interface into a tutorial on basic unix system skills. i think that someone who doesn't know how to use a text editor will *not* be able to follow your instructions without additional help from someone else. That's a good point. Someone else also mentioned why not have a more user friendly example. I will eventually. I think I will make a page with maybe 5 examples of how to edit a file to make a working modules.conf and provide it as a link in the doc. The info in the doc will be as above. If anybody wants to write a corresponding example for their favorite editor please send it to me. It should take about 1 minute. The text that needs changing is this: - To copy and paste the above to your /etc/modules.conf file follow these instructions. Using the vi text editor: Change to root. su Open the file with your favorite text editor. vi /etc/modules.conf Copy the above text to the bottom of the file by highlighting it with your mouse and paste it by clicking in the appropriate spot with your middle mouse button. If you don't have a middle mouse button then you can press the left and right button at the same time. If you use the above text editor you will need to put the cursor in the correct place and type: a Which allows you to write to the file. Then save the file. If you use the above text editor type: ESC q then type: wq! and press enter. - The problem is that these documents will become reference sheets for each soundcard. Browsing through a couple of pages of install info for ALSA every time you want to check on that detail about the CmRMiceCreatEmu Y18kJA card is going to annoy most people. Hence the hyperlinks in the contents of the page. Once I learn some more comma nds for the wiki then having these shouldn't be a problem. Someone correct me if I'm wrong. I would just invert the order of the information. Put the card specific info at the top, and follow it with the generic information. That works too. But more experienced users can easily follow a link whereas the newbies will get very confused with lots of technical info at the top of the document. I think a linked TOC is a good compromise. I'm attacking the install howto from the point of view of a complete newbie. Someone who needs to be spoonfeed. Thats a different goal than I was originally outlining. We get lots of mail on alsa-devel (and probably even more on alsa-user) asking how do i use this card? or how do i get this card to do ...?. the mail isn't from complete newbies, who probably wouldn't even know that alsa-devel exists, but from people who know how to use a text editor yet have no clue how to get their audio interface working. Thats the audience I was aiming for. Sure, currently we do but in the not too distant future we may be overloaded with new users who don't know this information. Better to cover our bases now than field hundreds of the same questions later. We just need to organise the page in a layout that makes it as easy as possible for everyone. -- Patrick Shirkey - Boost Hardware Ltd For the discerning hardware connoisseur Http://www.boosthardware.com Http://www.boosthardware.com/LAU/Linux_Audio_Users_Guide/ _ Want a new web-based email account ? --- http://www.firstlinux.net _ You deserve a better email address! Get personalized email @yourname or @yourcompany from Everyone.net -- http://www.everyone.net?tag ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
RE: [Alsa-devel] question regarding latest CS4205 laptop soundcard driver
I have a notebook with an es1969 which can mix 4 streams in hardware. -- Patrick Shirkey - Boost Hardware Ltd For the discerning hardware connoisseur Http://www.boosthardware.com Http://www.boosthardware.com/LAU/Linux_Audio_Users_Guide/ --- Ivica Bukvic [EMAIL PROTECTED] wrote: First off, thanks for your reply. I am, however, baffled by what you had to say. Crystal company claims complete Linux friendliness and I've seen several sites which carry detailed specs of the CS4205 chip in PDF file, so I am not sure what aspect of the sound chip is missing for such information to be complete. Could you please clarify your point? Also, is there a way to contact Crystal company and request additional info? Finally, if this soundcard is not capable of hardware downmixing, is there ANY laptop soundcard at all out there that IS capable of doing that. P.S. What about Yamaha/Intel 753 chip that is found in the Toshiba Satellite 5005's? Thanks for your assistance! Ico -Original Message- From: Patrick Shirkey [mailto:[EMAIL PROTECTED]] Sent: Tuesday, February 26, 2002 2:25 AM To: Ivica Bukvic; [EMAIL PROTECTED] Subject: Re: [Alsa-devel] question regarding latest CS4205 laptop soundcard driver --- Ivica Bukvic [EMAIL PROTECTED] wrote: Hi all! I have a quick question regarding the latest CrystalClear soundcard that is found in Dell Inspirons and other laptops (model name CS4205). My understanding is that the maker of this DSP chip is rather Linux friendly, so my question is does the driver for this soundcard (which I believe is Intel810 and has been reported to be working in Linux) supports hardware mixing (i.e. opening sound device multiple times as is the case with SBLive!), since this card also advertises having hardware mixer like SBLive! does. I=92ve also heard that most other modern mainstream soundcards have that capability and some of them simply don=92t do that due to lack of documentation (i.e. Ess maestro 3i). So what is then the case with this one and how does it stack-up against other mobile built-in soundcards? IIRC The docs for this chip are not sufficient for the hardware mixing to be used. In regards to how well it works I have had ok sound from it and have recorded quite clean through it but it is nothing special IMO. -- Patrick Shirkey - Boost Hardware Ltd For the discerning hardware connoisseur Http://www.boosthardware.com Http://www.boosthardware.com/LAU/Linux_Audio_Users_Guide/ Ivica Ico Bukvic, composer, multimedia sculptor, programmer, webmaster computer consultant http://meowing.ccm.uc.edu/~ico/ [EMAIL PROTECTED] =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3 D= 3D= =3D=3D=3D To be is to do=A0=A0 - Socrates To do is to be=A0=A0 - Sartre Do be do be do=A0=A0 - Sinatra I am=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 - God ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel _ Want a new web-based email account ? --- http://www.firstlinux.net _ You deserve a better email address! Get personalized email @yourname or @yourcompany from Everyone.net -- http://www.everyone.net?tag _ Want a new web-based email account ? --- http://www.firstlinux.net _ You deserve a better email address! Get personalized email @yourname or @yourcompany from Everyone.net -- http://www.everyone.net?tag ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
RE: [Alsa-devel] question regarding latest CS4205 laptop soundcard driver
--- Ivica Bukvic [EMAIL PROTECTED] wrote: *There is esd, which is outdated and simply crappy. *There is artsd, which is better, but not good enough, and again, the app must be made to be aware of it in order to utilize it. *There is JACK project which has a huge potential but none of its effects are again universal, nor backwards-compatible with already released software. *There is Gstreamer, but I do not honestly know enough about it. Then make them better. While I would like to thank you for your prompt response, I want to point out that I find your above statement rather discouraging. Not everyone is a low-level programmer, and not everyone should be one. Yet, with such statement you are implying exactly that: for one to use Linux for multimedia, one has to be prepared to be able to do low-level coding in an environment that inherently suffers from lack of documentation. Although I've provided my humble coding contributions to the Linux community, I am by no means an adept programmer who is capable of dealing with the low-level stuff such as this (needless to say I have no clue where to start since documentation is less than sparse). Besides, I would love to help any of these projects to reach their ripeness, but find most of them to be focused on things that need less urgent attention (i.e. JACK, as I understand it, focuses on inter-app audio communication in a highly efficient manner, requiring app-side implementation for any kind of dsp resource sharing, thus meaning there is currently no planned backwards-compatibility, unless the older apps are adapted to its architecture, which in itself is a rather far-fetched assumption that the other application developers will be willing to adapt their apps to this yet-and-if-to-be-established-standard). First let us establish that you want pro quality audio right? PD will answer this better than I. Jack is based on the callback paradigm. This is the same as nearly all the professional quality sound servers on other leading OS's. Unfortunately it has taken the Linux audio community slightly longer to implement this design. Now that we have it many of the developers of realtime music apps are supporting it. Jack is not a yet-and-if-to-be-established-standard. It is a yet to be finished implementation of the standard. Finally, why not merge the efforts of all these different groups/projects into one concise solution, rather than a dozen half-working ones? And who is going to organise this effort? No seriously you are talking about Jack. It is the combined knowledge of the LAD community who have been debating the concept for the past 5 years and are now writing the code. If you haven't joined the mailing list for jack then you should. AFAIK everyone is welcome. Sincerely, Ico ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel -- Patrick Shirkey - Boost Hardware Ltd For the discerning hardware connoisseur Http://www.boosthardware.com Http://www.boosthardware.com/LAU/Linux_Audio_Users_Guide/ _ Want a new web-based email account ? --- http://www.firstlinux.net _ You deserve a better email address! Get personalized email @yourname or @yourcompany from Everyone.net -- http://www.everyone.net?tag ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
[Alsa-devel] Sample rate mask
Hi, How can an application retrieve the supported sample rates? (SNDRV_PCM_RATE* flags) I know you can get the min and max sample rate, but it's more interesting to know exactly which sample rates the hardware supports (if not continuous). Maybe I didn't RTFM carefully enough, but I haven't found any way to do this. The ALSA (kernel) sources suggest this isn't possible. Thanks, Sander ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] question regarding latest CS4205 laptop soundcard driver
I do not mean to be hammering this issue into the ground, but Linux OS as an audio workstation solution has been around for 3 years now, yet the only soundcard I am aware of that is capable of doing hardware mixing is SBLive!, and even that one is due to fact that Creative had their hands in the driver devel. The trident cards can also do this. I believe that all cards that are actually capable of doing this and for which the docs have been provided have ALSA drivers that support it. However, I agree that the issue of simultaneous access to audio resources is a critical one. But lets look at how its been dealt with on other operating systems: Windows (pre-WDM): a kernel-side mixer that creates horrible, un-work-aroundable latency and puts a bunch of code that Linus would never accept into the kernel. Windows (WDM): i don't know. ASIO: no device sharing, AFAIK. MacOS (without ASIO): like windows pre-WDM, AFAIK. Mac OS X: CoreAudio. Much like JACK, it requires a complete rewrite of all code that interacts with audio hardware. thats why there are very few OS X native audio apps at this time. Unlike Apple, we can't force people to use a particular sound server :( I am sure there are more. Yet, no viable solution has been provided despite the fact that even Beos had this solved, needless to mention Mac and Win os's which do this flawlessly. They don't do it flawlessly. It works for many simple cases. ASIO, which until WDM showed up was by far the preferred driver API for audio, doesn't allow device sharing at all AFAIK. Nevertheless, the point remains that under Windows and MacOS, multiple apps can access audio h/w resources simultaneously regardless of the hardware involved, certainly if they are not professional audio apps. So what do we have? *There is esd, which is outdated and simply crappy. *There is artsd, which is better, but not good enough, and again, the app must be made to be aware of it in order to utilize it. *There is JACK project which has a huge potential but none of its effects are again universal, nor backwards-compatible with already released software. *There is Gstreamer, but I do not honestly know enough about it. You missed perhaps the most important ones: * KDE's audio API * GNOME's audio API * ALSA share devices KDE and GNOME are both (regrettably) wrapping artsd in their own APIs that allow device sharing. You could choose to use either of these systems. They are no good for low latency and/or pro audio, and probably never can be if they continue to use a server with artsd's design. ALSA share devices are, at this time, largely untested by the ALSA user community. I don't know how well they are working (I don't even know how to set one up), but if they work as intended, they will entirely solve this issue in the correct way: apps use the same API as they would to access a regular PCM device, and the magic just happens. If you're not willing to sign on to a synchronous execution model like JACK, then I think you should probably focus on ALSA share devices. The fundamental problem is that the original audio API (OSS) didn't provide any interposition between the application and the kernel side driver. That means that mixing either has to be in the kernel, which nobody will approve of let alone allow, or we have to use a clever but ugly hack like LD_PRELOAD to create a point at which the data from these legacy apps can be routed to a better system that can do mixing. libaoss does this, but it relies on the share PCM devices in order to accomplish what you want. Now that Alsa has become default kernel driver, we should definitely try to use the opportunity to finally provide this rudimentary, yet extremely important aspect of audio system. don't consider it so rudimentary. you think of it as basic because Windows and MacOS did it, but they did it at the expense of low latency use. When Apple finally fixed this (with CoreAudio), they have forced not only a completely new API but for many people (non-ASIO developers), a whole new design on their developer community. I overheard that the new 2.5.x kernels have multiplexing feature (which I am guessing enables sharing of the dev resources -- please correct me if I am wrong), if so, will this solve this issue? has nothing to do with the issue. --p ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] latency timer
So what do think I should use instead? I need all 48 channels in perfect sync (sample-accurate). Do you think that's impossible? The CPU-load of my I think it might be very difficult if it involves two separate cards. It would be easy on one card, for sure. application is (with signal processing) less than 30%, but still there are xruns sometimes. It might be that the pci bus can't handle my data. unlikely. its less than 18MB/sec. the PCI bus can easily handle that. I wonder if I'm the first one who wants to use two hammerfalls in linux for recording and playback at the same time. under linux: almost certainly. under any OS: quite possibly. one other question: what kind of video interface are you using and which version of XFree86? --p ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
[Alsa-devel] RME Hammerfall DSP
i just got info on the internals of this interface you're all gonna love it! even if it is expensive. peak and rms meters in hardware, full matrix mixing with a range of -inf .. +2dB, 2 MIDI ports. its going to be great, and hard to see why anyone would want to use anything else for serious audio, IMHO. i hope to have the driver working within a few days of getting the hardware (i have part of it already). --p ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
[Alsa-devel] AC3 Passthru on SB Live
Hello AC3 passthru on the SB Live does not seem to work on all platforms with the latest alsa-cvs. (26-2-2002) It works on my system, which is a SB Live Rev 6, which only started working recently. It does not work on a SB Live rev 7 (I don't have this, but others have reported.) Can anyone comment on which SB Live revisions work, and which do not. All the SB Live versions seem to work with the emu10k1 kernel drivers. Cheers James ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
[Alsa-devel] RE: AC3 Passthru on SB Live
As a small extra, the emu10k1 kernel driver which support oss, has a few bits of info which might be of help From the emu10k1 linux kernel developers: - We allocate memory with pci_alloc_consistent() which according to DMA-mapping.txt assures 32-bits PCI addresses. On top of that we set a dma_mask (with pci_set_dma_mask) of 29 bits (512Mib). Also: - 29 bit (512MiB), mostly speculation/trial-and-error though. See main.c and the pci_set_dma_mask() calls. Does this help alsa09 at all ? Cheers James -Original Message- From: James Courtier-Dutton [mailto:[EMAIL PROTECTED]] Sent: 27 February 2002 15:51 To: [EMAIL PROTECTED] Subject: AC3 Passthru on SB Live Hello AC3 passthru on the SB Live does not seem to work on all platforms with the latest alsa-cvs. (26-2-2002) It works on my system, which is a SB Live Rev 6, which only started working recently. It does not work on a SB Live rev 7 (I don't have this, but others have reported.) Can anyone comment on which SB Live revisions work, and which do not. All the SB Live versions seem to work with the emu10k1 kernel drivers. Cheers James ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
[Alsa-devel] design for the H-DSP control/mixer interface
so, the matrix mixer on the hammerfall-dsp comes with 1456 independent controls. each one represents the volume for routing an input (h/w input or playback stream) to an output. there are 28 h/w inputs, 28 playback streams and 28 outputs. it seems unwise to simply map this straight to the control API. no program is going to be able to usefully cope with this many controls. i welcome ideas on ways to represent this kind of mixer with the ALSA control system. --p ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] AC3 Passthru on SB Live
At Wed, 27 Feb 2002 17:19:44 -, James Courtier-Dutton wrote: Or, it might be the problem of dma mask. ALSA uses 31bit mask while Creative's driver uses 29bit. But anyway this won't affect unless you have more than 512MB RAM and kernel ocasionally allocates the area greater than 512MB. Creative's driver uses 29bit mask, because a 32bit mask was creating problems with some users. Maybe the SB Live is only capable of 29bits for DMA. well, as stated above, alsa uses 31bit (not 32), so this is not problem usually, because kernel's pci memory allocator checks only whether the mask is 32bit or not, and if it's not 32bit, the allocator uses always GFP_DMA flag. Takashi ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] question regarding latest CS4205 laptop soundcarddriver
The trident cards can also do this. I believe that all cards that are actually capable of doing this and for which the docs have been provided have ALSA drivers that support it. Well that's exactly where lies the problem. Most of the laptop soundcards have marginal Alsa (and for that matter OSS) support. The only ones that I am aware of so far of being able to do multiple hardware streams in Linux are es1969 (thanks to Patrick Shirkey) and Trident that you have mentioned (although I am not sure what model and in what laptop), and possibly Yamaha chipset. That is rather sparse choice and usually laptops that utilize these are either outdated or have other peripherals weak (i.e. marginal video card). Windows (WDM): i don't know. WDM is good, since Sonar claims sub-7 ms latencies on average sound hardware in XP right out of the box. They don't do it flawlessly. It works for many simple cases. ASIO, which until WDM showed up was by far the preferred driver API for audio, doesn't allow device sharing at all AFAIK. I agree, my flawless statement was certainly overrated. Yet, the question remains: what am I to do as a musician needing to utilize my portable laptop while the apps/software I currently use get ported to the JACK architecture (if they get ported at all)? Please don't get me wrong, I do like to do programming, and I am about to join JACK community. Yet, I need to continue churning music as well in order to finish my degree. Programming alone will not get me there, although I love Linux for what it is, and would love to contribute as much as my time allows. don't consider it so rudimentary. you think of it as basic because Windows and MacOS did it, but they did it at the expense of low latency use. When Apple finally fixed this (with CoreAudio), they have forced not only a completely new API but for many people (non-ASIO developers), a whole new design on their developer community. Well, what if we had at least a temporary, even higher-latency solution, so that I could at least get some work done without worrying about these serious software limitations and trying to come-up with poor and temporary work-arounds? Thanks for your insightful comments! Sincerely, Ico ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
[Alsa-devel] Rotating left/right to front/back
I am happily outputting sound via spdif on my YMF744B based soundcard (an AW744 Pro). What I'd like to be able to do, though is rotate the left/right channels to come out of front/back instead. The reason is to have stereo separation when I am at a different angle. Is there any way to do this at the configuration level, or will I have to write software to split the PCM data into left/right and then output mono signals separately to front and back? Any help would be much appreciated. Thanks, Mike -- Mike Oliphant [EMAIL PROTECTED] MP3.com - The Premier Music Service Provider http://www.mp3.com ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] question regarding latest CS4205 laptop soundcard driver
I agree, my flawless statement was certainly overrated. Yet, the question remains: what am I to do as a musician needing to utilize my portable laptop while the apps/software I currently use get ported to the JACK architecture (if they get ported at all)? 1a) Get Abramo to post (or point to) detailed information on using a share PCM device 1b) Get Abramo or Jaroslav to post (or point to) detailed information on setting up libaoss (specifically, how to map /dev/dspN to a specific ALSA PCM device) 2) edit your ~/.asoundrc file to define a share PCM device 3) run all your legacy (OSS) apps with LD_PRELOAD set to preload libaoss. a small wrapper script is useful for this; ALSA may already come with one (*) 4) run all your newer (ALSA) apps with an argument telling it to use the share PCM device and you should be done. if, that is, the share device type is really working. if not, you can help us debug it. --p (*) something like: % cat aoss #!/bin/sh export LD_PRELOAD=/where/i/put/libaoss.so exec $* % then you can just run OSS apps like this: % aoss oss-app-name oss-app-args... i know this appears hacky. like i said, there is no way around this because of the way OSS was designed. ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
[Alsa-devel] an excellent article
this: http://www.linuxpower.org/display.php?id=216 is an excellent article on mistakes that SGI made developing their video APIs. much of what it says seems deeply relevant to audio as well. from my perspective, its pretty confirming of a JACK approach, but even if you don't see it that way, i think there is a lot to be learned and/or reminded of here. --p ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
RE: [Alsa-devel] question regarding latest CS4205 laptop soundcard driver
1a) Get Abramo to post (or point to) detailed information on using a share PCM device 1b) Get Abramo or Jaroslav to post (or point to) detailed information on setting up libaoss (specifically, how to map /dev/dspN to a specific ALSA PCM device) 2) edit your ~/.asoundrc file to define a share PCM device 3) run all your legacy (OSS) apps with LD_PRELOAD set to preload libaoss. a small wrapper script is useful for this; ALSA may already come with one (*) 4) run all your newer (ALSA) apps with an argument telling it to use the share PCM device and you should be done. if, that is, the share device type is really working. if not, you can help us debug it. --p (*) something like: % cat aoss #!/bin/sh export LD_PRELOAD=/where/i/put/libaoss.so exec $* % then you can just run OSS apps like this: % aoss oss-app-name oss-app-args... i know this appears hacky. like i said, there is no way around this because of the way OSS was designed. Wow, finally a huge step forward!:-) I really do not care if it is a hacker-like way of doing stuff as long as it works. I will try fiddling with what you gave me and post some results when (and if) I get anywhere with it... Thanks once more for a concise explanation... Is there anyone else with some kind of experience in this field? Maybe it is time to start documenting this potentially awesome feature... I could easily provide webspace and/or maintain the docs webpage if needed, as long as I can get a pool of people working on this issue with me... Anyone interested? Ico ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
