Sergei Steshenko wrote: > On Mon, 28 Apr 2008 09:01:04 +1200 > Pete Black <pete@xxxxxxxxxxxxxxxxx> wrote: > > >> I'm no expert, but as far as I can tell: >> >> Currently, it seems that the sample rate setting is supposed to be >> managed by applications (where application includes user space ALSA >> plugins etc.) - an application tries to open a channel to the hardware >> device with a specific sample rate - if the hardware supports it, the >> hardware is switched to that rate. If not, you get an error. >> >> The practical upshot of this is that the audio daemon you are using >> (JACK, ALSA dmix or whatever the native 'soft mixer' component is these >> days) which is actually driving the hardware directly needs to be >> configured with the sample rate it will access the hardware with. >> >> Currently, this is done with JACK by launching it with a command-line >> flag, and on ALSA dmix by editing the user or system .asoundrc files. >> >> So, the control is there, but not at the 'mixer' level of the stack - >> while i guess it would be a valid design to restrict all applications to >> a single mixer-specified sample rate, which you would change on a global >> basis, this is not the way its done. The application with exclusive >> control over the sound channel (or, presumably, the first application to >> open a channel on a driver that supports multiple hardware channels) >> sets the rate to be used until termination. 'On the fly' rate switching >> might be possible, but i expect any support for this would be done by >> closing the channel and requesting a re-open with a new rate. >> >> I might have the details wrong on this, but as far as I know, this is >> how it works >> >> -Pete >> >> > > Honestly, have you painted a consistent trouble-free picture ? > > For example, this: > > " > The application with exclusive > control over the sound channel (or, presumably, the first application to > open a channel on a driver that supports multiple hardware channels) > sets the rate to be used until termination > " > > - suppose, again, 'mplayer' wants 44100Hz while 'vlc' wants 48000Hz, > how are they supposed to switch sample rate while simultaneously working ? > > I, as end user, may understand the need to sometimes grant an application an > exclusive access but it shouldn't be an application which decides on this, > it should be me who decides which applications have exclusive access. > > Aren't we talking about the basics of OSes ? > > Does anyone expect coherent OS functioning if every application is allowed > to change SATA/IDE channels settings for the drive on which system-wide > filesystem resides ? > > Thanks, > Sergei. > Sergei, Not every application is allowed to change the setting - only the application with exclusive access to the channel is. When that application terminates, or releases its handle on the channel, the channel can be 'grabbed' by another application and possibly set to a new rate. This is well illustrated when JACK is used - without JACK running, you can have many applications play sound - this data is mixed through the ALSA default device - actually a plugin called dmix. When you run JACK, it grabs exclusive use of the sound device (dmix will immediately give up it's 'lock' on the hardware when another app requests access to the 'low level' hardware device), sets its output rate to whatever you specify, and locks access to any other application - that is, only JACK clients can play sound, and any other apps attempting to play sound through the ALSA default channel (dmix) will not produce sound. Currently, ALSA software mixing can handle multiple applications connecting to it with arbitary rates - it will then resample these streams and send output to the channel at a specific, rate - for default ALSA dmix, this is specified in .asoundrc and defaults to 48000Hz 16 bit, as far as I can remember. Without software mixing (which defaults to enabled on ALSA these days), only one application can use the sound card at a time in the general case, and where a driver supports low-level 'multi-open' e.g. SB Live - i assume that streams are resampled in hardware to whatever rate the 'first' access to the hardware was. The model is quite consistent, and you may be getting confused by the fact that in general use (e.g. without JACK), youre applications are opening a stream to the ALSA software mixer, not the hardware itself. Hope that helps, -Pete ------------------------------------------------------------------------- This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone _______________________________________________ Alsa-user mailing list Alsa-user@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/alsa-user
