[alsa-devel] Hidden rate conversion, and Alsa configuration
tiwai at suse.de
Fri Jul 27 18:18:29 CEST 2007
At Fri, 27 Jul 2007 17:20:41 +0100,
Alan Horstmann wrote:
> On Friday 20 July 2007 13:33, Alan Horstmann wrote:
> > < Previously subject: Re: SALSA and aplay >
> > On Thursday 19 July 2007 15:24, you wrote:
> > > On Thu, Jul 19, 2007 at 11:33:32AM +0200, Takashi Iwai wrote:
> > > > At Wed, 18 Jul 2007 17:20:29 +0100,
> > > >
> > > > The 48k-fixed rate is due to dmix plugin. It requires a fixed sample
> > > > rate for all apps. In theory, it may accept multiple rates, but the
> > > > feature is not implemented yet.
> > > >
> > > > You can change the default rate by overriding defaults.pcm.dmix.rate
> > > > config item, e.g. define the below in ~/.asoundrc:
> > > >
> > > > defaults.pcm.dmix.rate 44100
> > >
> > > Wouldn't it be better to specify hw:0 (or whatever card you are using)
> > > in this case? With this type of hardware I'd rather make sure that dmix
> > > isn't used at all (I assume that dmix is now the default instead of
> > > hw:0).
> > I have less concern with dmix than the hidden rate conversion, but would
> > happily loose both. Using "hw" forces use of 12 capture and 10 playback
> > channels in this case, doesn't it? So I need some plugin to play 2
> > channels?
Yes. The route plugin.
> > There are 2 issues for me:
> > 1. With the cards rate state = 'locked' alsa (not sure what bit of it) was
> > unable to set the desired clock rate, yet did not report an error. Data
> > was then eg captured from the card as if it was running at 48K, but
> > actually it remained at 44.1K. Thus the recorded data was wrong.
> > snd_pcm_hw_params_set_rate_near(..)
> > did not report error because it was asking for 44.1K; somewhere else the
> > configuration decided 48K was better, but did not highlight that the card
> > refused to change setting. Surely this should class as a bug.
> > Since the inverse error happens on capture, it is not immediately obvious
> > that there is a problem with the recording, so important recordings could
> > be completely messed up.
This is rather a driver problem (or maybe the configuration issue that
doesn't reset the locked rate to a proper value). Should be fixed,
> > 2. These ice1712-based pro/semi-pro hardware systems should IMO NEVER
> > perform secret rate conversion. They are designed for readers of 'Sound on
> > Sound' etc, and Paul White et al would rightly blast M-Audio or Terratec if
> > their Windows drivers quietly set the card to a different rate to that
> > requested and rate converted the data! Especially so on a capture stream.
> > Remember the cards are 24-bit 96KHz capable and approach 100dB
> > signal-to-noise ratio.
The "default" PCM is the laziest setting, which accepts the things as
much as possible. That is, the default PCM is definitely _not_ for
"pro" guys. And, the real pro would use JACK with hw PCM, so this
shouldn't matter :)
> > Whilst there may be circumstances in which material recorded at different
> > rates has to be used in the same project, it is only converted once, in
> > full knowledge.
> > Can't dmix be configured to run at whatever rate is set on the card, or the
> > requested rate, rather than attempt to overule both of them?
> Was this missed or ignored?!!
Sorry, your post was burried in flood of incoming mails over
(literally) thousands mails per day...
> Could you give pointers as to how to modify Alsa configuration so that rate
> conversion can never happen, as I would prefer to have an error accessing the
> sound card rather than unknown conversion, which in my use should never be
> neccesary anyway.
If any implicit conversion does matter, use hw PCM. That's exactly
what is designed for. Any other convenience with plugins is your
We provide the laziest setting as the default, and this won't be
changed unless people will stop bugging about non-working apps :)
More information about the Alsa-devel