Re: [ecasound] delta66, chains, and ecasound

[Lance <lance@email-addr-hidden>]

Vladimir Mosgalin wrote:
> Hi paul blakeley!
>
>  On 2007.11.20 at 12:26:29 +0000, paul blakeley wrote next:
>
>   
>> Can someone please explain the differences between these?  What impact
>> they have on the application?
>>     
>
> plughw supports much more sample formats / channel configurations
> than underlying hardware supports natively, and performs conversion if
> needed. hw performs no conversion, but supports less configuration,
> sometimes only very obscure ones, but when used you can rest assured
> that no conversion takes place.
>
> Mostly you'd want these conversions to take place, like mono->stereo
> conversion or S16LE->S32LE conversion etc (all depending on your
> hardware)
>
>   
>> If I need to drive the sound card directly should I use 'hw'?
>>     
>
> You can use hw, but it isn't really recommended unless you REALLY know
> how to use it and have support of every weird format in all possible
> combinations. That's about underlying hardware details, and most
> applications don't want to deal with them.
>
> For example my soundcard supports only S24_3BE format; you can't open hw
> device in any other mode, if you want to output S16LE (most applications
> never heard of S24_3 formats, let alone BE variations), you must use
> plughw, there is no other choice. Or p16v device on audigy2 supports
> only 8-channel modes; you can't output stereo signal to it, no matter
> how you try. So you either can output 8 channels to hw device or let
> plughw to do stereo->8ch conversion for you automatically.
>
> Unless you want to take care of all these little details, using hw is
> probably not a good idea. Though it's required for some applications
> because you don't actually know if/what kind of conversion takes place
> when you use plughw, most application would trouble users much less if
> they were to use plughw instead of hw. Actually, almost all application
> shouldn't even use plughw, sticking to "default" device, to allow
> software mixing, jack/pulse routing plugins, user choosen conversions to
> take place. If you do anything else, you create problems for users, so
> you must have really good reasons to do so..
>
>   
Valadimir, I agree with what you say, but if you want to use the exotic 
features of alsa to control the sound device you have to use plughw: 
instead of default.  default uses dmix which always uses 48000 frame 
rate.  So if you want to use a card at say, 96000 frame rate, you can't 
do it with default but can do it with plughw.  The sound servers don't 
implement this  exotic alsa functionality (they are 'dumb' regarding 
alsa).  For casual use, great because people aren't interested in sound 
device performance, they just want to hear sound, and want it to be easy 
to manipulate.  For average mp3 use, sound quality is irrelevant, for 
anything else, not good.

To the original poster, you can of course control the hardware directly  
using hw: as well, but you are responsible for all the details as 
Vladimir pointed out above.  Usually what you want is to avoid software 
mixing by using a frame rate supported by the hardware.  With plughw: 
you can do this and let alsa take care of format conversion for you.  
With hw: you have to do the format conversion to the card's internal 
format.  If you run on more than one card or expect to run in the wild, 
this means you duplicate the functionality of alsa for format 
conversion.  Counterproductive.

On the other hand, if you are building an embedded device with a single 
sound interface always, hw: might be the way to go.

------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H

_______________________________________________
Ecasound-list mailing list
Ecasound-list@email-addr-hidden
https://lists.sourceforge.net/lists/listinfo/ecasound-list
Received on Sun Mar 8 12:15:01 2009