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 > On 27-04-08 12:55, Sergei Steshenko wrote: > > >> On Sun, 27 Apr 2008 02:21:23 +0200 Rene Herman <rene.herman@xxxxxxxxxxxx> >> wrote: >> > > >>> (the card = the M-Audio Revolution. No control is the expected >>> situation) >>> >> ??? >> >> For me it's the opposite - if a card is capable of having different >> sample rates, the expected situation is to be able to change the rate >> from mixer. >> > > Makes no sense. Setting the sampling rate has no meaning outside of the > action of playing or recording. It's you who decides the sampling rate, but > by the rate of whatever you throw at the card for playback, or by whatever > rate you specify for a recording. The card adepts to the data (for playback > that is), not the other way around. > > Note that mixing is not (historically) an expected feauture either and at > least when not supported directly in hardware, an unwanted feature these > days by most people that care. > > Rene. > > ------------------------------------------------------------------------- > 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 > ------------------------------------------------------------------------- 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
