[Asus 1101HA] Choppy sound due to excessive rewinding on Atom chipsets

[simplygades]

Description: Ubuntu oneiric (development branch)
Release: 11.10

pulseaudio:
  Installed: 1:0.99.1-0ubuntu2
  Candidate: 1:0.99.1-0ubuntu2
  Version table:
 *** 1:0.99.1-0ubuntu2 0
        500 http://gr.archive.ubuntu.com/ubuntu/ oneiric/main i386 Packages
        100 /var/lib/dpkg/status

Expected behaviour: Play music and sounds without gaps.

What happened: Every system sound or music through any media player follows a pattern of 2 seconds of silence followed by 1 second of sound. This happened only after I updated today.

[David Henningsson (diwic)]

Hi Simply Gades and thanks for testing the new PulseAudio version!

Seems you get stuck in eternal rewinding, which is one of the bugs I've trying to work with this cycle. Unfortunately, it's quite hard to fix it.

Do you still get the same breakups if you're using any of these commands to play back sound?

speaker-test -D pulse -t sine -c 2

paplay <name of media file>

Also, do you have a low-end CPU (e g Atom based)?

[simplygades (simplygades-deactivatedaccount)]

Hi David!

:~$ speaker-test -D pulse -t sine -c 2

speaker-test 1.0.24.2

Playback device is pulse
Stream parameters are 48000Hz, S16_LE, 2 channels
Sine wave rate is 440.0000Hz
ALSA lib dlmisc.c:254:(snd1_dlobj_cache_get) Cannot open shared library /usr/lib/i386-linux-gnu/alsa-lib/libasound_module_pcm_pulse.so
Playback open error: -6,No such device or address

[simplygades (simplygades-deactivatedaccount)]

Sorry, I accidentally posted it incomplete, so:

:~$paplay /home/~/Music/Nightwish/Dark\ Passion\ Play/03_-_Amaranth.mp3
Failed to open audio file.

My PC is an Intel Atom-Z520 based Acer. Now updating, and I'll check again. Contact me in case you need any further info, bye!

[David Henningsson (diwic)]

paplay cannot open mp3 files, but you could e g try

paplay /usr/share/sounds/ubuntu/stereo/desktop-login.ogg

As for the speaker-test (or rather alsa-plugins) problem, that sounds strange, but I know there has been some multiarch updates to that package lately. Maybe an update will help?

As for the root cause, if paplay succeeds, chances are that you are helped by a patch I made this morning. I *think* Dolphin/phonon uses gstreamer internally, but not completely sure.

Thanks for helping out!

[simplygades (simplygades-deactivatedaccount)]

OK, I'm using Kubuntu right now with latest updates (inc. PA). The result of "paplay" is the same "skipping rewind" behaviour.

[David Henningsson (diwic)]

Okay, then I don't have any good ideas at the moment. Probably need to have a very low-end machine in order to dig deep enough into the problem.

[simplygades (simplygades-deactivatedaccount)]

Shouldn't the cause be found among the changes from the changes from the last working version to the first buggy one? In case you have a clue and want some testing, tell me, ciao!

[Lucazade (lucazade)]

same issue here with acer751h

[Lucazade (lucazade)]

Can say that I never had any audio issue on this netbook from Hardy Heron 8.04.
Quite sad to have this now, we already have a lot of issue with gfx drivers!

[simplygades (simplygades-deactivatedaccount)]

I dare say that this one is going to be there on the final release...Sad,, cause its a major issue. I'm really curious if that affects other Atom users. Kubuntu and removal of PA will be my last shelter, given the GPU situation.

[Li Li (lli5)]

My Toshiba N205 works fine when CPU% doesn't reach ~100%. But when CPU is busy (e.g. during chatting with IM SW, the sound sometimes become choppy. The speaker-test works fine also.

[Li Li (lli5)]

lli5@netbook:~/Ubuntu One$ cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 28
model name : Intel(R) Atom(TM) CPU N280 @ 1.66GHz
stepping : 2
cpu MHz : 1000.000
cache size : 512 KB
physical id : 0
siblings : 2
core id : 0
cpu cores : 1
apicid : 0
initial apicid : 0
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 10
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx constant_tsc arch_perfmon pebs bts aperfmperf pni dtes64 monitor ds_cpl est tm2 ssse3 xtpr pdcm movbe lahf_lm dts
bogomips : 3325.14
clflush size : 64
cache_alignment : 64
address sizes : 32 bits physical, 32 bits virtual
power management:

processor : 1
vendor_id : GenuineIntel
cpu family : 6
model : 28
model name : Intel(R) Atom(TM) CPU N280 @ 1.66GHz
stepping : 2
cpu MHz : 1000.000
cache size : 512 KB
physical id : 0
siblings : 2
core id : 0
cpu cores : 1
apicid : 1
initial apicid : 1
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 10
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx constant_tsc arch_perfmon pebs bts aperfmperf pni dtes64 monitor ds_cpl est tm2 ssse3 xtpr pdcm movbe lahf_lm dts
bogomips : 3323.40
clflush size : 64
cache_alignment : 64
address sizes : 32 bits physical, 32 bits virtual
power management:

[Keng-Yu Lin (lexical)]

just for comparison, I tested on Dell Latitude 2110 with Atom N470 CPU, I do not observe the same issue with PulseAudio 0.99.3-0ubuntu5.

[Li Li (lli5)]

Update: If CPU% is too high, sounds become choppy and won't recover until the application close and reopen (therefore the audio device is re-inited).

[Li Li (lli5)]

More:

If CPU% is too high AND AUDIO BUFFER TOO SHORT (say 10ms e.g.), sounds become choppy. If the buffer isn't too short, audio playback is still fine even if I run another application to consume all available CPU resource.

PS: I've upgraded to the latest Oneiric, with pulseaudio version 1:0.99.3-0ubuntu5.

[simplygades (simplygades-deactivatedaccount)]

I reinstalled PA on Kubuntu 11.10, seems fixed here with the latest version!

[simplygades (simplygades-deactivatedaccount)]

UPDATE: No it's still acting like that. I'll try to test on a clean installation and report.

[David Henningsson (diwic)]

A few Atom users have complained about enternal rewinds since they
upgraded to 0.99.x, see
https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/825709

So here's just an idea. As a "last resort", ratelimit the number of
rewinds. If there are more than 10 rewinds in 200 ms, go to sleep for
200 ms. The idea is that during those 200 ms, the client application
will produce enough packets to fill up the buffer enough. Those packets
will then be merged into one, due to an earlier rewind patch that is
already in. The 200 ms sleep might cause a noticable glitch, but
hopefully we get that one glitch only instead of complete brokenness.

But I don't have any such setup here currently, so maybe any of you
could check this patch and see if it works as intended, and has real effect?

--
David Henningsson, Canonical Ltd.
http://launchpad.net/~diwic

[Ubuntu Foundations Team Bug Bot (crichton)]

The attachment "0001-Ratelimit-rewinds-of-sinks.patch" of this bug report has been identified as being a patch. The ubuntu-reviewers team has been subscribed to the bug report so that they can review the patch. In the event that this is in fact not a patch you can resolve this situation by removing the tag 'patch' from the bug report and editing the attachment so that it is not flagged as a patch. Additionally, if you are member of the ubuntu-sponsors please also unsubscribe the team from this bug report.

[This is an automated message performed by a Launchpad user owned by Brian Murray. Please contact him regarding any issues with the action taken in this bug report.]

[Lucazade (lucazade)]

@David
I can try it out on atom..
is there a fast way to compile pulseaudio from source?
is this good?

apt-get source pulseaudio
sudo apt-get build-dep pulseaudio
cat ../0001-Ratelimit-rewinds-of-sinks.patch | patch -p1
.configure && make && sudo make install

[Lucazade (lucazade)]

no luck.. patch doesn't help, it is still choppy.
is there any pulseaudio log to check rewinds?

[David Henningsson (diwic)]

On 09/19/2011 07:14 PM, Tanu Kaskinen wrote:
> On Mon, 2011-09-19 at 17:49 +0200, David Henningsson wrote:
>> + if (!pa_ratelimit_test(&s->thread_info.rewind_limit, PA_LOG_DEBUG)) {
>> + pa_log_warn("Okay, I'm sick and tired of all this rewinding. I'm going to sleep for %lu ms!",
>> + s->thread_info.rewind_limit.interval / PA_USEC_PER_MSEC);
>> + usleep(s->thread_info.rewind_limit.interval);
>> + pa_log_debug("Waking up.");
>> + }
>
> The patch seems otherwise ok to me, but I'd prefer the log prints to
> include the sink name. When a system has e.g. 6 sinks, all of which may
> be in active use at the same time, I really don't like the sink.c
> messages that don't tell which sink is in question... Also, instead of
> just "waking up", maybe it would be useful to have "waking up; not so
> sick and tired anymore" or something else that clearly connects the
> wakeup message to the preceding warning.
>

Sure. I don't mind changing the log messages. (As for sink names, I
think there was a plan to add that to the thread name in the log?)
I'm more concerned about what happens if we wake up and that sleep has
caused an underrun on the ALSA level, what that will do to the
watermark, etc.

--
David Henningsson, Canonical Ltd.
http://launchpad.net/~diwic

[David Henningsson (diwic)]

@Lucazade, Either use debian packages, something like:

apt-get source pulseaudio
cd <pulseaudio dir>
quilt push -a
quilt import <patch name>
quilt push
dch -i
dpkg-buildpackage -b
sudo dpkg -i <debian packages>

or use upstream stuff:

http://colin.guthr.ie/2010/09/compiling-and-running-pulseaudio-from-git/

Could you send a PulseAudio log with the patch applied (see http://wiki.ubuntu.com/PulseAudio/Log if you run the debian package)? Would be interesting to see if the sleep actually triggers or not.

[Lu Guanqun (guanqun-lu)]

On Mon, Sep 19, 2011 at 11:49:03PM +0800, David Henningsson wrote:
> A few Atom users have complained about enternal rewinds since they
> upgraded to 0.99.x, see
> https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/825709
>
> So here's just an idea. As a "last resort", ratelimit the number of
> rewinds. If there are more than 10 rewinds in 200 ms, go to sleep for
> 200 ms. The idea is that during those 200 ms, the client application
> will produce enough packets to fill up the buffer enough. Those packets
> will then be merged into one, due to an earlier rewind patch that is
> already in. The 200 ms sleep might cause a noticable glitch, but
> hopefully we get that one glitch only instead of complete brokenness.
>
> But I don't have any such setup here currently, so maybe any of you
> could check this patch and see if it works as intended, and has real effect?

Hi David,

Thanks for the patch, rate limiting the rewinding seems a good idea,
however, I don't have Atom machine right on my hand. I met the flood of
rewinds before, but that was later root caused to the wrong report of
timing info from underlying device. After this was fixed, no flood of
rewinds were seen.

--
guanqun

[David Henningsson (diwic)]

On 09/20/2011 10:21 AM, Lu Guanqun wrote:
> On Mon, Sep 19, 2011 at 11:49:03PM +0800, David Henningsson wrote:
>> A few Atom users have complained about enternal rewinds since they
>> upgraded to 0.99.x, see
>> https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/825709
>>
>> So here's just an idea. As a "last resort", ratelimit the number of
>> rewinds. If there are more than 10 rewinds in 200 ms, go to sleep for
>> 200 ms. The idea is that during those 200 ms, the client application
>> will produce enough packets to fill up the buffer enough. Those packets
>> will then be merged into one, due to an earlier rewind patch that is
>> already in. The 200 ms sleep might cause a noticable glitch, but
>> hopefully we get that one glitch only instead of complete brokenness.
>>
>> But I don't have any such setup here currently, so maybe any of you
>> could check this patch and see if it works as intended, and has real effect?
>
> Hi David,
>
> Thanks for the patch, rate limiting the rewinding seems a good idea,
> however, I don't have Atom machine right on my hand. I met the flood of
> rewinds before, but that was later root caused to the wrong report of
> timing info from underlying device. After this was fixed, no flood of
> rewinds were seen.
>

Hi Lu,

This is interesting. If there was something in the kernel that makes
Atom HDA controllers (?) report the wrong timing info, and this was
later fixed, could you point me to that patch?

Thanks in advance!

--
David Henningsson, Canonical Ltd.
http://launchpad.net/~diwic

[Lucazade (lucazade)]

@David
repackaged using quilt and your guide but unfortunately didn't help.
this is the log with the patch applied

[Arun Raghavan (arunraghavan)]

Adding a testing data point. I've run PA 0.99.4 (on Debian, not Ubuntu) on an Acer Aspire One 722, which has a dual-core (but I disabled 1 core for testing) AMD C-50 processor running at 1 GHz (http://en.wikipedia.org/wiki/AMD_mobile_platform#Brazos_.28Fusion.29_platform_.282011.29). The HDA codec on this is a Conexant CX20588.

The audio is smooth in Rhythmbox and Totem (except if I play something reasonably stressful like 720p or 1080p video). It's using gst-plugins-good 0.10.30, and with 720p/1080p video, I do see the rewind madness and messed up sound. It continues to happen when I switch to a less stressful video, and fixes itself if I pause for long enough for the sink to suspend.

[Lucazade (lucazade)]

any news on this? was the log useful?

[David Henningsson (diwic)]

@Lucazade, thanks for the log. It shows that my attempt to solve the problem was not the right one, as the sleep code was called but it did not help. So back to the drawing board, basically.

Arun seems to have replicated the issue on his side, and he's a PulseAudio developer, so I hope he (and I - to the amount I can be of help) can help to resolve the issue.

@Arun, do you know if/when you'll have time to look into this in more depth?

[Arun Raghavan (arunraghavan)]

Sorrt if I was unclear in my previous comment -- I can't actually see this problem unless I'm seriously stressing out the CPU at the same time as playing audio (which it appears to me is not the situation in the original report). It would be great to be able to find a way to isolate whether this problem is actually a regression in 0.99.4 (that is, does it work with 0.9.23).

[Arun Raghavan (arunraghavan)]

There is a small possibility that his patch might help. Would be nice if someone could try since I haven't really been able to see the problem.

http://cgit.freedesktop.org/pulseaudio/pulseaudio/commit/?id=6a9272f9506

[simplygades (simplygades-deactivatedaccount)]

I would happily test it, however I don't know the way. Am I supposed to apply the patch via bzr as mentioned in the Ubuntu wiki? Sorry but I'm a bit inexperienced in this, if you have the time to provide a link, or tell e what to do I can test it. Thanks!

[Lucazade (lucazade)]

unfortunately latest patch didn't help, still choppy behavior.
attached pulse audio log.

[Lucazade (lucazade)]

after trying the latest patch I've updated the system (dist-upgrade) and get a new kernel (3.0.0-12) and other packages.
after a reboot no soundcard were present in audio capplet and indicator-sound was muted because no device present.. i was reading in the forum yesterday this issue was present also for other users. (funny thing is alsamixer shows my hda intel sound card).

Tried then to play an .mp3 and it was working good.. unfortunately pulseaudio was not working...
so i tried to restart pulseaudio using the wiki log instructions and mp3 is still playing good, incredible.. attached the new log
(sincerly I don't know if pulseaudio is really employed in this test.. hope i've explained it well with my poor english!)

[Lucazade (lucazade)]

found a workaround in the meanwhile

applied workarounds found in arch wiki pulse audio and everything is working now
- Glitches, skips or crackling
- Choppy sound

https://wiki.archlinux.org/index.php/PulseAudio#Glitches.2C_skips_or_crackling

Hope this is useful to find a proper fix

[Arun Raghavan (arunraghavan)]

Could you remove the Choppy Sounds "fix" (that is go back to the default sample rate of 44.1 kHz), and see if the problem remains fixed or comes back?

[Lucazade (lucazade)]

tested and the choppy sound fix is not needed.

[Singpolyma (singpolyma)]

Just to say, I have an eeePC 1101HA 1.33Ghz Atom processor and was having the same issue. https://wiki.archlinux.org/index.php/PulseAudio#Glitches.2C_skips_or_crackling fixed it

[David Henningsson (diwic)]

Hi, is any of you able to replicate the eternal rewind errors with a special version of PulseAudio, the one in ppa:diwic/fighting-rewinds (for oneiric), and if so, give me some logs according to https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/872320/comments/5 ? Thanks in advance!

[Stefano Lodi (stefano-lodi)]

On my Asus eeePC 1101HA, Atom Z520@1.33GHz, Ubuntu 11.10, kernel 3.0.0.12-generic, there are consistent skips as described in previous posts. I'll try the special PulseAudio as soon as possible.

[Jan (jankanis)]

I have the same problem on an Asus eeePC 1101HA, Ubuntu Oneric, kernel 3.0.0-12.20. The 'speaker-test' test plays without stuttering, paplay stutters. However, this problem also occurs if the processor isn't loaded, just running the music player at around 10% cpu.

I tried the archwiki solution, that solved it.
I undid that and installed the fighting-rewinds ppa build. The problem persists. Attached are the logs.

When opening firefox to post this comment, it turned out a flash video played smoothly, probably because it was not using pulseaudio now.

[Jan (jankanis)]

and the gst log

[Stefano Lodi (stefano-lodi)]

I cannot reproduce the previous behaviour with the special pulseaudio version. It works better than the one from the distribution (tested with banshee, vlc and youtube). Skips are hardly noticeable and not frequent.

However, when I played a mp3 file with vlc I heard a crackling sound for several seconds at the beginning. I attach the log.

[Stefano Lodi (stefano-lodi)]

I realized I did not start banshee as recommended (and I have not uploaded the 2nd log).

I upgraded pulseaudio from ppa:diwic/fighting-rewinds, then I performed the test again, this time following the instructions.
During the test, the sound was indeed broken as expected, with long pauses between short fragments correctly played.

I attach both logs.

[Stefano Lodi (stefano-lodi)]

Here is the 2nd log (Banshee).

The total playing time is about 3 minutes.

[David Henningsson (diwic)]

@Stefano, many thanks!

From the pulseverbose log it seems like there is a driver problem of not reporting the hw position correctly.

( 135.836| 0.000) D: [alsa-sink] alsa-sink.c: avail: 336892 (filled: 15876)
( 135.836| 0.000) D: [alsa-sink] alsa-sink.c: 90.00 ms left to play; inc threshold = 0.00 ms; dec threshold = 100.00 ms
( 135.836| 0.000) D: [alsa-sink] alsa-sink.c: work_done = 0
( 135.836| 0.000) D: [alsa-sink] alsa-sink.c: Waking up in 60.00ms (system clock).
( 135.896| 0.060) D: [alsa-sink] alsa-sink.c: avail: 336892 (filled: 15876)
( 135.896| 0.000) D: [alsa-sink] alsa-sink.c: 90.00 ms left to play; inc threshold = 0.00 ms; dec threshold = 100.00 ms
( 135.896| 0.000) D: [alsa-sink] alsa-sink.c: work_done = 0
( 135.896| 0.000) D: [alsa-sink] alsa-sink.c: Waking up in 60.00ms (system clock).

Notice there are 60 ms between the first and second check of "avail", yet "avail" is not increasing (which it should be doing, if the audio was playing back). Then, suddenly:

( 136.170| 0.060) D: [alsa-sink] alsa-sink.c: avail: 336892 (filled: 15876)
( 136.170| 0.000) D: [alsa-sink] alsa-sink.c: 90.00 ms left to play; inc threshold = 0.00 ms; dec threshold = 100.00 ms
( 136.170| 0.000) D: [alsa-sink] alsa-sink.c: work_done = 0
( 136.171| 0.000) D: [alsa-sink] alsa-sink.c: Waking up in 60.00ms (system clock).
( 136.231| 0.060) D: [alsa-sink] alsa-sink.c: avail: 689660 (filled: 4294630404)
( 136.231| 0.000) D: [alsa-sink] alsa-sink.c: 0.00 ms left to play; inc threshold = 0.00 ms; dec threshold = 100.00 ms

And then, two seconds later (with a latency of ~100 ms!), the underrun is a fact.

[David Henningsson (diwic)]

So, can you try two different methods of position reporting?
Edit /etc/modprobe.d/alsa-base.conf and add the following line:

options snd-hda-intel position_fix=1

Reboot your computer and see if it works better, and also try this version:

options snd-hda-intel position_fix=2

Reboot and retry.
Thanks!

[David Henningsson (diwic)]

I also noticed that you might have had a volume control opened when you tested? If so, make sure to repeat the test case with the same conditions with the new position_fix versions. Thanks!

[Stefano Lodi (stefano-lodi)]

Ok, I'll try first with a volume control open and then closed, as I do not remember whether it was open or not.

I see there is an update (1:1.0-0ubuntu3+bufferingtest --> 1:1.0-0ubuntu3.1), however the changelog does not mention the bug of this thread. Should I perform the tests with the installed version 1:1.0-0ubuntu3+bufferingtest or the new version 1:1.0-0ubuntu3.1?

[Stefano Lodi (stefano-lodi)]

I guess not with 1:1.0-0ubuntu3.1 if I have to record logs as that version is listed in the official repositories.

[David Henningsson (diwic)]

> Should I perform the tests with the installed version 1:1.0-0ubuntu3+bufferingtest or the new version 1:1.0-0ubuntu3.1?

Please use the 1:1.0-0ubuntu3+bufferingtest version. Thanks!

[Stefano Lodi (stefano-lodi)]

1st test: With
- options snd-hda-intel position_fix=1 in /etc/modprobe.d/alsa-base.conf
- autospawn = no in ~/.pulse/client.conf
result: fine sound until about 1'30 from start, then a few jumps ahead; finally the sound became distorted until the end of the test (about 3').

I kept a volume control window opened during the test.

[Stefano Lodi (stefano-lodi)]

Here's the other log (Banshee).

[Stefano Lodi (stefano-lodi)]

2nd test: With
- options snd-hda-intel position_fix=2 in /etc/modprobe.d/alsa-base.conf
- autospawn = no in ~/.pulse/client.conf
result: choppy sound, just as in my initial test (that is without the position fix).

I kept a volume control window open during the test.

[Stefano Lodi (stefano-lodi)]

Here's the log of Banshee.

[David Henningsson (diwic)]

Thanks. So the most disturbing in the first log is:

( 262.115| 0.000) D: [alsa-sink] alsa-sink.c: Waking up in 43.01ms (system clock).
( 270.521| 8.405) E: [alsa-sink] alsa-util.c: snd_pcm_avail() returned a value that is exceptionally large: 1822684 bytes (10332 ms).

This was probably where it started to be completely broken.

So - what happened during this 8 seconds, that was running at a higher priority than PulseAudio? PulseAudio should have woken up in 43 ms, but it was 8 seconds until it actually woke up - and then PulseAudio is quite bad at recovering from that situation unfortunately.
Did you notice any sudden 8 second hang of your computer?

[Stefano Lodi (stefano-lodi)]

No, I do not remember noticing a hang. But I might have moved the Sound preferences volume slider when or before the sound became corrupted. That is the control I used in the last tests.

I have just repeated the test with position_fix=1. The sound distortion I mentioned in the previous test did not occur. But I have heard several jumps (I mean like edit cuts, not seconds of silence).

Since you mentioned priority problems, I opened the System Monitor during today's test. During playback, CPU load is abut 65-70% for both cores. However, when the volume control is being moved, it jumps to 100% and stays there until I stop moving it. Same behavior when I opened Applications and moved the mouse in it.

I hope I am not going outside of scope---but since I upgraded to 11.10 the Application submenus have been consistently unresponsive for seconds. For example, the Office submenu is displayed instantly, but the selection in it is invisible for a few seconds---moving the mouse does nothing and the CPU load is about 100%, dropping when the selection appears again (pulseaudio not running). However, repeating the test, and keeping moving the mouse inside the submenu for many seconds, the interface become unresponsive and CPU load went to 100% and remained there even long after I exited the area of the submenu---but the sound was not affected.

If you like I can attach the logs.

[Stefano Lodi (stefano-lodi)]

Note that I have not updated my system, currently there are almost 150 updates involving GNOME and Banshee. My system is exactly as it was when I attached the first logs here.

[David Henningsson (diwic)]

Thanks for your continued investigation. I'm wondering what to do next. I could submit an LPIB quirk for your particular machine (for that I'll need an alsa-info, see http://wiki.ubuntu.com/Audio/AlsaInfo ), which would mean that in the next version of Ubuntu, position_fix=1 would be the default.

But if that causes higher CPU usage, I'm unsure if that's the right way to go? Or was the high CPU usage (which was attributed to PulseAudio, or something completely different?) independent of position_fix=1 or position_fix=2 ?

[Stefano Lodi (stefano-lodi)]

The high cpu usage is independent of position_fix=1. It looks like a problem related to the interface, which for some reason is slow in handling mouse events in submenus of Applications and in the Places menu, to some extent also in file context menus and in Nautilus menus.

On the other hand I am experiencing too much randomness for reliable testing, because at random banshee does not handle well changes in its window. Examples:
- if I resize the lower right view (Name Artist etc.)
  - it randomly locks X (cpu at 100%)
  - the sound is corrupted, until playback is stopped and restarted (this case occured with pulseaudio running)
- on startup while recording the log as recommended
  - refuses to show the contents of its window (cpu at 95% in the Resources window)
  - shows the window and then crashes with a GLib-CRITICAL failed assertion

I wonder if it would not be safer to update all the packages except pulseaudio and see if independent problems have been solved.

To summarize the current state

- no pulseaudio: OK
- pulseaudio & no fix: choppy sound, but not always
- pulseaudio & position_fix=1: OK, sound silenced for one second or less if one rearranges windows etc.

Surely, position_fix=1 is a substantial improvement. But as I said I would be very interested in continuing to test it with updated packages.

[David Henningsson (diwic)]

Could you please submit an alsa-info, see http://wiki.ubuntu.com/Audio/AlsaInfo ?

Also, banshee uses gstreamer internally, so maybe another player (i e Rhythmbox) would still show the bugs, although with less randomness? Or even a raw gstreamer pipeline (the example is for an ogg file):

gst-launch filesrc location=music.ogg ! oggdemux ! vorbisdec ! audioconvert ! audioresample ! pulsesink

[Stefano Lodi (stefano-lodi)]

I attach the output of alsa-info.

I'm trying the methods you suggested in a minute.

BTW yesterday I logged pulseaudio using vlc. No choppy sound, however after a random number of minutes (at most 30) the audio output is trapped into an infinite loop a few seconds long, and finally stops completely after say 100 repetitions. If you think it's worth I can attach the logs (compressed). The cpu usage was quite modest.

[Stefano Lodi (stefano-lodi)]

I attach two logs obtained using vlc and position_fix=1. The audio output suddenly stopped in both cases.

In the meantime I am continuing the tests using rhythmbox.

[Stefano Lodi (stefano-lodi)]

Rhythmbox tests: I can still hear the loops I mentioned two posts ago, however in almost all cases there is a recovery after a few loops, that is, rhythmbox jumps ahead and proceeds normally. Gstreamer pipeline still to test.

[David Henningsson (diwic)]

Ok, so I'll send a patch for the LPIB quirk for Stefano Lodi's device. If anybody else with an atom-based box, who can confirm that position_fix=1 works for them, could you file a new bug against the alsa-driver package (this will gather the relevant hw info) and point me to it by posting a comment in this bug? Thanks!

[David Henningsson (diwic)]

For the Asus 1101HA, reporting position by reading the DMA position
buffer map seems unstable and often wrong. The reporter says that
position_fix=LPIB works much better (although not 100%, but this is
probably due to other issues).

The controller chip is an Intel Poulsbo 8086:811b (rev 07) controller,
and complete alsa-info is available here:
https://launchpadlibrarian.net/86691768/alsa-info.txt.1TNwyE5Ea7

Cc: <email address hidden> (3.0+)
BugLink: http://bugs.launchpad.net/bugs/825709
Tested-by: Stefano Lodi
Signed-off-by: David Henningsson <email address hidden>
---
 sound/pci/hda/hda_intel.c | 1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c
index d1582dd..0746ab4 100644
--- a/sound/pci/hda/hda_intel.c
+++ b/sound/pci/hda/hda_intel.c
@@ -2506,6 +2506,7 @@ static struct snd_pci_quirk position_fix_list[] __devinitdata = {
  SND_PCI_QUIRK(0x1043, 0x813d, "ASUS P5AD2", POS_FIX_LPIB),
  SND_PCI_QUIRK(0x1043, 0x81b3, "ASUS", POS_FIX_LPIB),
  SND_PCI_QUIRK(0x1043, 0x81e7, "ASUS M2V", POS_FIX_LPIB),
+ SND_PCI_QUIRK(0x1043, 0x83ce, "ASUS 1101HA", POS_FIX_LPIB),
  SND_PCI_QUIRK(0x104d, 0x9069, "Sony VPCS11V9E", POS_FIX_LPIB),
  SND_PCI_QUIRK(0x1297, 0x3166, "Shuttle", POS_FIX_LPIB),
  SND_PCI_QUIRK(0x1458, 0xa022, "ga-ma770-ud3", POS_FIX_LPIB),
--
1.7.5.4

[David Henningsson (diwic)]

Upstream accepted patch.

[David Ayers (ayers)]

Setting:

/etc/modprobe.d/alsa-base.conf
options snd-hda-intel position_fix=1

as per comment #48 fixes the same issue for my on a Dell mini 12
00:1b.0 Audio device: Intel Corporation System Controller Hub (SCH Poulsbo) HD Audio Controller (rev 07)

[David Henningsson (diwic)]

Thanks David Ayers, can you also send me your alsa-info so I can send a quirk upstream? See https://wiki.ubuntu.com/Audio/AlsaInfo

[David Ayers (ayers)]

Sure! I've let the script upload it to:
http://www.alsa-project.org/db/?f=b7421521b8d8a4db3842ee14cdb54b4f440cae5e

[David Henningsson (diwic)]

Upstream has now agreed to move all of Poulsbo to LPIB (i e position_fix=1), which I believe is the right thing to do. This will be in the development release shortly. Thanks for all the testing everybody!

http://git.kernel.org/?p=linux/kernel/git/tiwai/sound.git;a=commit;h=645e903528ca6cd510f9ac71a6a23de1a4d931e3

[Lucazade (lucazade)]

Thanks guys for the hard work, really appreciated!

[Stefano Lodi (stefano-lodi)]

David, in the meantime is the recommended version of pulseaudio the one you released in this thread for testing?

Stefano

[David Henningsson (diwic)]

The recommended version to use is the officially released version of PulseAudio, together with the position_fix=1 workaround.

[Stefano Lodi (stefano-lodi)]

Upgraded to 12.04. The position_fix=1 workaround must still be in alsa-base.conf, right?

Using totem, audio output loops a large number of times, then recovers. The initial bug (seconds of silence) does not occur.

Stefano

[Stefano Lodi (stefano-lodi)]

That happens with the workaround. I am testing without it.