All of lore.kernel.org
 help / color / mirror / Atom feed
* issue with AD1989A HDA codec and alsamixer
@ 2011-02-01 14:57 Vincent Meserette
  2011-02-02  0:15 ` Raymond Yau
  0 siblings, 1 reply; 8+ messages in thread
From: Vincent Meserette @ 2011-02-01 14:57 UTC (permalink / raw)
  To: alsa-devel

Hi all,

I am working on a system which includes a connexant AD1989A HDA codec
connected to a ATOM processor.
I have four microphones connected to the B and C ports of this codec.
If I change one of the 3 capture gains present in the alsamixer
(Capture, Capture 1 or Capture 3), I can't have any more signal on the
B and C ports
It seems to be due to the fact that ALSA breaks (for example for the
Capture gain) the link between the ADC selector 0 and ADC_0 widgets of
the codec, what can be easily seen with codecgraph.

Have you ever had this kind of problem?
Do you know how can I resolve it ?

Many thanks for your asnwers and best regards

Vincent

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: issue with AD1989A HDA codec and alsamixer
  2011-02-01 14:57 issue with AD1989A HDA codec and alsamixer Vincent Meserette
@ 2011-02-02  0:15 ` Raymond Yau
  2011-02-02  6:16   ` Raymond Yau
  0 siblings, 1 reply; 8+ messages in thread
From: Raymond Yau @ 2011-02-02  0:15 UTC (permalink / raw)
  To: ALSA Development Mailing List

2011/2/1 Vincent Meserette <vmeserette@aldebaran-robotics.com>

> Hi all,
>
> I am working on a system which includes a connexant AD1989A HDA codec
> connected to a ATOM processor.
> I have four microphones connected to the B and C ports of this codec.
> If I change one of the 3 capture gains present in the alsamixer
> (Capture, Capture 1 or Capture 3), I can't have any more signal on the
> B and C ports
> It seems to be due to the fact that ALSA breaks (for example for the
> Capture gain) the link between the ADC selector 0 and ADC_0 widgets of
> the codec, what can be easily seen with codecgraph.
>
> Have you ever had this kind of problem?
> Do you know how can I resolve it ?
>
> Many thanks for your asnwers and best regards
>
> Vincent
>

What is the Vendor Id of conexant AD1989A ?

are your codec are using patch_analog.c according to vendor id of the codec
?

Looking at the datasheet of ad1988a , ad1988b and ad1989b at analog device
web site and ad1989a conexant web site

The digital microphone of conexant ad1989a only connect to adc0 in the
functional block diagram

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: issue with AD1989A HDA codec and alsamixer
  2011-02-02  0:15 ` Raymond Yau
@ 2011-02-02  6:16   ` Raymond Yau
  2011-02-02 19:22     ` Vincent Meserette
  0 siblings, 1 reply; 8+ messages in thread
From: Raymond Yau @ 2011-02-02  6:16 UTC (permalink / raw)
  To: ALSA Development Mailing List

2011/2/2 Raymond Yau <superquad.vortex2@gmail.com>

>
>
> 2011/2/1 Vincent Meserette <vmeserette@aldebaran-robotics.com>
>
> Hi all,
>>
>> I am working on a system which includes a connexant AD1989A HDA codec
>> connected to a ATOM processor.
>> I have four microphones connected to the B and C ports of this codec.
>> If I change one of the 3 capture gains present in the alsamixer
>> (Capture, Capture 1 or Capture 3), I can't have any more signal on the
>> B and C ports
>> It seems to be due to the fact that ALSA breaks (for example for the
>> Capture gain) the link between the ADC selector 0 and ADC_0 widgets of
>> the codec, what can be easily seen with codecgraph.
>>
>> Have you ever had this kind of problem?
>> Do you know how can I resolve it ?
>>
>> Many thanks for your asnwers and best regards
>>
>> Vincent
>>
>
> What is the Vendor Id of conexant AD1989A ?
>
> are your codec are using patch_analog.c according to vendor id of the codec
> ?
>
> Looking at the datasheet of ad1988a , ad1988b and ad1989b at analog device
> web site and ad1989a conexant web site
>
> The digital microphone of conexant ad1989a only connect to adc0 in the
> functional block diagram
>
>
If the number of input sources of adc0 of ad1989a is more than those of adc1
and adc2

This may mean that you will need to implement a specific
ad1989a_capture_mixer[] for ad1989a instead of using ad1988_capture_mixer
and

may need to implement ad1989a_pcm_analog_alt_capture  for adc1 and adc2
similar to alc880_pcm_analog_alt_capture

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: issue with AD1989A HDA codec and alsamixer
  2011-02-02  6:16   ` Raymond Yau
@ 2011-02-02 19:22     ` Vincent Meserette
  2011-02-05  9:46       ` Raymond Yau
  0 siblings, 1 reply; 8+ messages in thread
From: Vincent Meserette @ 2011-02-02 19:22 UTC (permalink / raw)
  To: Raymond Yau; +Cc: ALSA Development Mailing List

Hi Raymond,

Many thanks for your answer.

Looking the AD1989A datasheet (which can be found here :
http://www.conexant.com/products/entry.jsp?id=599) the vendor id of the
codec seems to be 11D4989A
So, I think the codec taken into account in the "patch_analog.c" file is
well the AD1989A because I found these lines in the source code :

/*
 * patch entries
 */
static struct hda_codec_preset snd_hda_preset_analog[] = {
   ...
    { .id = 0x11d4989a, .name = "AD1989A", .patch = patch_ad1988 },
   ...
    {} /* terminator */
};

Concerning the digital microphone input of the codec, I don't use it. I have
four electret microphones connected to the B and C ports of the codec (one
on the PORT-B_L pin, one on the PORT-B_R pin, one on the PORT-C_L pin and
one on the PORT-C_R pin). I have connected by software configuration the
port B to the ADC1 and the port C to the ADC0.
Maybe my problem comes from here, because I don't use the codec in a
standard configuration ?
if it is the case, do you know how can i resolve it ?
Do you also know which registers control the three capture gains of the
alsamixerl (i thought it was the gains of the ADC0, ADC1 and ADC2 )?

Many thanks

Kind regards

Vincent




2011/2/2 Raymond Yau <superquad.vortex2@gmail.com>

> 2011/2/2 Raymond Yau <superquad.vortex2@gmail.com>
>
> >
> >
> > 2011/2/1 Vincent Meserette <vmeserette@aldebaran-robotics.com>
> >
> > Hi all,
> >>
> >> I am working on a system which includes a connexant AD1989A HDA codec
> >> connected to a ATOM processor.
> >> I have four microphones connected to the B and C ports of this codec.
> >> If I change one of the 3 capture gains present in the alsamixer
> >> (Capture, Capture 1 or Capture 3), I can't have any more signal on the
> >> B and C ports
> >> It seems to be due to the fact that ALSA breaks (for example for the
> >> Capture gain) the link between the ADC selector 0 and ADC_0 widgets of
> >> the codec, what can be easily seen with codecgraph.
> >>
> >> Have you ever had this kind of problem?
> >> Do you know how can I resolve it ?
> >>
> >> Many thanks for your asnwers and best regards
> >>
> >> Vincent
> >>
> >
> > What is the Vendor Id of conexant AD1989A ?
> >
> > are your codec are using patch_analog.c according to vendor id of the
> codec
> > ?
> >
> > Looking at the datasheet of ad1988a , ad1988b and ad1989b at analog
> device
> > web site and ad1989a conexant web site
> >
> > The digital microphone of conexant ad1989a only connect to adc0 in the
> > functional block diagram
> >
> >
> If the number of input sources of adc0 of ad1989a is more than those of
> adc1
> and adc2
>
> This may mean that you will need to implement a specific
> ad1989a_capture_mixer[] for ad1989a instead of using ad1988_capture_mixer
> and
>
> may need to implement ad1989a_pcm_analog_alt_capture  for adc1 and adc2
> similar to alc880_pcm_analog_alt_capture
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>



-- 
--------------------------------------------------------
-------- acoustic / audio engineer ---------
-----------  Aldebaran Robotics -------------
168 bis / 170, rue Raymond Losserand
---------------- 75014 PARIS-------------------
----- Phone : +33(0)1.77.37.17.66 -------
----- Mobile : +33(0)6.89.35.71.85 -------
--------------------------------------------------------

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: issue with AD1989A HDA codec and alsamixer
  2011-02-02 19:22     ` Vincent Meserette
@ 2011-02-05  9:46       ` Raymond Yau
       [not found]         ` <AANLkTikugTHmj5aKZqXSi3g50gkqLDXiWmTshBbd9TGQ@mail.gmail.com>
  0 siblings, 1 reply; 8+ messages in thread
From: Raymond Yau @ 2011-02-05  9:46 UTC (permalink / raw)
  To: ALSA Development Mailing List

2011/2/3 Vincent Meserette <vmeserette@aldebaran-robotics.com>

> Hi Raymond,
>
> Many thanks for your answer.
>
> Looking the AD1989A datasheet (which can be found here :
> http://www.conexant.com/products/entry.jsp?id=599) the vendor id of the
> codec seems to be 11D4989A
> So, I think the codec taken into account in the "patch_analog.c" file is
> well the AD1989A because I found these lines in the source code :
>
> /*
>  * patch entries
>  */
> static struct hda_codec_preset snd_hda_preset_analog[] = {
>    ...
>     { .id = 0x11d4989a, .name = "AD1989A", .patch = patch_ad1988 },
>    ...
>     {} /* terminator */
> };
>
> Concerning the digital microphone input of the codec, I don't use it. I
> have four electret microphones connected to the B and C ports of the codec
> (one on the PORT-B_L pin, one on the PORT-B_R pin, one on the PORT-C_L pin
> and one on the PORT-C_R pin). I have connected by software configuration the
> port B to the ADC1 and the port C to the ADC0.
> Maybe my problem comes from here, because I don't use the codec in a
> standard configuration ?
> if it is the case, do you know how can i resolve it ?
> Do you also know which registers control the three capture gains of the
> alsamixerl (i thought it was the gains of the ADC0, ADC1 and ADC2 )?
>

can you post the output of alsa-info.sh

Six 192kHz 92dB ADCs
- simultaneous record of up to 3 stereo channels

It does not imply you can record 4 channels with the existing hda driver
which create three subdevices

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: issue with AD1989A HDA codec and alsamixer
       [not found]         ` <AANLkTikugTHmj5aKZqXSi3g50gkqLDXiWmTshBbd9TGQ@mail.gmail.com>
@ 2011-02-07 16:12           ` Raymond Yau
  2011-02-08  9:18           ` Raymond Yau
  2011-03-23  6:51           ` Raymond Yau
  2 siblings, 0 replies; 8+ messages in thread
From: Raymond Yau @ 2011-02-07 16:12 UTC (permalink / raw)
  To: ALSA Development Mailing List

2011/2/7 Vincent Meserette <vmeserette@aldebaran-robotics.com>

>
> To record four channels simultaneously, I have created the following alsa configuration file :
>
> *# output device
> pcm.AD1989A{
>     type hw
>     card 0
> }
>
> # input device* *
> pcm.quad {
>         type multi
>
>         slaves.a.pcm "hw:0,0,0" # ADC 0 of the codec (left and right mics)
>         slaves.a.channels 2
>         slaves.b.pcm "hw:0,0,1" # ADC 1 of the codec (front and rear mics)
>         slaves.b.channels 2
>
>         bindings.0.slave a
>         bindings.0.channel 0
>         bindings.1.slave a
>         bindings.1.channel 1
>         bindings.2.slave b
>         bindings.2.channel 0
>         bindings.3.slave b
>         bindings.3.channel 1
> }
>
> # input device containing interleaved data
> pcm.quad2 {
>         type route
>         slave.pcm "quad"
>         ttable.0.0 1
>         ttable.1.1 1
>         ttable.2.2 1
>         ttable.3.3 1
> }
>
> ### CTL DEVICES (controls)
> ctl.mixer0 {
>     type hw
>     card 0
> }*
>
> With this configuration file, I am able to record the four channels
> simultaneously with the following command :
>
> arecord -c4 -fS16_LE -r48000 -D «quad2 » -d5 /tmp/recording.wav
>
>
it is strange that I alway got overrun only at the first time of running the
above command but no overrun on the second time

arecord -v -c4 -fS16_LE -r48000 -D quad2  -d5 /tmp/recording.wav
Recording WAVE '/tmp/recording.wav' : Signed 16 bit Little Endian, Rate
48000 Hz, Channels 4
Route conversion PCM
  Transformation table:
    0 <- 0
    1 <- 1
    2 <- 2
    3 <- 3
Its setup is:
  stream       : CAPTURE
  access       : RW_INTERLEAVED
  format       : S16_LE
  subformat    : STD
  channels     : 4
  rate         : 48000
  exact rate   : 48000 (48000/1)
  msbits       : 16
  buffer_size  : 16384
  period_size  : 4096
  period_time  : 85333
  tstamp_mode  : NONE
  period_step  : 1
  avail_min    : 4096
  period_event : 0
  start_threshold  : 1
  stop_threshold   : 16384
  silence_threshold: 0
  silence_size : 0
  boundary     : 1073741824
Slave: Multi PCM
  Channel bindings:
    0: slave 0, channel 0
    1: slave 0, channel 1
    2: slave 1, channel 0
    3: slave 1, channel 1
Its setup is:
  stream       : CAPTURE
  access       : MMAP_COMPLEX
  format       : S16_LE
  subformat    : STD
  channels     : 4
  rate         : 48000
  exact rate   : 48000 (48000/1)
  msbits       : 16
  buffer_size  : 16384
  period_size  : 4096
  period_time  : 85333
  tstamp_mode  : NONE
  period_step  : 1
  avail_min    : 4096
  period_event : 0
  start_threshold  : 1
  stop_threshold   : 16384
  silence_threshold: 0
  silence_size : 0
  boundary     : 1073741824
Slave #0: Hardware PCM card 1 'HDA Intel' device 0 subdevice 0
Its setup is:
  stream       : CAPTURE
  access       : MMAP_INTERLEAVED
  format       : S16_LE
  subformat    : STD
  channels     : 2
  rate         : 48000
  exact rate   : 48000 (48000/1)
  msbits       : 16
  buffer_size  : 16384
  period_size  : 4096
  period_time  : 85333
  tstamp_mode  : NONE
  period_step  : 1
  avail_min    : 4096
  period_event : 0
  start_threshold  : 1
  stop_threshold   : 16384
  silence_threshold: 0
  silence_size : 0
  boundary     : 1073741824
  appl_ptr     : 0
  hw_ptr       : 0
Slave #1: Hardware PCM card 1 'HDA Intel' device 0 subdevice 1
Its setup is:
  stream       : CAPTURE
  access       : MMAP_INTERLEAVED
  format       : S16_LE
  subformat    : STD
  channels     : 2
  rate         : 48000
  exact rate   : 48000 (48000/1)
  msbits       : 16
  buffer_size  : 16384
  period_size  : 4096
  period_time  : 85333
  tstamp_mode  : NONE
  period_step  : 1
  avail_min    : 4096
  period_event : 0
  start_threshold  : 1
  stop_threshold   : 16384
  silence_threshold: 0
  silence_size : 0
  boundary     : 1073741824
  appl_ptr     : 0
  hw_ptr       : 0
overrun!!! (at least 0.001 ms long)
Status:
  state       : XRUN
  trigger_time: 1077.282286934
  tstamp      : 1077.282292637
  delay       : 0
  avail       : 16384
  avail_max   : 16384
overrun!!! (at least 0.001 ms long)
Status:
  state       : XRUN
  trigger_time: 1077.623810402
  tstamp      : 1077.623819150
  delay       : 0
  avail       : 16384

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: issue with AD1989A HDA codec and alsamixer
       [not found]         ` <AANLkTikugTHmj5aKZqXSi3g50gkqLDXiWmTshBbd9TGQ@mail.gmail.com>
  2011-02-07 16:12           ` Raymond Yau
@ 2011-02-08  9:18           ` Raymond Yau
  2011-03-23  6:51           ` Raymond Yau
  2 siblings, 0 replies; 8+ messages in thread
From: Raymond Yau @ 2011-02-08  9:18 UTC (permalink / raw)
  To: ALSA Development Mailing List

2011/2/7 Vincent Meserette <vmeserette@aldebaran-robotics.com>

>
> I found from where came my problem with the capture gains by adding some
> logs in the hda_codec.c file.
> When I set one of the capture gain, the put_vol_mute function well write in
> the AMP_GAIN_MUTE verb of the corresponding ADC selector (0x0c, 0x0d or 0x0e
> widget) but the mute bit is always set to 1.
> Indeed, the value associated to the AMP_GAIN_MUTE verb is formated as folow
> :
> bits  0 to 6 : gain
> bit 7 : mute
> bits 8 to 11 : index
> bit 12 : set right amp
> bit 13 : set left amp
> bit 14 : set input amp
> bit 15 : set output amp
>
> and alsa sets the value of this register from a080 / b080 to a0b6 / b0b6
> when i change the gain from -58.5 dB to 22.5dB
>
> Do you know how alsa and thus the alsamixer determine the minimum and
> maximum values for the capture gain, and how to say to alsa the the gain is
> only a 7bits step value ?
>

Take a look at HDA Specification 7.3.4.10 Amplifier Capabilities

StepSize (7 bits) indicates the size of each step in the gain range. Each
individual step may be 0-32 dB specified in 0.25-dB steps. A value of 0
indicates 0.25-dB steps, while a value of 127d indicates a 32-dB step.
NumSteps (7 bits) indicates the number of steps in the gain range. There may
be from 1 to 128 steps in the amplifier gain range. (0d means 1 step, 127d
means 128 steps). A value of 0 (1 step) means that the gain is fixed and may
not be changed.
Offset (7 bits) indicates which step is 0 dB. If there are two or more
steps, one of the step values must correspond to a value of 0 dB. The
“Offset” value reflects the value which, if programmed in to the Amplifier
Gain control, would result in a gain of 0 dB.
Mute Capable (1 bit) reports if the respective amplifier is capable of
muting. Muting implies a –infinity gain (no sound passes), but the actual
performance is determined by the hardware.


Node 0x0c [Audio Selector] wcaps 0x30010d: Stereo Amp-Out
  Control: name="Capture Volume", index=0, device=0
    ControlAmp: chs=3, dir=Out, idx=0, ofs=0
  Control: name="Capture Switch", index=0, device=0
    ControlAmp: chs=3, dir=Out, idx=0, ofs=0
  Control: name="Input Source", index=0, device=0
  Amp-Out caps: ofs=0x27, nsteps=0x36, stepsize=0x05, mute=1
  Amp-Out vals:  [0x25 0x25]
  Connection: 10
     0x38 0x39* 0x3a 0x3b 0x3c 0x18 0x24 0x25 0x3d 0x20
Node 0x0d [Audio Selector] wcaps 0x30010d: Stereo Amp-Out
  Control: name="Capture Volume", index=1, device=0
    ControlAmp: chs=3, dir=Out, idx=0, ofs=0
  Control: name="Capture Switch", index=1, device=0
    ControlAmp: chs=3, dir=Out, idx=0, ofs=0
  Control: name="Input Source", index=1, device=0
  Amp-Out caps: ofs=0x27, nsteps=0x36, stepsize=0x05, mute=1
  Amp-Out vals:  [0xa7 0xa7]
  Connection: 10
     0x38 0x39* 0x3a 0x3b 0x3c 0x18 0x24 0x25 0x3d 0x20
Node 0x0e [Audio Selector] wcaps 0x30010d: Stereo Amp-Out
  Control: name="Capture Volume", index=2, device=0
    ControlAmp: chs=3, dir=Out, idx=0, ofs=0
  Control: name="Capture Switch", index=2, device=0
    ControlAmp: chs=3, dir=Out, idx=0, ofs=0
  Control: name="Input Source", index=2, device=0
  Amp-Out caps: ofs=0x27, nsteps=0x36, stepsize=0x05, mute=1
  Amp-Out vals:  [0xa7 0xa7]
  Connection: 10
     0x38 0x39* 0x3a 0x3b 0x3c 0x18 0x24 0x25 0x3d 0x20

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: issue with AD1989A HDA codec and alsamixer
       [not found]         ` <AANLkTikugTHmj5aKZqXSi3g50gkqLDXiWmTshBbd9TGQ@mail.gmail.com>
  2011-02-07 16:12           ` Raymond Yau
  2011-02-08  9:18           ` Raymond Yau
@ 2011-03-23  6:51           ` Raymond Yau
  2 siblings, 0 replies; 8+ messages in thread
From: Raymond Yau @ 2011-03-23  6:51 UTC (permalink / raw)
  To: ALSA Development Mailing List

2011/2/7 Vincent Meserette <vmeserette@aldebaran-robotics.com>

> Hi Raymond,
>
> Thanks for your reply.
>
> To reply to your question, indeed the AD1989A codec is seen by alsa as a
> device containing three subdevices (the three ADC) :
>
>  result of arecord -l :
>  List of CAPTURE Hardware Devices :
>
>  card 0: MID [HDA Intel MID], device 0: AD198x Analog [AD198x Analog]
>
>  Subdevices: 3/3
>  Subdevice #0: subdevice #0
>  Subdevice #1: subdevice #1
>  Subdevice #2: subdevice #2
>
>
> To record four channels simultaneously, I have created the following alsa configuration file :
>
> *# output device
> pcm.AD1989A{
>     type hw
>     card 0
> }
>
> # input device* *
> pcm.quad {
>         type multi
>
>         slaves.a.pcm "hw:0,0,0" # ADC 0 of the codec (left and right mics)
>         slaves.a.channels 2
>         slaves.b.pcm "hw:0,0,1" # ADC 1 of the codec (front and rear mics)
>         slaves.b.channels 2
>
>         bindings.0.slave a
>         bindings.0.channel 0
>         bindings.1.slave a
>         bindings.1.channel 1
>         bindings.2.slave b
>         bindings.2.channel 0
>         bindings.3.slave b
>         bindings.3.channel 1
> }
>
> # input device containing interleaved data
> pcm.quad2 {
>         type route
>         slave.pcm "quad"
>         ttable.0.0 1
>         ttable.1.1 1
>         ttable.2.2 1
>         ttable.3.3 1
> }
>
> ### CTL DEVICES (controls)
> ctl.mixer0 {
>     type hw
>     card 0
> }*
>
> With this configuration file, I am able to record the four channels
> simultaneously with the following command :
>
> arecord -c4 -fS16_LE -r48000 -D «quad2 » -d5 /tmp/recording.wav
>
>
> I found from where came my problem with the capture gains by adding some
> logs in the hda_codec.c file.
> When I set one of the capture gain, the put_vol_mute function well write in
> the AMP_GAIN_MUTE verb of the corresponding ADC selector (0x0c, 0x0d or 0x0e
> widget) but the mute bit is always set to 1.
> Indeed, the value associated to the AMP_GAIN_MUTE verb is formated as folow
> :
> bits  0 to 6 : gain
> bit 7 : mute
> bits 8 to 11 : index
> bit 12 : set right amp
> bit 13 : set left amp
> bit 14 : set input amp
> bit 15 : set output amp
>
> and alsa sets the value of this register from a080 / b080 to a0b6 / b0b6
> when i change the gain from -58.5 dB to 22.5dB
>
> Do you know how alsa and thus the alsamixer determine the minimum and
> maximum values for the capture gain, and how to say to alsa the the gain is
> only a 7bits step value ?
>
> Thanks in advance.
>
> Best regards
>
> Vincent
>
>
>
>
>
> 2011/2/5 Raymond Yau <superquad.vortex2@gmail.com>
>
>> 2011/2/3 Vincent Meserette <vmeserette@aldebaran-robotics.com>
>>
>> > Hi Raymond,
>> >
>> > Many thanks for your answer.
>> >
>> > Looking the AD1989A datasheet (which can be found here :
>> > http://www.conexant.com/products/entry.jsp?id=599) the vendor id of the
>> > codec seems to be 11D4989A
>> > So, I think the codec taken into account in the "patch_analog.c" file is
>> > well the AD1989A because I found these lines in the source code :
>> >
>> > /*
>> >  * patch entries
>> >  */
>> > static struct hda_codec_preset snd_hda_preset_analog[] = {
>> >    ...
>> >     { .id = 0x11d4989a, .name = "AD1989A", .patch = patch_ad1988 },
>> >    ...
>> >     {} /* terminator */
>> > };
>> >
>> > Concerning the digital microphone input of the codec, I don't use it. I
>> > have four electret microphones connected to the B and C ports of the
>> codec
>> > (one on the PORT-B_L pin, one on the PORT-B_R pin, one on the PORT-C_L
>> pin
>> > and one on the PORT-C_R pin). I have connected by software configuration
>> the
>> > port B to the ADC1 and the port C to the ADC0.
>> > Maybe my problem comes from here, because I don't use the codec in a
>> > standard configuration ?
>> > if it is the case, do you know how can i resolve it ?
>> > Do you also know which registers control the three capture gains of the
>> > alsamixerl (i thought it was the gains of the ADC0, ADC1 and ADC2 )?
>> >
>>
>> can you post the output of alsa-info.sh
>>
>> Six 192kHz 92dB ADCs
>> - simultaneous record of up to 3 stereo channels
>>
>> It does not imply you can record 4 channels with the existing hda driver
>> which create three subdevices
>>
>


when  recording with 4 channels using audacity with my ad1988a, audacity
hang after a few seconds or half minute

Does snd-hda-inel really suport SNDRV_PCM_INFO_SYNC_START ?


ALSA pcm_lib.c:374: period_update: pcmC0D0c:0: pos=0/1216/4864,
hwptr=1216/314944/316160/311296
ALSA pcm_lib.c:374: period_update: pcmC0D0c:1: pos=1/1216/4864,
hwptr=1216/314945/316161/311296
ALSA pcm_lib.c:374: period_update: pcmC0D0c:0: pos=1216/1216/4864,
hwptr=1207/316169/317376/316160
ALSA pcm_lib.c:374: period_update: pcmC0D0c:1: pos=1217/1216/4864,
hwptr=1216/316161/317377/316160
ALSA pcm_lib.c:374: period_update: pcmC0D0c:0: pos=2432/1216/4864,
hwptr=1216/317376/318592/316160
ALSA pcm_lib.c:374: period_update: pcmC0D0c:1: pos=2433/1216/4864,
hwptr=1216/317377/318593/316160
ALSA pcm_lib.c:374: period_update: pcmC0D0c:0: pos=3648/1216/4864,
hwptr=1199/318609/319808/316160
ALSA pcm_lib.c:374: period_update: pcmC0D0c:1: pos=3649/1216/4864,
hwptr=1216/318593/319809/316160
ALSA pcm_lib.c:374: period_update: pcmC0D0c:0: pos=0/1216/4864,
hwptr=1216/319808/321024/316160
ALSA pcm_lib.c:374: period_update: pcmC0D0c:1: pos=1/1216/4864,
hwptr=1216/319809/321025/316160
ALSA pcm_lib.c:374: period_update: pcmC0D0c:0: pos=1216/1216/4864,
hwptr=1207/321033/322240/321024
ALSA pcm_lib.c:374: period_update: pcmC0D0c:1: pos=1217/1216/4864,
hwptr=1216/321025/322241/321024
ALSA pcm_lib.c:374: period_update: pcmC0D0c:0: pos=2432/1216/4864,
hwptr=1216/322240/323456/321024
ALSA pcm_lib.c:374: period_update: pcmC0D0c:1: pos=2433/1216/4864,
hwptr=1216/322241/323457/321024
ALSA pcm_lib.c:374: period_update: pcmC0D0c:0: pos=3648/1216/4864,
hwptr=1199/323473/324672/321024
ALSA pcm_lib.c:374: period_update: pcmC0D0c:1: pos=3649/1216/4864,
hwptr=1216/323457/324673/321024
ALSA pcm_lib.c:374: period_update: pcmC0D0c:0: pos=0/1216/4864,
hwptr=1216/324672/325888/321024
ALSA pcm_lib.c:374: period_update: pcmC0D0c:1: pos=1/1216/4864,
hwptr=1216/324673/325889/321024
ALSA pcm_lib.c:374: period_update: pcmC0D0c:0: pos=1216/1216/4864,
hwptr=1184/325920/327104/325888
ALSA pcm_lib.c:374: period_update: pcmC0D0c:1: pos=1217/1216/4864,
hwptr=1216/325889/327105/325888
ALSA pcm_lib.c:374: period_update: pcmC0D0c:0: pos=2432/1216/4864,
hwptr=1216/327104/328320/325888
ALSA pcm_lib.c:374: period_update: pcmC0D0c:1: pos=2433/1216/4864,
hwptr=1216/327105/328321/325888
ALSA pcm_lib.c:374: period_update: pcmC0D0c:0: pos=3648/1216/4864,
hwptr=1215/328321/329536/325888
ALSA pcm_lib.c:374: period_update: pcmC0D0c:1: pos=3649/1216/4864,
hwptr=1216/328321/329537/325888
ALSA pcm_lib.c:374: period_update: pcmC0D0c:0: pos=0/1216/4864,
hwptr=1216/329536/330752/325888
ALSA pcm_lib.c:374: period_update: pcmC0D0c:1: pos=1/1216/4864,
hwptr=1216/329537/330753/325888


ALSA pcm_lib.c:172: XRUN: pcmC0D0c:1

 [<f895f201>] xrun+0x97/0x9e [snd_pcm]
 [<f895f859>] snd_pcm_update_state+0x74/0xc1 [snd_pcm]
 [<f895fe03>] snd_pcm_update_hw_ptr0+0x55d/0x569 [snd_pcm]
 [<c042823f>] ? default_wake_function+0xb/0xd
 [<c0421fd3>] ? __wake_up+0x31/0x3b
 [<f895fe89>] snd_pcm_period_elapsed+0x7a/0xe9 [snd_pcm]
 [<f8a41744>] azx_interrupt+0x99/0x120 [snd_hda_intel]
 [<c046548f>] handle_IRQ_event+0x2f/0x64
 [<c04664f8>] handle_fasteoi_irq+0x85/0xc0
 [<c0466473>] ? handle_fasteoi_irq+0x0/0xc0
 [<c0406e6e>] do_IRQ+0xc7/0xfe
 [<c0405668>] common_interrupt+0x28/0x30
 [<c040a112>] ? mwait_idle+0x38/0x4b
 [<c0403c61>] cpu_idle+0x101/0x134
 [<c06a7db4>] start_secondary+0x197/0x19f

 =======================
ALSA hda_intel.c:1679: azx_pcm_prepare: bufsize=0x4c00, format=0x11
ALSA hda_codec.c:1228: hda_codec_setup_stream: NID=0x8, stream=0x1,
channel=0, format=0x11
ALSA hda_intel.c:1679: azx_pcm_prepare: bufsize=0x4c00, format=0x11
ALSA hda_codec.c:1228: hda_codec_setup_stream: NID=0x9, stream=0x2,
channel=0, format=0x11
ALSA hda_intel.c:1679: azx_pcm_prepare: bufsize=0x4c00, format=0x11
ALSA hda_codec.c:1228: hda_codec_setup_stream: NID=0x8, stream=0x1,
channel=0, format=0x11
ALSA hda_intel.c:1679: azx_pcm_prepare: bufsize=0x4c00, format=0x11
ALSA hda_codec.c:1228: hda_codec_setup_stream: NID=0x9, stream=0x2,
channel=0, format=0x11
ALSA hda_codec.c:1291: hda_codec_cleanup_stream: NID=0x8
ALSA hda_codec.c:1291: hda_codec_cleanup_stream: NID=0x9
ALSA hda_codec.c:1291: hda_codec_cleanup_stream: NID=0x8
ALSA hda_codec.c:1291: hda_codec_cleanup_stream: NID=0x9

^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2011-03-23  6:51 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-02-01 14:57 issue with AD1989A HDA codec and alsamixer Vincent Meserette
2011-02-02  0:15 ` Raymond Yau
2011-02-02  6:16   ` Raymond Yau
2011-02-02 19:22     ` Vincent Meserette
2011-02-05  9:46       ` Raymond Yau
     [not found]         ` <AANLkTikugTHmj5aKZqXSi3g50gkqLDXiWmTshBbd9TGQ@mail.gmail.com>
2011-02-07 16:12           ` Raymond Yau
2011-02-08  9:18           ` Raymond Yau
2011-03-23  6:51           ` Raymond Yau

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.