I haven't seen anyone with similar problem, and you seem happy, so I'm closing
the bug. If installing a later kernel works, we can assume it is fixed in
Maverick, so marking as fix released.
Thanks for the cooperation, at least I learned something in the process :-)
** Changed in: linux
Ok, after some few hours more of listening, I can report that, if not
fixed, the problem is diminished by several orders of magnitude at
least.
For clarity, the fix is to install the 2.6.34-lucid kernel from the
kernel-ppa's.
I could mark this as solved but I don't know if that's appropriate.
Some new, and I think good, news!
Bug #427439 morphs at end into someone having a problem with noise
floor calibration timeout messages. He repairs this problem by trying
a new kernel, located at http://kernel.ubuntu.com/~kernel-
ppa/mainline/v2.6.34-lucid/
Well now that I am an expert :-) in
** Tags added: kj-triage
--
Wireless blocks USB-Audio, leading to dropouts
https://bugs.launchpad.net/bugs/579117
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
I see in reading your response I have mislead you slightly - the Kubuntu
test DID SHOW noise floor calibration timeouts; just no (apparent)
disturbance of alsa / pulse.
I do not see a linux-preempt in lucid synaptic... I changed to the main
server in case there was something weird there... but no
Linux-preempt should be in the main repositories, and I have it here.
Never tried it though. The rt kernel is not officially supported by the
kernel team and is known to be unstable on some machines.
--
Wireless blocks USB-Audio, leading to dropouts
https://bugs.launchpad.net/bugs/579117
You
hmm. maybe it's only an amd64 kernel? That's what I see at
http://packages.ubuntu.com/hu/lucid/linux-image-preempt
In any case, when I try apt-get here are the results:
c...@temuko:~$ sudo apt-get install linux-preempt
[sudo] password for clh:
Reading package lists... Done
Building
Sorry, but one other thought / question.
Since I'm getting an underrun, doesn't that kind of imply that my client
is not able to reliably fill pulseaudio's buffers? Maybe I should run
the client at a higher priority?
--
Wireless blocks USB-Audio, leading to dropouts
Guess you're right, for some (to me unknown) reason linux-preempt is not
built for i386...
As for the underrun question: if you get alsa-sink.c: Underrun!, that's the
alsa driver telling PA it didn't get any buffers from PA in time.
If you get something like protocol-native.c: Underrun on
Well, renice-ing rhythmbox down to -9 did not seem to help. I got
stuttering every two-three minutes. Besides the ath5k noise floor
calibration message, the only message I received during the test was
Jul 4 15:37:15 temuko pulseaudio[1273]: ratelimit.c: 848 events
suppressed
I don't always
Today's experiment - try it with Kubuntu.
I still get noise floor calibration timeout messages.
However, I have listened to 10 songs or so now and no skipping. Also no
alsa messages in the log.
Watching latencytop run, I still see the big latencies for Scheduler:
waiting for cpu from time to
I'm still watching, but I lack both time and ideas. Kubuntu 10.04 does not run
pulseaudio so that could be the reason for differences in behavior. (Kubuntu
10.10 will run Pulseaudio, btw.)
That there are no noise floor calibration timeouts under kubuntu seems
interesting though. I'm not sure
Tonight I had a few minutes to experiment.
I decided to try VLC as it is a different kind of audio client, lots of
things to tweak, and it knows about pulse audio.
So I installed it, and picked a directory, and started playing it.
Below is the log file info related to a stutter. Note the first
Clues? No, rather the opposite...
It sounds like you're getting an underrun on the front end of PA (the
application does not supply PA with sound data quickly enough), but that
should have showed up in the PA log as 0 bytes on memblock renderq or
something like that (don't remember the exact
Ok, more experimentation with play-file in pacmd, and there is no
stuttering. Doesn't seem to be affected if I am running e-mail, web
browser, etc simultaneously.
I've jumped back to Exaile to play the same music. Sure enough, some
ath5k messages and a stutter.
I see a message cluster in
Well, I'm also out of really good ideas, but if you have the time, I guess you
just have to continue investigating and trying combinations of what causes high
latencies and what don't. E g trying Karmic with a different kernel, trying a
preemptive kernel, a mainline kernel, etc.
If you find
Here's an interesting thing
I was reading over First Steps on the pulseaudio website, and I
noticed the pulseaudio command play-file.
I fooled around a bit trying to kill pulseaudio and start it up from the
command line with pulseaudio -nC but it seems some system service is
restarting it
I feel stuck at this point. I would like to test some more but I don't
really have any good ideas.
Is there some kind of pulse audio reconfiguration that I should try?
Should I try to remove pulse audio?
Should I try a fresh install of Kubuntu 10.04 on my spare hard drive to
see if it causes
I have been carrying out tests as per David H.'s instructions but we
have not found any workarounds nor fixes. I don't believe David is
waiting for more info so I marked it as new; sorry if that's not
right.
** Changed in: linux (Ubuntu)
Status: Expired = New
--
Wireless blocks
This bug report was marked as Incomplete and has not had any updated
comments for quite some time. As a result this bug is being closed.
Please reopen if this is still an issue in the current Ubuntu release
http://www.ubuntu.com/getubuntu/download . Also, please be sure to
provide any requested
Ok so fresh hard drive fresh 9.10 install with latencytop running
alongside Bob Marley.
Here's what I see.
This is the original disk that came with the laptop, a 100gb 4400 rpm
drive; it's pretty slow.
I see two causes with higher latency: fsync() on a file, and scheduler:
waiting for cpu
So I decided to run latencytop here while not doing much. The wireless
is on and I'm reading your e-mail. After the first refresh, here's what
I see under Global:
Scheduler: waiting for cpu 255.7ms
fsync() on a file (type 'F' for details)29.3ms
Opening file
David, I was doing some further digging on the scheduler: waiting for
cpu thing. There is this thread that is interesting:
https://patchwork.kernel.org/patch/52509/
where it seems others are seeing high-ish latencies in relation to this.
I tried rebooting with the nohz=off but I saw no
On the bios upgrade: my bios is 1.5 which seems to be the latest on
Toshiba's website. So I guess there's nothing there.
--
Wireless blocks USB-Audio, leading to dropouts
https://bugs.launchpad.net/bugs/579117
You received this bug notification because you are a member of Ubuntu
Bugs, which is
Three more things to add.
First, I have a very similar, slightly older laptop than this one. Same
model number etc but about an 8 month earlier build with a slightly
slower processor. It's a kind of spare. It has 10.04 on it, but
otherwise nothing much in the way of installed stuff. So I
There is another way we could try. You began this entire thread by
saying that this did not occur in 9.10. Can you verify that with
latencytop and/or cyclictest, what are the maximum latencies there?
Assuming 9.10 latencies are way lower, it is possible to try to find the
exact kernel patch
It sound like a big latency to me as well. You could be suffering from
SMI (see http://en.wikipedia.org/wiki/System_Management_Mode ) in which
case there is not that much one can do about it (try updating BIOS). I'm
still new at this and learn as I go, so I'm not sure if 127 ms is
something that a
David, just a thought here, but please remember this is a USB audio
device. Does that mean anything, in terms of latency issues?
--
Wireless blocks USB-Audio, leading to dropouts
https://bugs.launchpad.net/bugs/579117
You received this bug notification because you are a member of Ubuntu
Bugs,
Hmm...is there a way we can make those high latencies go away? I mean,
if the wireless is down, usb-audio is unplugged, no music playing, the
computer is just idle for a minute - are there still high latencies?
Given you find such a state, it would be easier for you to try to find
what is causing
Ok I made them go away a bit.
Clicked on disconnect in NetworkManager. ifconfig down on wlan0 and
eth0 interfaces, leaving only lo0. Started up a terminal, nothing else
(save what Ubuntu starts up on its own). Ran the same cyclictest as
above.
Here are the first few lines of the histogram,
Ok I have tried out cyclictest, here are the results.
I used the version from the repositories, run with the command:
sudo time cyclictest --histogram=100 histogram.txt
Prior to starting cyclictest, I opened the log file viewer and went to
the end of the messages. Then I started
Right, your results look way ahead of mine, I was listening to webradio
for a minute (over wired network) and got a max latency of 3409 - 3,4
ms, i e nothing in any bucket above that. To conclude that it is the
wireless causing the problem, could you try the same test without the
wireless
I certainly can; I hope to get to that tomorrow evening (GMT-8 right
now).
On Tue, 2010-05-25 at 01:52 +, David Henningsson wrote:
Right, your results look way ahead of mine, I was listening to webradio
for a minute (over wired network) and got a max latency of 3409 - 3,4
ms, i e nothing
Ok no one is in a hurry to get to bed here, so I tried it.
I disabled wireless by using the disconnect in NetworkManager applet;
then I used sudo ifconfig wlan0 down to disable it.
I don't have a wired connection, though I notice eth0 is up as well.
Anyway, I didn't touch it.
So, the results!
First, the logging does not make sense to me; in the default
configuration (/etc/rsyslog.d/50-default.conf) says that what goes to
/var/log/messages is a subset of what goes to /var/log/syslog.
I feel somewhat out on deep water here (I should really learn more about this),
but there is a test
I'm afraid I don't know much more than you do at this point.
Theoretically, if the watermark is 60 ms, anything below approx 50 ms
shouldn't cause an underrun.
Btw, are the calibration timeout and the underrun messages
synchronized? You should be able to see both if you look in
/var/log/syslog.
David, /var/log/syslog contains the calibration timeout
messages; /var/log/messages contains the Underrun! messages... but
anyway, that's what sort is for...
In answer to your question, they are often synchronized:
Starting with a sample at 07:54 yesterday:
the 1st Underrun happens at 07:54:11,
In case it's useful, I attach a merge of syslog and messages (sort -u)
that covers from just before a startup of Rhythmbox, through a few
underruns, to terminating Rhythmbox partway through the first song.
On Thu, 2010-05-20 at 02:14 +, Chris Hermansen wrote:
David, /var/log/syslog contains
Oh, Latencytop has got a new UI for Lucid, nice :-) Although it is still
missing decent documentation :-(
Anyway, I guess the most important thing would be to look at the
pulseaudio process after an underrun and see if anything seems strange
there, or if you get anything above 20 ms.
--
Now that I've watched the messages file enough, I see there's a pattern;
I get several successive underruns fairly quickly with the wakeup
watermark increased from 30ms through 60ms, then things level off for
awhile.
Anyway, after the first underrun, here's what I see in pulseaudio:
scheduler:
40 matches
Mail list logo
