[alsa-devel] Hidden rate conversion, and Alsa configuration

[Alan Horstmann]

< 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,
> >
> > Alan Horstmann wrote:
> > > Actually, I think I have an idea what is happening, but not why.
> > >
> > > It attempts to set the card to 48000, which fails since I have it
> > > locked! When I recorded the file the same was true, so from "default"
> > > the file plays back correct although it is in fact wrong, and plays
> > > wrong when imported into Audacity.  The set-up listed above suggests to
> > > me that Alsa is rate converting to 48000 and Mmap'ing to the card.  If
> > > correct, is that really necessary?  I dislike any rate conversions on a
> > > serious recording system, and especially hidden ones.  Is this a
> > > configuration issue that might have changed since, say, 1.0.10 or
> > > 1.0.12?
> >
> > 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?

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.

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.

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?

Alan