Perhaps I can phrase my question a little differently. I understand that synchronous, sample-accurate minimal-latency operation is in the realm of JACK etc., and for this to be properly implemented requires a change of application architecture to fit with a callback approach. This is good, and one day i hope we can look forward to seeing all 'professional' audio apps on Linux use the Jack API.
I understand that simple, low-latency and application transparent is probably a tough one given the audio application architecture that is predominant across most modern operating systems. I am not overly concerned about latency, the main thing is that it sounds good enough - i.e. i don't require perfection, I just want to get it 'as good as I can' without rewriting the applications to use, for example JACK. So, while I wait for JACK support to be mainstream, what I would like to know is: 1. Can ALSA be configured to provide an application-transparent mechanism to mix multiple independent stereo sound streams (generated by different, independent applications) and route the resulting mixed stream to a single stereo output on a soundcard? 2. If the answer to question 1 is 'yes', then how can I configure my system to support this capability? I have found references to the enigma that is 'aserver', the mythical 'smix' plugin, the mysterious 'share' plugin, and in each case there is either no documentation whatsoever (aserver), the only documentation are the two words 'unknown reference' (smix plugin), or the documentation clearly states that the component is not fit for the purpose it has been suggested to be used for (share plugin). I would be very willing to write a HOWTO on making this work, as the question has come up under different guises many times on the ALSA lists, and never an actual resolution or categorical 'it's just not doable currently'. Can someone help me (and the others who are as confused as I am on this issue)? Thanks -Pete > [ please forward to alsa-devel; my ISP and sf.net are not on > speaking terms right now. ] > > > >>I am interested in knowing what ALSA's current support is for a >>'software multi-open' driver/plugin, that can take the output of several >>streams, mix them together in realtime and play them out to the soundcard. >> >>From browing the list archives, I come across several references to a >>'share' plugin, but also several references to the fact that the author >>of the plugin is the only one who has ever actually used it. >> >> > >correct. > > > >>I am aware of esd/arts/JACK etc., but none of these projects do what I >>would like to have - a simple, lowish-latency, application-transparent >>method of sharing a sound card. >> >> > >its not possible to to do this. its like the old saw: > > simple > low latency > application-transparent > > pick 2 out of three! > >nobody, and i mean nobody, has ever provided a way to do all >3. CoreAudio, for which JACK is a rough equivalent, is the best, and >it only works when you use AudioUnits and even that only works because >Apple can force the callback-style API on developers. the windows >equivalent (the kernel mixer) has horrible latency and until WDM came >along it was the principle reason for such lousy latency under windows >(without ASIO, anyway). > > > >>I understand that drivers such as the SBLive and trident support >>multi-open, passing the streams to the hardware for mixing, but why does >>there seem to be no way to do the same thing with software? >> >>ESD doesn't seem to put any appreciable load on the system, and network >>transparency is not really a requirement, at least for me. >> >> > >then what's wrong with esd? use it. > >you need to think more about what you're asking for. you want multiple >programs to be able to write data to the same place. ALSA provides >this already, its accessed via the "share" PCM type, but nobody that i >know of except abramo (who wrote implemented most of it) has every >tried to use it. > >its simple (it uses the same API as the rest of ALSA), its application >transparent (you just change the name of the PCM device you pass to >the program to use), but its not low latency. > > > >>Does ALSAs architecture make doing this in software at the driver/plugin >>level difficult, or is it just that nobody wants this capability? >> >> > >to repeat: it can't be done if the goal is to meet all 3 of your >stated goals. many of us have another goal too: sample synchronous >execution. add that it, and all of a sudden, its not just difficult, >its very hard. JACK represents an attempt to synthesize 2+ years of discussions >on linux-audio-dev about how best to do this. > > > >>And, should it be that this functionality is simply not implemented, >>what would be the best way to approach building in this capability - the >>plugin API, an extended, card-specific driver, or what? >> >> > >the functionality is implemented, but its not documented, its not been >well tested, and it doesn't meet all three of your goals (and cannot). > >--p > > > ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
