Hi Takashi,
On Wed, Sep 21, 2011 at 04:43:15PM +0200, Takashi Iwai wrote:
At Wed, 21 Sep 2011 10:35:10 -0400, Forest Bond wrote:
Hi Takashi,
On Wed, Sep 21, 2011 at 10:39:44AM +0200, Takashi Iwai wrote:
At Tue, 20 Sep 2011 15:05:34 -0400, Forest Bond wrote:
On Tue, Sep 20, 2011 at 09:22:23AM +0200, Takashi Iwai wrote:
At Mon, 19 Sep 2011 19:14:13 -0400, Forest Bond wrote:
On Fri, Sep 16, 2011 at 04:36:01PM -0400, Forest Bond wrote: > I have two boards with a VT1708: > > * VIA EPIA EX15000G > * VIA VB8002 > > I'm using VLC to play audio via PulseAudio to the analog outputs. The VB8002 > sounds great, but the EX15000G has random pops and clicks in the output. Both > machines are running exactly the same configuration (they are using the same > pre-built OS image).
Maybe this issue would be more approachable if I could produce it without PulseAudio involved?
Yes.
Heh, I guess I'm probably not going to be able to do that very easily.
Incidentally, these boards both produce a crackling/static sound when PulseAudio is playing and the PCM mixer is turned all the way down. I have seen scattered reports of this in various bug trackers. The problem does not occur when playing via alsa directly. One thing I have noticed is that the crackling noise follows the rhythm of the music being played. It actually sounds like the music has been heavily distorted (i.e. via extreme digital clipping) and then attenuated significantly.
It seems likely that there are driver issues that PulseAudio is exposing. What can I do to track them down?
Is the problem related with the driver version? You mentioned the difference of drivers installed on your systems. If it's a regression of the driver, it'd be easier to figure out.
No, the issue occurs with both driver versions.
Other than that, I'd try to adjust PA, e.g. try tsched=0. Usually this kind of problem is because of inaccurate playback position reporting from the hardware. PA relies (too much) on the playback position as default.
Using tsched=0 fixes the pops and clicks on the EX15000G. Any idea why I might see problems on one board but not the other given how similar they are?
Do they have the same HD-audio controller chip (VIA one)? Usually it's an issue of controller chip, not codec chips, so I wonder if they behave differently even with a same controller.
I'm not really sure how to identify the controller chip. alsa-info.sh output is here:
EX15000G: http://www.alsa-project.org/db/?f=ea56226a7917391d6adf9078650d3a9395f51b17
VB8002: http://www.alsa-project.org/db/?f=611cc772a3fab7552bbda193b6ad7998f66a60fb
As I understand it the VT1708 is the codec chip. Is the audio controller part of the south bridge? Both report having a VT8237.
Yes, and it's VT1708 also meaning a controller chip, apparently. The controller chip is what PCI ID shows.
The crackling with PCM volume set to 0 persists with tsched=0.
Hrm, which PA version are you using? I remember vaguely a buggy PA SIMD operations in some old PA versions.
1:0.9.22+stable-queue-24-g67d18-0ubuntu3 from Ubuntu Lucid.
Also, when you mute the mixer (nor the PA's mixer), e.g. via "alsamixer -c0", the noise goes away, right?
I do not use the PA mixer. The noise is present with ALSA's PCM control set to zero (-51dB). If I move the PCM control up one tick (to -50.8dB) the noise goes away.
OK, then it's an issue in the sound driver. Could you give alsa-info.sh outputs both mute-with-noise and without noise for comparison?
With noise:
http://www.alsa-project.org/db/?f=c8119c27951479731f1ba6d8ea62cd3ad91aec1a
Without noise:
http://www.alsa-project.org/db/?f=f40d02f0286a64946bec2ff4243c15ea86e5ea59
It seems unlikely that this isn't driver or hardware issue. But fixing the pops and clicks without using tsched=0 is more important to me. If you can provide suggestions as to where I might start looking, I would be happy to try and come up with a fix.
As mentioned, the usual problem is the inaccurate DMA position reporting, especially when tsched=0 helped. It means a problem of HD-audio controller. We have already many workarounds in the driver code, but more investigations are needed in such a case...
Again, I'm happy to spend the time needed to get this fixed. If you can provide hints on where to look, that would be great. Can you point me at some git commits that fixed similar issues? I checked the git log but did not find any such commits that changed patch_via.c.
Well, there are a few possible causes. If it's something wrong in the codec side, it can be a PM code. The latest driver has a mixer enum "Dynamic Power-Control". Try to disable it.
Okay, I'll give this a try.
OTOH, if it's in the controller side, where you need to take a look at is hda_intel.c, or sometimes hda_codec.c.
Thanks for the info.
-Forest