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

[Jaroslav Kysela]

On Sun, 22 Jul 2007, stan wrote:

> On Fri, 20 Jul 2007 13:33:38 +0100
> Alan Horstmann <gineera at 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.

						Jaroslav

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