[Gta04-owner] QtMoko audio state work

[Neil Jerram]

NeilBrown <neilb at suse.de> writes:

> The 'writes' are very unlikely to have blocked, so it must have been the
> reads.  They are allowed to block, for some reason they block too long.
>
> The only thing I can think of is that you have some plugin in place which
> causes a larger buffer to be used.  So the first 'read from mic' actually
> waits more than 160ms and gets a big buffer.  The subsequent calls all work
> directly with buffers and don't block at all.  Then the second
> read-from-modem happened too late (because it didn't have a big buffer).
>
> Do you have anything in /etc/asound or /root/.asoundrc ??

No, I don't have those files at all.

> Maybe use "hw:0,0" instead of "default".  That should ensure no pluggins are
> happening (though I won't promise).

I think you might be on the right track though.  There's already
a commented snd_pcm_dump() call in the code, and if I uncomment that, I
see:

gsm-voice-routing started
Hardware PCM card 1 'gta04-voice' device 0 subdevice 0
Its setup is:
  stream       : PLAYBACK
  access       : RW_INTERLEAVED
  format       : S16_LE
  subformat    : STD
  channels     : 1
  rate         : 8000
  exact rate   : 8000 (8000/1)
  msbits       : 16
  buffer_size  : 1024
  period_size  : 256
  period_time  : 32000
  tstamp_mode  : NONE
  period_step  : 1
  avail_min    : 256
  period_event : 0
  start_threshold  : 1024
  stop_threshold   : 1024
  silence_threshold: 0
  silence_size : 0
  boundary     : 1073741824
  appl_ptr     : 0
  hw_ptr       : 0
opened p_mod stream
Hardware PCM card 1 'gta04-voice' device 0 subdevice 0
Its setup is:
  stream       : CAPTURE
  access       : RW_INTERLEAVED
  format       : S16_LE
  subformat    : STD
  channels     : 1
  rate         : 8000
  exact rate   : 8000 (8000/1)
  msbits       : 16
  buffer_size  : 1024
  period_size  : 256
  period_time  : 32000
  tstamp_mode  : NONE
  period_step  : 1
  avail_min    : 256
  period_event : 0
  start_threshold  : 1
  stop_threshold   : 1024
  silence_threshold: 0
  silence_size : 0
  boundary     : 1073741824
  appl_ptr     : 0
  hw_ptr       : 0
opened r_mod stream
Plug PCM: Route conversion PCM (sformat=S16_LE)
  Transformation table:
    0 <- 0
    1 <- 0
Its setup is:
  stream       : PLAYBACK
  access       : RW_INTERLEAVED
  format       : S16_LE
  subformat    : STD
  channels     : 1
  rate         : 8000
  exact rate   : 8000 (8000/1)
  msbits       : 16
  buffer_size  : 1024
  period_size  : 256
  period_time  : 32000
  tstamp_mode  : NONE
  period_step  : 1
  avail_min    : 256
  period_event : 0
  start_threshold  : 1024
  stop_threshold   : 1024
  silence_threshold: 0
  silence_size : 0
  boundary     : 1073741824
Slave: Hardware PCM card 0 'gta04' device 0 subdevice 0
Its setup is:
  stream       : PLAYBACK
  access       : MMAP_INTERLEAVED
  format       : S16_LE
  subformat    : STD
  channels     : 2
  rate         : 8000
  exact rate   : 8000 (8000/1)
  msbits       : 16
  buffer_size  : 1024
  period_size  : 256
  period_time  : 32000
  tstamp_mode  : NONE
  period_step  : 1
  avail_min    : 256
  period_event : 0
  start_threshold  : 1024
  stop_threshold   : 1024
  silence_threshold: 0
  silence_size : 0
  boundary     : 1073741824
  appl_ptr     : 0
  hw_ptr       : 0
opened p_ear stream
Plug PCM: Route conversion PCM (sformat=S16_LE)
  Transformation table:
    0 <- 0*0.5 + 1*0.5
Its setup is:
  stream       : CAPTURE
  access       : RW_INTERLEAVED
  format       : S16_LE
  subformat    : STD
  channels     : 1
  rate         : 8000
  exact rate   : 8000 (8000/1)
  msbits       : 16
  buffer_size  : 1024
  period_size  : 256
  period_time  : 32000
  tstamp_mode  : NONE
  period_step  : 1
  avail_min    : 256
  period_event : 0
  start_threshold  : 1
  stop_threshold   : 1024
  silence_threshold: 0
  silence_size : 0
  boundary     : 1073741824
Slave: Hardware PCM card 0 'gta04' device 0 subdevice 0
Its setup is:
  stream       : CAPTURE
  access       : MMAP_INTERLEAVED
  format       : S16_LE
  subformat    : STD
  channels     : 2
  rate         : 8000
  exact rate   : 8000 (8000/1)
  msbits       : 16
  buffer_size  : 1024
  period_size  : 256
  period_time  : 32000
  tstamp_mode  : NONE
  period_step  : 1
  avail_min    : 256
  period_event : 0
  start_threshold  : 1
  stop_threshold   : 1024
  silence_threshold: 0
  silence_size : 0
  boundary     : 1073741824
  appl_ptr     : 0
  hw_ptr       : 0
opened r_mic stream
voice routing started
gsm-voice-routing ending - signal 15

So the microphone and earpiece channels are being handled differently
from the modem channels.

What is still curious is that this PCM dump information is identical for
an outgoing call with perfect audio, and for an incoming call with bad
audio and the xrun pattern that I've previously reported.  So I guess
that different handling cannot be the only factor.

If I change "default" to "hw:0,0", I see the same as above for the modem
channels, but then:

[0] p_ear: snd_pcm_hw_params_set_channels failed: Invalid argument
p_ear: retrying in 100 ms
[0] p_ear: snd_pcm_hw_params_set_channels failed: Invalid argument
p_ear: retrying in 100 ms
[0] p_ear: snd_pcm_hw_params_set_channels failed: Invalid argument
p_ear: retrying in 100 ms
...

The code is

    rc = snd_pcm_hw_params_set_channels(s->handle, s->hwparams, 1);

so I presume the problem is that hw:0,0 is a stereo device and must be
opened with 2 channels.

The next idea that occurs to me is to use hw:0,0 and try handling the
mono-stereo mapping in gsm-voice-routing.c.  Do you (or anyone else)
have any other thoughts or ideas, based on the latest observations
above?

Thanks,
        Neil