Re: Hidden rate conversion, and Alsa configuration

[stan <stanl@cox.net>]

On Mon, 23 Jul 2007 10:15:07 +0200 (CEST)
Jaroslav Kysela <perex@suse.cz> wrote:

> On Sun, 22 Jul 2007, stan wrote:
> 
> > On Fri, 20 Jul 2007 13:33:38 +0100
> > Alan Horstmann <gineera@aspect135.co.uk> wrote:
> > 
> > [snip]
> > 
> > > 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
> > 
> > For what it's worth, I agree with Alan here.  Any sound library with
> > aspirations to professional use can't have hidden conversions and
> > silent corrections going on.
> > 
> > However, I also agree with Takashi that for the average user having
> > the dmix plugin as a default is a very good thing.
> > 
> > So, would it be possible to have an api call in the interface to
> > disable the dmix plugin for any instance of alsa.  For example,  I
> > call the interface to open the default sound device.  Another call
> > gets me the hardware associated with the default device.  I then
> > tell the interface to bypass any filters or plugins, basically
> > giving access to the hw interface for whichever card is default for
> > this stream only.
> > 
> > Maybe this already exists.  If it does, could you point me in the
> > right direction (which function).  If not, where would it be best
> > implemented (which source file)?  I don't know that I could or will
> > write it, but I would like to have a look at how difficult it would
> > be.
> 
> The library is intended to hide all these details for applications.
> You can disable sample conversion on demand 
> (snd_pcm_hw_params_set_rate_resample) to use own better resampler.
> 
> Note that conversions are not used when application asks for
> parameters which hw already supports. Of course, dmix is different
> thing, but the definition of default device is that it should be
> common for most applications. Other applications have possibility to
> choose another device / abstraction. These applications can determine
> card number and device/subdevice numbers via
> snd_pcm_info_get_card,device,subdevice functions and try to open
> "raw" hw:card,device,subdevice PCM devices.

Thank you Jaroslav,

That's what I was looking for.

> 
> 						Jaroslav
> 
> -----
> Jaroslav Kysela <perex@suse.cz>
> Linux Kernel Sound Maintainer
> ALSA Project, SUSE Labs