ALSA 'share' device, or 'software multi-open'

ALSA 'share' device, or 'software multi-open'

[Pete Black]

Hi there,

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.

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.

I have also seen posts on the same alsa-devel mailing list to the effect 
that mixing several audio streams in software is easy, and an 
application-level problem hence the lack of implementation in ALSA 
itself. I think that idea is ludicrous, and this type of sharing is 
absolutely necessary, especially when using Linux to make music with the 
variety of software synths that are now available.

Specifically, I have a CMI8738 card, and I want to be able to run seq24 
(MIDI sequencer),and a couple of separate software synths at the same time.

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.

Does ALSAs architecture make doing this in software at the driver/plugin 
level difficult, or is it just that nobody wants this capability?

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?

Thanks

-Pete







-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: ALSA 'share' device, or 'software multi-open'

[Pete Black]

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

Re: ALSA 'share' device, or 'software multi-open'

[Patrick Shirkey]

Pete Black wrote:
> 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)?
> 

Even if you could access directly the plugin you are requiring you still 
have to code support for alsa into every app or write code for the oss 
emulation layer to deal with this scenario. I don't think it would be 
worthless effort to do the latter. After all that is what WDM/MME does.

IIUC the share plugin is not even intended to do what you want (as you 
mention above) it is written to share audio between different devices 
specified in the asoundrc file. Not to mix multiple streams from 
multiple apps. Paul you should stop suggesting the share plugin as an 
almost possible option. It is a red herring.

The deal is that Abramo got the smix plugin working (probably only on 
his personal tree) and then got laid off from Suse and has since not had 
the time or interest to contribute to the code base.

It sure would be nice if he would release that old code so that other 
people could use it as a base to work from. I don't know what is 
stopping him apart from an extremely busy workload over the past year. 
So busy he hasn't been able to find 10 minutes to make the patch and 
post it to the list or put it online. (hint hint nudge nudge).

-- 
Patrick Shirkey - Boost Hardware Ltd.
For the discerning hardware connoisseur
Http://www.boosthardware.com
Http://www.djcj.org - The Linux Audio Users guide
========================================

"Um...symbol_get and symbol_put... They're
kindof like does anyone remember like get_symbol
and put_symbol I think we used to have..."
- Rusty Russell in his talk on the module subsystem



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: ALSA 'share' device, or 'software multi-open'

[Patrick Shirkey]

[ please forward to alsa-devel for me. thanks. ]

 >IIUC the share plugin is not even intended to do what you want (as you
 >mention above) it is written to share audio between different devices
 >specified in the asoundrc file. Not to mix multiple streams from
 >multiple apps. Paul you should stop suggesting the share plugin as an
 >almost possible option. It is a red herring.

sorry, its a mis-identification rather than anything else. the plugin
i am trying to refer to exists, but as usual with ALSA, its not
documented and so even i don't know its name :) but yes, "mix" or
"smix" is the right one, not "share".

--p





-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: ALSA 'share' device, or 'software multi-open'

[Pete Black]

This would be the same smix plugin that isn't in the ALSA tree then? 
Unless it has recently been added to CVS, i can find no trace of it in 
my 0.9rc trees.

Suggesting a solution that doesn't exist outside the context of 'some 
guy who used to work for SuSE and might have got this to work once on 
his own tree but didn't commit it' is not only frustrating, but also 
misleading.

A simple 'No, ALSA is not capable of mixing multiple streams in software 
for playback on single-channel hardware' would have sufficed.

However, now that we have established that there is no specific problem 
with doing this in the context of ALSA, and that it has, in fact 
supposedly been done, I would welcome any information on where this smix 
plugin might be found, and how it might be used.

I feel like i'm in the Matrix  -

'Do not try to use the smix plugin, there is no documentation. Instead, 
only try to realise the truth...The truth?...There is no smix plugin'

Does anyone know abramo's (sp?) email address so that i could ask him 
for some information directly?

Thanks

-Pete




>[ please forward to alsa-devel for me. thanks. ]
>
>  
>
>>IIUC the share plugin is not even intended to do what you want (as you 
>>mention above) it is written to share audio between different devices 
>>specified in the asoundrc file. Not to mix multiple streams from 
>>multiple apps. Paul you should stop suggesting the share plugin as an 
>>almost possible option. It is a red herring.
>>    
>>
>
>sorry, its a mis-identification rather than anything else. the plugin
>i am trying to refer to exists, but as usual with ALSA, its not
>documented and so even i don't know its name :) but yes, "mix" or
>"smix" is the right one, not "share". 
>
>--p
>
>  
>





-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf