Invalid PCM pointer with CMI8738 and pcm.c buffer underuns

Invalid PCM pointer with CMI8738 and pcm.c buffer underuns

[andoru]

I've previously posted under ALSA's user mailing list so to avoid the
clutter, the details about what's happening is here:
http://article.gmane.org/gmane.linux.alsa.user/38258
http://article.gmane.org/gmane.linux.alsa.user/38260

There was no debug info under /proc/asound/card0/ so nothing to give from
there unless you guys need something specific.

Output of alsa-debug.sh:
http://www.alsa-project.org/db/?f=26187faadd47f3626029ba667cb004e74695f2b2

aplay returns:
________________________________________________________________________
$ aplay -vv 03\ paris\ match-\ Bikeride.wav
Playing WAVE '03 paris match- Bikeride.wav' : Signed 16 bit Little Endian,
Rate 44100 Hz, Stereo
Plug PCM: Direct Stream Mixing PCM
Its setup is:
  stream       : PLAYBACK
  access       : RW_INTERLEAVED
  format       : S16_LE
  subformat    : STD
  channels     : 2
  rate         : 44100
  exact rate   : 44100 (44100/1)
  msbits       : 16
  buffer_size  : 4096
  period_size  : 1024
  period_time  : 23219
  tstamp_mode  : NONE
  period_step  : 1
  avail_min    : 1024
  period_event : 0
  start_threshold  : 4096
  stop_threshold   : 4096
  silence_threshold: 0
  silence_size : 0
  boundary     : 1073741824
Hardware PCM card 0 'C-Media CMI8738' device 0 subdevice 0
Its setup is:
  stream       : PLAYBACK
  access       : MMAP_INTERLEAVED
  format       : S16_LE
  subformat    : STD
  channels     : 2
  rate         : 44100
  exact rate   : 44100 (44100/1)
  msbits       : 16
  buffer_size  : 4096
  period_size  : 1024
  period_time  : 23219
  tstamp_mode  : ENABLE
  period_step  : 1
  avail_min    : 1024
  period_event : 0
  start_threshold  : 1
  stop_threshold   : 1073741824
  silence_threshold: 0
  silence_size : 1073741824
  boundary     : 1073741824
  appl_ptr     : 0
  hw_ptr       : 0
#+                                                 | 00%
_____________________________________________________________________

Re: Invalid PCM pointer with CMI8738 and pcm.c buffer underuns

[Raymond Yau]

>
> I've previously posted under ALSA's user mailing list so to avoid the
> clutter, the details about what's happening is here:
> http://article.gmane.org/gmane.linux.alsa.user/38258
> http://article.gmane.org/gmane.linux.alsa.user/38260
>
> There was no debug info under /proc/asound/card0/ so nothing to give from
> there unless you guys need something specific.
>
> Output of alsa-debug.sh:
> http://www.alsa-project.org/db/?f=26187faadd47f3626029ba667cb004e74695f2b2

https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/commit/sound/pci/cmipci.c?id=1c583063a5c769fe2ec604752e383972c69e6d9b

Seem cannot read valid value from register within three trials

state.CMI8738 {
control.1 {
iface PCM
device 2
name 'Playback Channel Map'
value.0 0
value.1 0
value.2 0
value.3 0
value.4 0
value.5 0
comment {
access read
type INTEGER
count 6
range '0 - 36'
}
}

Seem bug in adding channel map to iec958 instead of analog

https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/commit/sound/pci/cmipci.c?id=f49921b894ec338696e47d985acc09df3cddbfd1

pcm.!default {
    type plug
    slave.pcm "dmixer"
}

You need asym plugin for playback and capture when overwrite pcm.default

Re: Invalid PCM pointer with CMI8738 and pcm.c buffer underuns

[andoru]

> Seem cannot read valid value from register within three trials
> 
> state.CMI8738 {
> control.1 {
> 
> [...]
> 
> Seem bug in adding channel map to iec958 instead of analog

What does that mean? What should I do with those patches?
Should I apply them and try to compile the latest ALSA version?

> 
> pcm.!default {
>     type plug
>     slave.pcm "dmixer"
> }
> 
> You need asym plugin for playback and capture when overwrite pcm.default
> 

Should I change my /etc/asound.conf like in the examples here?
http://alsa.opensrc.org/Asym

Re: Invalid PCM pointer with CMI8738 and pcm.c buffer underuns

[Raymond Yau]

https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/commit/sound/pci/cmipci.c?id=1c583063a5c769fe2ec604752e383972c69e6d9b

you have to dump the value of the register and increase the number of
trials to find out whether you can get a valid value


>
> >
> > state.CMI8738 {
> > control.1 {
> >
> > [...]
> >
> > Seem bug in adding channel map to iec958 instead of analog
>
> What does that mean? What should I do with those patches?
> Should I apply them and try to compile the latest ALSA version?

the patch did not channel map to the analog device

control.1 {
iface PCM
device 2
name 'Playback Channel Map'
value.0 0
value.1 0
value.2 0
value.3 0
value.4 0
value.5 0
comment {
access read
type INTEGER
count 6
range '0 - 36'
}
}

!!Aplay/Arecord output
!!--------------------

APLAY

**** List of PLAYBACK Hardware Devices ****
card 0: CMI8738 [C-Media CMI8738], device 0: CMI8738-MC6 [C-Media PCI
DAC/ADC]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: CMI8738 [C-Media CMI8738], device 1: CMI8738-MC6 [C-Media PCI 2nd
DAC]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: CMI8738 [C-Media CMI8738], device 2: CMI8738-MC6 [C-Media PCI
IEC958]
  Subdevices: 1/1
  Subdevice #0: subdevice #0

https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/commit/sound/pci/cmipci.c?id=1da177e4c3f41524e886b7f1b8a0c1fc7321cac2

http://git.alsa-project.org/?p=alsa-lib.git;a=blob;f=src/conf/cards/CMI8738-MC6.conf;hb=HEAD

CMI8738-MC6.pcm.rear.0 {

         @args [ CARD ]
         @args.CARD {
                type string
         }
         type hw
         card $CARD
         device 1
}

device 0 seem emulate sb16 , you need to ask the author how this driver
support multi-channels

seem device 1 is used for multi-channels playback and device 2 is used for
iec958
>
>
> >
> > pcm.!default {
> >     type plug
> >     slave.pcm "dmixer"
> > }
> >
> > You need asym plugin for playback and capture when overwrite pcm.default
> >
>
> Should I change my /etc/asound.conf like in the examples here?
> http://alsa.opensrc.org/Asym
>

yes, you need define both playback and capture if you overwrite pcm.default
 since dmix does not support capture

Re: Invalid PCM pointer with CMI8738 and pcm.c buffer underuns

[Clemens Ladisch]

Raymond Yau wrote:
> https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/commit/sound/pci/cmipci.c?id=1c583063a5c769fe2ec604752e383972c69e6d9b
>
> you have to dump the value of the register and increase the number of
> trials to find out whether you can get a valid value

As shown in the bug, the register fails continuously; this is not
a transient failure that could be worked around like in that commit.

>>> Seem bug in adding channel map to iec958 instead of analog
>>
>> What does that mean?

Nothing relevant to this problem.

>> What should I do with those patches?

Nothing.


Regards,
Clemens

Re: Invalid PCM pointer with CMI8738 and pcm.c buffer underuns

[andoru]

> yes, you need define both playback and capture if you overwrite pcm.default
> since dmix does not support capture

I'm less concerned with the capture part of this card as I record audio
through the mic of the webcam anyway. But having added that, it hasn't
solved my previous problem with not being able to hear sounds from multiple
sources, and also I can't use alsamixer now.

> >>> Seem bug in adding channel map to iec958 instead of analog
> >>
> >> What does that mean?
> 
> Nothing relevant to this problem.
> 
> >> What should I do with those patches?
> 
> Nothing.

So I guess that means there aren't really any solutions to my bug? What
happens next? (sorry for all the annoying questions)

Re: Invalid PCM pointer with CMI8738 and pcm.c buffer underuns

[Clemens Ladisch]

andoru wrote:
> So I guess that means there aren't really any solutions to my bug?

It sounds like a hardware error.  You will have to replace the card.


Regards,
Clemens

Re: Invalid PCM pointer with CMI8738 and pcm.c buffer underuns

[Takashi Iwai]

At Tue, 29 Apr 2014 13:06:59 +0000 (UTC),
Andoru wrote:
> 
> > 
> > It should be applicable to most of existing versions.
> 
> Existing versions of what...?

Existing versions of Linux kernels.


Takashi

Re: Invalid PCM pointer with CMI8738 and pcm.c buffer underuns

[Andoru]

> 
> It should be applicable to most of existing versions.

Existing versions of what...?

Re: Invalid PCM pointer with CMI8738 and pcm.c buffer underuns

[Takashi Iwai]

At Mon, 28 Apr 2014 21:28:42 +0000 (UTC),
Andoru wrote:
> 
> [Continued from here:
> http://thread.gmane.org/gmane.linux.alsa.devel/122028/focus=122354 ]
> 
> > It's way too old.  Better to build the latest kernel.
> 
> The latest kernel available for my distro, or the latest kernel available
> "from Linus"? I've already tried the former.

The latter.

> > You need to figure out the condition reproducing the issue.
> 
> For all I know (I'm not that knowledgeable on those things, mind you) this
> happens completely at random. There hasn't been any pattern when the PC
> would become unusable, and the OS unresponsive.

If it's completely random, it's a hardware problem, and impossible to
fix properly.  If there is some condition (i.e. happens only when
using this period size and buffer size, etc), then we have a chance to
fix.  You have to figure out it by yourself.  Note that the condition
doesn't mean only the timing.  It means the audio setup you're using,
too.

> > For example, application may apply some strange buffer size and period
> > size the hardware chip doesn't like. If so, changing the buffer size
> > and/or period size may reduce the problem.
> 
> I'm not aware of any feature to change the buffer size in any of the
> programs that cause the lock-ups.

If so, try another program (or better to write a test case by
yourself) to reproduce the problem more easily and allow you to adjust
the parameters to figure out the condition.

> > Meanwhile, you can try the patch below, too, which aligns the period
> 
> That patch is for kernel sources or for the above snapshots I mentioned? Or
> perhaps there are more recent ALSA source codes?

It should be applicable to most of existing versions.


Takashi

Re: Invalid PCM pointer with CMI8738 and pcm.c buffer underuns

[Andoru]

Sorry, meant to reply this:
http://thread.gmane.org/gmane.linux.alsa.devel/122028/focus=122362 to you
instead.

Invalid PCM pointer with CMI8738 and pcm.c buffer underuns

[Andoru]

[Continued from here:
http://thread.gmane.org/gmane.linux.alsa.devel/122028/focus=122354 ]

> It's way too old.  Better to build the latest kernel.

The latest kernel available for my distro, or the latest kernel available
"from Linus"? I've already tried the former.

> You need to figure out the condition reproducing the issue.

For all I know (I'm not that knowledgeable on those things, mind you) this
happens completely at random. There hasn't been any pattern when the PC
would become unusable, and the OS unresponsive.

> For example, application may apply some strange buffer size and period
> size the hardware chip doesn't like. If so, changing the buffer size
> and/or period size may reduce the problem.

I'm not aware of any feature to change the buffer size in any of the
programs that cause the lock-ups.

> Meanwhile, you can try the patch below, too, which aligns the period

That patch is for kernel sources or for the above snapshots I mentioned? Or
perhaps there are more recent ALSA source codes?

Re: Invalid PCM pointer with CMI8738 and pcm.c buffer underuns

[Takashi Iwai]

At Sun, 20 Apr 2014 15:04:48 +0000 (UTC),
Andoru wrote:
> 
> [Continued from here:
> http://news.gmane.org/find-root.php?message_id=loom.20140406T010044%2d863%40post.gmane.org]
> 
> Since I didn't get any answer again, I decided to try and build the latest
> ALSA snapshots myself (alsa-driver-1.0.25.3584.gb044d;

It's way too old.  Better to build the latest kernel.

> alsa-firmware-1.0.27.2.gf21a8; alsa-lib-1.0.27.2; alsa-oss-1.0.25.2.g39df1;
> alsa-plugins-1.0.27.10.gb5917; alsa-utils-1.0.27.2.22.gb7ed4) and purge the
> Debian ALSA packages to see if I could do something at compile time or if it
> would fix the problems, but they're still there. The OS still slows down to
> a crawl at random times and I still have the issue with the volume control
> plus other quirks I mentioned in the previous threads...

You need to figure out the condition reproducing the issue.  For
example, application may apply some strange buffer size and period
size the hardware chip doesn't like.  If so, changing the buffer size
and/or period size may reduce the problem.

Meanwhile, you can try the patch below, too, which aligns the period
size.


Takashi

---
diff --git a/sound/pci/cmipci.c b/sound/pci/cmipci.c
index 12c318e175f4..e8c8a2256fd2 100644
--- a/sound/pci/cmipci.c
+++ b/sound/pci/cmipci.c
@@ -1683,6 +1683,7 @@ static int snd_cmipci_playback_open(struct snd_pcm_substream *substream)
 		runtime->hw.rate_max = 128000;
 	}
 	snd_pcm_hw_constraint_minmax(runtime, SNDRV_PCM_HW_PARAM_BUFFER_SIZE, 0, 0x10000);
+	snd_pcm_hw_constraint_integer(runtime, SNDRV_PCM_HW_PARAM_PERIODS);
 	cm->dig_pcm_status = cm->dig_status;
 	return 0;
 }
@@ -1708,6 +1709,7 @@ static int snd_cmipci_capture_open(struct snd_pcm_substream *substream)
 		runtime->hw.rate_max = 128000;
 	}
 	snd_pcm_hw_constraint_minmax(runtime, SNDRV_PCM_HW_PARAM_BUFFER_SIZE, 0, 0x10000);
+	snd_pcm_hw_constraint_integer(runtime, SNDRV_PCM_HW_PARAM_PERIODS);
 	return 0;
 }
 
@@ -1746,6 +1748,7 @@ static int snd_cmipci_playback2_open(struct snd_pcm_substream *substream)
 		runtime->hw.rate_max = 128000;
 	}
 	snd_pcm_hw_constraint_minmax(runtime, SNDRV_PCM_HW_PARAM_BUFFER_SIZE, 0, 0x10000);
+	snd_pcm_hw_constraint_integer(runtime, SNDRV_PCM_HW_PARAM_PERIODS);
 	return 0;
 }
 
@@ -1772,6 +1775,7 @@ static int snd_cmipci_playback_spdif_open(struct snd_pcm_substream *substream)
 		runtime->hw = snd_cmipci_playback_iec958_subframe;
 	}
 	snd_pcm_hw_constraint_minmax(runtime, SNDRV_PCM_HW_PARAM_BUFFER_SIZE, 0, 0x40000);
+	snd_pcm_hw_constraint_integer(runtime, SNDRV_PCM_HW_PARAM_PERIODS);
 	cm->dig_pcm_status = cm->dig_status;
 	return 0;
 }
@@ -1791,6 +1795,7 @@ static int snd_cmipci_capture_spdif_open(struct snd_pcm_substream *substream)
 		runtime->hw.rate_max = 96000;
 	}
 	snd_pcm_hw_constraint_minmax(runtime, SNDRV_PCM_HW_PARAM_BUFFER_SIZE, 0, 0x40000);
+	snd_pcm_hw_constraint_integer(runtime, SNDRV_PCM_HW_PARAM_PERIODS);
 	return 0;
 }
 

Invalid PCM pointer with CMI8738 and pcm.c buffer underuns

[Andoru]

[Continued from here:
http://news.gmane.org/find-root.php?message_id=loom.20140406T010044%2d863%40post.gmane.org]

Since I didn't get any answer again, I decided to try and build the latest
ALSA snapshots myself (alsa-driver-1.0.25.3584.gb044d;
alsa-firmware-1.0.27.2.gf21a8; alsa-lib-1.0.27.2; alsa-oss-1.0.25.2.g39df1;
alsa-plugins-1.0.27.10.gb5917; alsa-utils-1.0.27.2.22.gb7ed4) and purge the
Debian ALSA packages to see if I could do something at compile time or if it
would fix the problems, but they're still there. The OS still slows down to
a crawl at random times and I still have the issue with the volume control
plus other quirks I mentioned in the previous threads...

Re: Invalid PCM pointer with CMI8738 and pcm.c buffer underuns

[Andoru]

Okay, nevermind, the OS froze as I've tried to change the level on the PCM
channel, so I rebooted and tried to look for anything that might have left a
trace for what has happened, and I think I found what you were looking for:
http://pastebin.com/YfP61KBk

It was under /var/log/messages.0 (same things also under /var/log/syslog for
some weird reason)
I haven't been able to see what caused the freezing.

Also found this, not sure if it's useful:
_______________________________________________________________________
Apr 12 23:30:50 flying-topsoil kernel: [18087.771787]  [<c12b3777>] ?
dump_stack+0xa/0x13
Apr 12 23:30:50 flying-topsoil kernel: [18087.771813]  [<f819d839>] ?
xrun+0x9a/0xb2 [snd_pcm]
Apr 12 23:30:50 flying-topsoil kernel: [18087.771824]  [<c104e65d>] ?
ktime_get_ts+0x30/0x77
Apr 12 23:30:50 flying-topsoil kernel: [18087.771838]  [<f819e43c>] ?
snd_pcm_update_hw_ptr0+0x91/0x744 [snd_pcm]
Apr 12 23:30:50 flying-topsoil kernel: [18087.771847]  [<c103bca3>] ?
hrtimer_start_range_ns+0x20/0x25
Apr 12 23:30:50 flying-topsoil kernel: [18087.771853]  [<c103b9c2>] ?
hrtimer_try_to_cancel+0x4a/0x51
Apr 12 23:30:50 flying-topsoil kernel: [18087.771864]  [<f8198cbb>] ?
snd_pcm_hwsync+0x30/0x46 [snd_pcm]
Apr 12 23:30:50 flying-topsoil kernel: [18087.771874]  [<f819ab7b>] ?
snd_pcm_common_ioctl1+0x5c/0xa0f [snd_pcm]
_______________________________________________________________________

Re: Invalid PCM pointer with CMI8738 and pcm.c buffer underuns

[Andoru]

> 
> You need root privilege to debug
> 
> sudo echo 11 > /proc/asound/card0/pcm0p/xrun_debug

___________________________________________________________
$ sudo echo 11 > /proc/asound/card0/pcm0p/xrun_debug
___________________________________________________________

implies:
___________________________________________________________
# echo 11 > /proc/asound/card0/pcm0p/xrun_debug
___________________________________________________________

So I did have root priviledges when I executed that command, and it still
gives me a Permission denied error.

I tried the command under root and it accepted the command but didn't print
anything after issuing the command. So I guess it worked?

> Check the system log , you should find the hwptr change at 10ms interval if
> vlc use period time of 10ms

Again, what system log? Be a little bit more specific please.

> Try different period time/size to verify that the hardware really support
> any  arbitrary period time/size requested by the application ?

VLC doesn't have any options or terminal parameters to be able to change the
period as you mention.

Re: Invalid PCM pointer with CMI8738 and pcm.c buffer underuns

[Raymond Yau]

>
> Continued from here:
http://article.gmane.org/gmane.linux.alsa.devel/121575
>
> > http://www.alsa-project.org/main/index.php/XRUN_Debug
> >
> > # Enable basic debugging and dump stack, check hardware pointer on the
> > period update
> > # Usefull to just see, if PCM stream is stopped for a reason (usually
wrong
> > audio process timing from scheduler)
> > # And to check the values from driver
> >
> > echo 11 > /proc/asound/card0/pcm0p/xrun_debug
>
> Okay, I not compiled my own kernel with CONFIG_SND_PCM_XRUN_DEBUG,
> CONFIG_SND_VERBOSE_PROCFS, CONFIG_SND_DEBUG all enabled in the kernel
> configuration, I have an xrun_debug file, but it doesn't seem to list
> anything, then I also tried with cat instead of echo, and just a 0 showed
up:
>
> ___________________________________________________________________
> $ echo 11 > /proc/asound/card0/pcm0p/xrun_debug
> bash: /proc/asound/card0/pcm0p/xrun_debug: Permission denied
>
> # echo 11 > /proc/asound/card0/pcm0p/xrun_debug
> bash: /proc/asound/card0/pcm0p/xrun_debug: Permission denied
>
> $ cat /proc/asound/card0/pcm0p/xrun_debug
> 0

You need root privilege to debug

sudo echo 11 > /proc/asound/card0/pcm0p/xrun_debug

Check the system log , you should find the hwptr change at 10ms interval if
vlc use period time of 10ms

Try different period time/size to verify that the hardware really support
any  arbitrary period time/size requested by the application ?

Invalid PCM pointer with CMI8738 and pcm.c buffer underuns

[andoru]

Continued from here: http://article.gmane.org/gmane.linux.alsa.devel/121575

> http://www.alsa-project.org/main/index.php/XRUN_Debug
> 
> # Enable basic debugging and dump stack, check hardware pointer on the
> period update
> # Usefull to just see, if PCM stream is stopped for a reason (usually wrong
> audio process timing from scheduler)
> # And to check the values from driver
> 
> echo 11 > /proc/asound/card0/pcm0p/xrun_debug

Okay, I not compiled my own kernel with CONFIG_SND_PCM_XRUN_DEBUG,
CONFIG_SND_VERBOSE_PROCFS, CONFIG_SND_DEBUG all enabled in the kernel
configuration, I have an xrun_debug file, but it doesn't seem to list
anything, then I also tried with cat instead of echo, and just a 0 showed up:

___________________________________________________________________
$ echo 11 > /proc/asound/card0/pcm0p/xrun_debug
bash: /proc/asound/card0/pcm0p/xrun_debug: Permission denied

# echo 11 > /proc/asound/card0/pcm0p/xrun_debug
bash: /proc/asound/card0/pcm0p/xrun_debug: Permission denied

$ cat /proc/asound/card0/pcm0p/xrun_debug
0
___________________________________________________________________

Re: Invalid PCM pointer with CMI8738 and pcm.c buffer underuns

[andoru]

Raymond Yau <superquad.vortex2 <at> gmail.com> writes:


> http://www.alsa-project.org/main/index.php/XRUN_Debug
> 
> # Enable basic debugging and dump stack, check hardware pointer on the
> period update
> # Usefull to just see, if PCM stream is stopped for a reason (usually wrong
> audio process timing from scheduler)
> # And to check the values from driver
> 
> echo 11 > /proc/asound/card0/pcm0p/xrun_debug

Argh, seems the kernel I'm using doesn't have the debug options.
Any other ways around this?

> Check the system log whether the hwptr position are correct in first nine
> periods and xrun  occur on 10th period since the buffer contain 9.27
> periods when running vlc?

Which system log? Or maybe this is related to the above? I can't find
anything in any file under /var/log/ that contains anything you're talking
about. 
 
>
https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/plain/Documentation
>/sound/alsa/CMIPCI.txt
> 
> cat /proc/asound/card0/cmipci
> 
> What is the model of your sound card ?

____________________________________________________
$ cat /proc/asound/card0/cmipci
C-Media CMI8738 (model 55) at 0xe000, irq 18

00: 02 00 01 00
04: d0 0d 00 00
08: 83 00 09 00
0c: 00 00 01 0a
10: c0 00 00 00
14: 00 60 c0 00
18: 00 01 80 0e
1c: 00 00 ee ee
20: 10 40 f9 00
24: 8f ff ff 06
90: 20 09 00 00
____________________________________________________


> Does it support 4 and 6 channels in windows ?

6 channels. I don't use more than 2 channels anyway.

Re: Invalid PCM pointer with CMI8738 and pcm.c buffer underuns

[Raymond Yau]

> >
> > does the hardware really support (16384/1764)
> > 9.27 periods?
> > does the error occur in the last period ?
>
> I have no idea, how do I find out? What last period?

http://www.alsa-project.org/main/index.php/XRUN_Debug

# Enable basic debugging and dump stack, check hardware pointer on the
period update
# Usefull to just see, if PCM stream is stopped for a reason (usually wrong
audio process timing from scheduler)
# And to check the values from driver

echo 11 > /proc/asound/card0/pcm0p/xrun_debug

Check the system log whether the hwptr position are correct in first nine
periods and xrun  occur on 10th period since the buffer contain 9.27
periods when running vlc?

https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/plain/Documentation/sound/alsa/CMIPCI.txt

cat /proc/asound/card0/cmipci

What is the model of your sound card ?

Does it support 4 and 6 channels in windows ?

Re: Invalid PCM pointer with CMI8738 and pcm.c buffer underuns

[andoru]

Raymond Yau <superquad.vortex2 <at> gmail.com> writes:
> 
> does the hardware really support (16384/1764)
> 9.27 periods?
> does the error occur in the last period ?

I have no idea, how do I find out? What last period?

> Do the clippping occur with oss emulation which use 
> power of 2 period size
> 
> or
> 
> add
> 
> snd_pcm_hw_constraint_integer(runtime,
> SNDRV_PCM_HW_PARAM_PERIODS)

Add that line where? I'm not sure if I'm using oss emulation.
_______________________________________________________________________

Re: Invalid PCM pointer with CMI8738 and pcm.c buffer underuns

[Raymond Yau]

2014-04-05 0:15 GMT+08:00 andoru <andoru.blah@gmail.com>:

> Continued from here:
> http://article.gmane.org/gmane.linux.alsa.devel/121379
>
> After a few days now I finally got VLC to log everything that happens, and
> finally the bug reappeared, and unlike previously thought, it happens when
> I
> watch a video as well.
> But unfortunately VLC didn't give anything specific that happened at the
> time, just some vague ALSA errors about broken pipes (at line 394) :
> http://pastebin.com/NgZiG9yX
>
> At the time I added the video to VLC's queue I was doing something in the
> background (which I don't remember now unfortunately), but this has
> happened
> even when listening to something without doing anything in the background,
> and not having any background-running apps except Transmission.
>
> Also interestingly lately I've heard a few crackles/pops when listening to
> stuff, followed by a second or so of silence then back to normal when I
> would run CPU intensive stuff. At those points I thought the bug would be
> invoked again, but it didn't happen so.
>
> I still have the crackling problem, not able to change the PCM channel
> volume and screeching on audio that has clipped portions or very high
> frequency waves.
>
>
alsa debug: final HW setup:
ACCESS:  RW_INTERLEAVED
FORMAT:  S16_LE
SUBFORMAT:  STD
SAMPLE_BITS: 16
FRAME_BITS: 32
CHANNELS: 2
RATE: 44100
PERIOD_TIME: 40000
PERIOD_SIZE: 1764
PERIOD_BYTES: 7056
PERIODS: (9 10)
BUFFER_TIME: (371519 371520)
BUFFER_SIZE: 16384
BUFFER_BYTES: 65536


does the hardware really support (16384/1764)  9.27 periods ?

does the error occur in the last period ?



> Can anyone give me any instructions on what I could do to further diagnose
> this problem?
> And more importantly, as I stated in the linked post above, how could I
> shut
> down the sound daemon/server/whatever so I could bring back the OS to
> stability without restarting.
>
>
Do the clippping occur with oss emulation which use power of 2 period size

or

add

snd_pcm_hw_constraint_integer(runtime,
                       SNDRV_PCM_HW_PARAM_PERIODS)

Invalid PCM pointer with CMI8738 and pcm.c buffer underuns

[andoru]

Continued from here: http://article.gmane.org/gmane.linux.alsa.devel/121379

After a few days now I finally got VLC to log everything that happens, and
finally the bug reappeared, and unlike previously thought, it happens when I
watch a video as well.
But unfortunately VLC didn't give anything specific that happened at the
time, just some vague ALSA errors about broken pipes (at line 394) : 
http://pastebin.com/NgZiG9yX

At the time I added the video to VLC's queue I was doing something in the
background (which I don't remember now unfortunately), but this has happened
even when listening to something without doing anything in the background,
and not having any background-running apps except Transmission.

Also interestingly lately I've heard a few crackles/pops when listening to
stuff, followed by a second or so of silence then back to normal when I
would run CPU intensive stuff. At those points I thought the bug would be
invoked again, but it didn't happen so.

I still have the crackling problem, not able to change the PCM channel
volume and screeching on audio that has clipped portions or very high
frequency waves.

Can anyone give me any instructions on what I could do to further diagnose
this problem?
And more importantly, as I stated in the linked post above, how could I shut
down the sound daemon/server/whatever so I could bring back the OS to
stability without restarting.

Re: Invalid PCM pointer with CMI8738 and pcm.c buffer underuns

[andoru]

Raymond Yau wrote:
>
> >
> > Andoru wrote:
> > > The last time you replied you said that it's a hardware error. If it
> > > is that way then how come the card otherwise works flawlessly in
> > > Windows, and this doesn't happen on Debian when watching videos or
> > > with certain programs?
>
> The Linux driver seem sharing two Dma channels with at least two playback
> devices and capture device
> 
> The logic seem allow front and rear playing different audio but no capture
> Multi channel playback but no capture
> 
> open three terminals and try different combination of
> 
> speaker-test -c2 -t wav -D front

This gives me: 
___________________________________________________

speaker-test 1.0.27.2

Playback device is front
Stream parameters are 48000Hz, S16_LE, 2 channels
WAV file(s)
ALSA lib confmisc.c:768:(parse_card) cannot find card '1'
ALSA lib conf.c:4248:(_snd_config_evaluate) function snd_func_card_driver
returned error: No such file or directory
ALSA lib confmisc.c:392:(snd_func_concat) error evaluating strings
ALSA lib conf.c:4248:(_snd_config_evaluate) function snd_func_concat
returned error: No such file or directory
ALSA lib confmisc.c:1251:(snd_func_refer) error evaluating name
ALSA lib conf.c:4248:(_snd_config_evaluate) function snd_func_refer returned
error: No such file or directory
ALSA lib conf.c:4727:(snd_config_expand) Evaluate error: No such file or
directory
ALSA lib pcm.c:2239:(snd_pcm_open_noupdate) Unknown PCM front
Playback open error: -2,No such file or directory
____________________________________________________

> speaker-test -c2 -t wav -D rear

This gives me the same as above. (except the playback device is "rear" not
"front", as expected)

> arecord -f dat -D plughw:0,0

This just prints a bunch of random characters continiously unless I quit.

> speaker-test -c4 -t wav -D surround40

Same as the first issued command.

> speaker-test -c6 -t wav -D surround51

As expected... same as above.

Re: Invalid PCM pointer with CMI8738 and pcm.c buffer underuns

[Raymond Yau]

>
> >
> > Andoru wrote:
> > > The last time you replied you said that it's a hardware error. If it
> > > is that way then how come the card otherwise works flawlessly in
> > > Windows, and this doesn't happen on Debian when watching videos or
> > > with certain programs?

The Linux driver seem sharing two Dma channels with at least two playback
devices and capture device

The logic seem allow

front and rear playing different audio but no capture
Multi channel playback but no capture

open three terminals and try different combination of

speaker-test -c2 -t wav -D front

speaker-test -c2 -t wav -D rear

arecord -f dat -D plughw:0,0

speaker-test -c4 -t wav -D surround40

speaker-test -c6 -t wav -D surround51

Re: Invalid PCM pointer with CMI8738 and pcm.c buffer underuns

[andoru]

Clemens Ladisch <clemens <at> ladisch.de> writes:

> 
> Andoru wrote:
> > The last time you replied you said that it's a hardware error. If it
> > is that way then how come the card otherwise works flawlessly in
> > Windows, and this doesn't happen on Debian when watching videos or
> > with certain programs?
> 
> It's still a hardware error, but, apparently, it happens only when the
> Linux driver accesses it in a certain way.
> 
> Which programs work?  Which do not?
> 
> Regards,
> Clemens
> 

Thanks and sorry again for contacting you through your private e-mail, Gmane
wasn't working yesterday.
I thought of letting VLC play along in the background and leave the Messages
window open with verbosity on 2 to see if any error pops up or any clue as
to why this happens. The ironic thing is that I've been listening to music
for about 4 hours and a half and nothing happened, even now it still plays
flawlessly... This is the longest period I've listened to music without
causing VLC to send this PC into error oblivion. I'll post if anything pops out.

Before I continue with the detailed list of programs that work or don't, I
wanted to ask if there's any way to stop the audio server when the PC
becomes unresponsive. So far this is what I've tried while the PC was
struggling to swich to the TTY:

$ alsa force unload

and

$ sudo invoke-rc.d alsa-utils stop

One closes ALSA completely and the other stops some components of ALSA, but
none of those two actually bring the PC/OS back to responsiveness. Nothing
shows up in top that takes that much CPU.

So now onto the list:
- VLC - Audio works fine when watching videos, but as soon as I disable the
video stream (Video -> Video Track -> Disable) same thing happens as when I
try to play audio-only files.
- cmus, moc, Banshee, MPlayer, Rythmbox - same problems as VLC, except cmus,
which instead of flooding the TTY with errors it just displays 3 and exits,
the OS is still unresponsive though.
- any midi interpreter/player - same as the above two
- PCSXR - worked until I changed asound.conf at the suggestions of Raymond
Yau earlier, no audio errors reported in the console before.
- pSX - Reports quite a few buffer underrun errors:
_______________________________________________________
sound: underrun
_______________________________________________________

This occurs 1-2 times every odd second, but I've emulated a game for over 6
hours and nothing bad happened.
But for whatever reason when I tried now to run the emulator it doesn't show
that many of these errors as it used to.
- DosBox - Audio works flawlessly, except midi emulation (see above), MUNT
(below), no errors reported in the terminal. When using any midi interface
this (single) error shows up and renders the OS/PC unresponsive: 
ALSA-lib pcm.c:7843:(snd_pcm_recover), underrun occured
- MUNT (https://github.com/munt/munt) - When using the stand-alone qt
client, I get this error in a dialogue window:
________________________________________________________
snd_pcm_writei failed: Broken pipe
ALSA audio: Processing thread stopped
________________________________________________________

Although admittedly it doesn't end with the OS being unresponsive
thankfully, but it happens exactly after playing 5 secs through a midi.
Now MUNT doesn't work either just like PCSXR

What I haven't tried:
Audio over wine. I don't know how well it works, but I'll try to run
foobar2000 through it to see if it changes anything.


Other stuff that don't work (properly):
- I some apps that use ALSA don't work (as PCSXR that I mentioned above)
- Can't control PCM channel volume
- alsamixer doesn't work except the controls for alsa-equal (see below)
- Screeching and popping when the audio is too loud or has cutoffs
- alsa-equal doesn't work even when properly configured (asound.conf here:
http://pastebin.com/c92CBZfQ and .asoundrc: http://pastebin.com/fmst4sJD)
and similar screeching when explicitly using aplay -D equal and setting some
controls "too high" it through alsamixer -D equal
- can't have more that one sound source (even with dmix set up)

Here's also what VLC outputs when playing a typical mp3 file in case you
need it: http://pastebin.com/gvZ4R4ZP
It shows some ALSA debug info.

Hope I was descriptive enough. Let me know if you need any additional info.

Re: Invalid PCM pointer with CMI8738 and pcm.c buffer underuns

[Clemens Ladisch]

Andoru wrote:
> The last time you replied you said that it's a hardware error. If it
> is that way then how come the card otherwise works flawlessly in
> Windows, and this doesn't happen on Debian when watching videos or
> with certain programs?

It's still a hardware error, but, apparently, it happens only when the
Linux driver accesses it in a certain way.

Which programs work?  Which do not?


Regards,
Clemens