[CM] snd-gtk-alsa "alsa_audio_open: could not set rate to exactly 44100, set to 3200 instead"

[Fernando Lopez-Lezcano]

On Wed, 2006-02-01 at 23:41 +0000, Sebastian Tennant wrote:
> "Bill Schottstaedt" <bil@ccrma.Stanford.EDU> wrote:
> 
> > Fernando explained what is going on, I think (at least his bugfix works
> > on my machine).  aplay uses the device "plughw:0", whereas snd/sndplay
> > default to "hw:0".  plughw then provides low-fi sampling rate interpolation
> > if necessary, whereas hw just throws up its hands.  To see aplay in the
> > same mode
> >
> > aplay --device=hw:0 oboe.snd
> >
> > and to get snd to use alsa's interpolator:
> >
> > SNDLIB_ALSA_DEVICE=plughw:0 snd oboe.snd
> >
> > (I think -- this looks like bash, and won't work in tcsh -- I did this:)
> >
> > setenv SNDLIB_ALSA_DEVICE "plughw:0"
> > snd oboe.snd
> >
> > I think I'll add scheme/ruby variables for alsa-device, alsa-playback-device, and
> > alsa-capture-device so that this can be set in ~/.snd or wherever, and add
> > Fernando's two notes to grfsnd.html in a new section ("Snd and Alsa"), and
> > it seems to me that Snd should provide hi-fi interpolation in the fallback
> > case -- I didn't realize this was such a complex business.  Any other suggestions
> > are always welcome.
> >
> > Another minor annoyance -- with plughw:0, snd now complains:
> >
> > ":;alsa_audio_open: plughw:0: could not set rate to exactly 22050, set to 22100 instead"
> >
> > which I'll either replace with my own src, or add a way to turn the warning off.
> 
> I'm afraid a lot of what you are saying is over my head, and I can't
> say I understand the ~/.asoundrc 'language' either.
> 
> With my existing ~/.asoundrc, (which works with all my other audio
> apps), when I run snd with the command:
> 
>   $ SNDLIB_ALSA_DEVICE=plughw:1 snd file.wav
> 
> it produces the following errors:
> 
>   [22:37:00] alsa_audio_open: plughw:1: could not set rate to exactly 44100, set to 0 instead
>   [22:37:00] alsa_dump_configuration: status of plughw:1
>   hw_params status of plughw:1
>   ACCESS:  RW_INTERLEAVED
>   FORMAT:  S16_LE
>   SUBFORMAT:  STD
>   SAMPLE_BITS: 16
>   FRAME_BITS: 32
>   CHANNELS: 2
>   RATE: (44101 44102)
>   PERIOD_TIME: [1000 23219)
>   PERIOD_SIZE: 1024
>   PERIOD_BYTES: 4096
>   PERIODS: 3
>   BUFFER_TIME: [3000 69659)
>   BUFFER_SIZE: 3072
>   BUFFER_BYTES: 12288
>   TICK_TIME: 1000
>   sw_params status of plughw:1
>   start_mode: DATA
>   xrun_mode: STOP
>   tstamp_mode: NONE
>   period_step: 0
>   sleep_min: 0
>   avail_min: 0
>   xfer_align: 0
>   silence_threshold: 0
>   silence_size: 0
>   boundary: 0
> 
>   [22:37:00] alsa_audio_open: cannot set hardware parameters for plughw:1
>   [22:37:00] can't play : alsa_audio_open: cannot set hardware parameters for plughw:1
>   [22:37:00] can't play : alsa_audio_open: cannot set hardware parameters for plughw:1

Strange, I'm looking at the current code...

snd_pcm_hw_params_set_rate_near
  is not returning a result < 0
  (otherwise the check right after calling it would return an error)

so... that would seem to mean that the call was sucessfull (ie: a sample
rate was selected). Then you get the warning above (about the rate not
being exactly the same). But there is something very wrong at that
point, the actual rate reported by alsa is 0! So it is not surprising
that the next call fails and triggers the parameter dump. That would
seem to point to some inconsistency in alsa itself, the call should
either fail with an error return < 0, or it should set the frequency and
return > 0. 

What is exactly the hardware in hw:1?

Have you tried to tweak other parameters? In particular I would try:

SNDLIB_ALSA_BUFFERS
SNDLIB_ALSA_BUFFER_SIZE

set BUFFER_SIZE to < 1024, perhaps 512?
try with BUFFERS = 2 or 4

Try _not_ using the .asoundrc to see if that has any influence. 
-- Fernando

> N.B. I changed '0' to '1' on the command line because the external
>      audio I/O device that I want snd to use is card 1
> 
> Do I need to modify my ~/.asoundrc, if so how?
> 
> sdt
> 
> 
> P.S. Here's my ~/.asoundrc again (for your convenience).
> 
>   #set Edirol UA-3FX as default hardware device for all alsa aware applications
>   pcm.!default { type hw card 1 device 0 }
>   ctl.!default { type hw card 1 device 0 }
> 
>   #force OSS apps to use Edirol UA-3FX too (with 'aoss' command)
>   pcm.dsp0 { type plug slave.pcm hw:1,0 }