Re: [alsa-devel] [Fwd: Re: [pulseaudio-discuss] pulseaudio debug mode]
2010/7/26 Chris cpollock@embarqmail.com
Raymond, attached is a post I made today to the pulseaudio list.
From: Chris cpollock@embarqmail.com To: pulseaudio-discuss@mail.0pointer.de Date: Sun, 25 Jul 2010 12:15:02 -0500 Subject: Re: [pulseaudio-discuss] pulseaudio debug mode On Fri, 2010-07-23 at 08:58 +0100, Colin Guthrie wrote:
'Twas brillig, and Chris at 23/07/10 02:04 did gyre and gimble:
What is the best way to start PA for debugging and still have all the usual clients running?
If you mean having all the clients connect (e.g. applications with libcanberra support or similar for sound events), then there are basically two ways.
The first is as Luke suggests. These clients will automatically reconnect to PA if they need to (provided you have a vaguely recent libcanberra), after it is restarted and run in debug mode.
Alternatively you can simply set debug-level to "debug" in daemon.conf (in /etc/pulse or ~/.pulse), and then "grep pulseaudio /var/log/messages"
Col
Colin, link below is for debug output also some other output. Anything look out of place that would cause the overruns?
http://pastebin.com/ZWSWmXZt
Most likely you will need to set debug-level to "debug" in daemon.conf logout and login , and check the /var/log/messages
I suspect it occur after PA server abort and auto spawn , so please don't just post the PA log starting from "asyncq overrun" , you need to post from the last two PA startup sequence before the error occur since we need to know why PA auto spawn
On Mon, 2010-07-26 at 07:31 +0800, Raymond Yau wrote:
2010/7/26 Chris cpollock@embarqmail.com
Raymond, attached is a post I made today to the pulseaudio list.
From: Chris cpollock@embarqmail.com To: pulseaudio-discuss@mail.0pointer.de Date: Sun, 25 Jul 2010 12:15:02 -0500 Subject: Re: [pulseaudio-discuss] pulseaudio debug mode On Fri, 2010-07-23 at 08:58 +0100, Colin Guthrie wrote:
'Twas brillig, and Chris at 23/07/10 02:04 did gyre and gimble:
What is the best way to start PA for debugging and still have all the usual clients running?
If you mean having all the clients connect (e.g. applications with libcanberra support or similar for sound events), then there are basically two ways.
The first is as Luke suggests. These clients will automatically reconnect to PA if they need to (provided you have a vaguely recent libcanberra), after it is restarted and run in debug mode.
Alternatively you can simply set debug-level to "debug" in daemon.conf (in /etc/pulse or ~/.pulse), and then "grep pulseaudio /var/log/messages"
Col
Colin, link below is for debug output also some other output. Anything look out of place that would cause the overruns?
http://pastebin.com/ZWSWmXZt
Most likely you will need to set debug-level to "debug" in daemon.conf logout and login , and check the /var/log/messages
I suspect it occur after PA server abort and auto spawn , so please don't just post the PA log starting from "asyncq overrun" , you need to post from the last two PA startup sequence before the error occur since we need to know why PA auto spawn
Is this what you mean Raymond: http://pastebin.com/4RT7YaG6
2010/7/26 Chris cpollock@embarqmail.com
On Mon, 2010-07-26 at 07:31 +0800, Raymond Yau wrote:
2010/7/26 Chris cpollock@embarqmail.com
Raymond, attached is a post I made today to the pulseaudio list.
From: Chris cpollock@embarqmail.com To: pulseaudio-discuss@mail.0pointer.de Date: Sun, 25 Jul 2010 12:15:02 -0500 Subject: Re: [pulseaudio-discuss] pulseaudio debug mode On Fri, 2010-07-23 at 08:58 +0100, Colin Guthrie wrote:
'Twas brillig, and Chris at 23/07/10 02:04 did gyre and gimble:
What is the best way to start PA for debugging and still have all
the
usual clients running?
If you mean having all the clients connect (e.g. applications with libcanberra support or similar for sound events), then there are basically two ways.
The first is as Luke suggests. These clients will automatically reconnect to PA if they need to (provided you have a vaguely recent libcanberra), after it is restarted and run in debug mode.
Alternatively you can simply set debug-level to "debug" in
daemon.conf
(in /etc/pulse or ~/.pulse), and then "grep pulseaudio
/var/log/messages"
Col
Colin, link below is for debug output also some other output. Anything look out of place that would cause the overruns?
http://pastebin.com/ZWSWmXZt
Most likely you will need to set debug-level to "debug" in daemon.conf logout and login , and check the /var/log/messages
I suspect it occur after PA server abort and auto spawn , so please don't just post the PA log starting from "asyncq overrun" , you need to post
from
the last two PA startup sequence before the error occur since we need to know why PA auto spawn
Is this what you mean Raymond: http://pastebin.com/4RT7YaG6
No, you don't have "asyncq overrun" error in these log
if you had change the "debug-level", the log still keep in /var/log/messages
The PA client which can connected to PA server before the PA server start the playing thread is the PA client which autospawn the PA server
On Mon, 2010-07-26 at 09:45 +0800, Raymond Yau wrote:
2010/7/26 Chris cpollock@embarqmail.com
On Mon, 2010-07-26 at 07:31 +0800, Raymond Yau wrote:
2010/7/26 Chris cpollock@embarqmail.com
Raymond, attached is a post I made today to the pulseaudio list.
From: Chris cpollock@embarqmail.com To: pulseaudio-discuss@mail.0pointer.de Date: Sun, 25 Jul 2010 12:15:02 -0500 Subject: Re: [pulseaudio-discuss] pulseaudio debug mode On Fri, 2010-07-23 at 08:58 +0100, Colin Guthrie wrote:
'Twas brillig, and Chris at 23/07/10 02:04 did gyre and gimble:
What is the best way to start PA for debugging and still have all
the
usual clients running?
If you mean having all the clients connect (e.g. applications with libcanberra support or similar for sound events), then there are basically two ways.
The first is as Luke suggests. These clients will automatically reconnect to PA if they need to (provided you have a vaguely recent libcanberra), after it is restarted and run in debug mode.
Alternatively you can simply set debug-level to "debug" in
daemon.conf
(in /etc/pulse or ~/.pulse), and then "grep pulseaudio
/var/log/messages"
Col
Colin, link below is for debug output also some other output. Anything look out of place that would cause the overruns?
http://pastebin.com/ZWSWmXZt
Most likely you will need to set debug-level to "debug" in daemon.conf logout and login , and check the /var/log/messages
I suspect it occur after PA server abort and auto spawn , so please don't just post the PA log starting from "asyncq overrun" , you need to post
from
the last two PA startup sequence before the error occur since we need to know why PA auto spawn
Is this what you mean Raymond: http://pastebin.com/4RT7YaG6
No, you don't have "asyncq overrun" error in these log
if you had change the "debug-level", the log still keep in /var/log/messages
The PA client which can connected to PA server before the PA server start the playing thread is the PA client which autospawn the PA server
The log level has been set to debug all day
### Read from configuration file: /home/chris/.pulse//daemon.conf ### daemonize = no fail = yes high-priority = yes nice-level = -11 realtime-scheduling = yes realtime-priority = 5 allow-module-loading = yes allow-exit = yes use-pid-file = yes system-instance = no cpu-limit = no enable-shm = yes flat-volumes = yes lock-memory = no exit-idle-time = 20 scache-idle-time = 20 dl-search-path = /usr/lib/pulse-0.9.21/modules default-script-file = /etc/pulse/default.pa load-default-script-file = yes log-target = auto log-level = debug resample-method = speex-float-0 enable-remixing = yes enable-lfe-remixing = no default-sample-format = s16le default-sample-rate = 44100 default-sample-channels = 2 default-channel-map = front-left,front-right default-fragments = 4 default-fragment-size-msec = 25 shm-size-bytes = 0 log-meta = no log-time = yes log-backtrace = 0 rlimit-fsize = -1 rlimit-data = -1 rlimit-stack = -1 rlimit-core = -1 rlimit-rss = -1 rlimit-as = -1 rlimit-nproc = -1 rlimit-nofile = 256 rlimit-memlock = -1 rlimit-locks = -1 rlimit-sigpending = -1 rlimit-msgqueue = -1 rlimit-nice = 31 rlimit-rtprio = 9 rlimit-rttime = 1000000
The is what happens after a fresh log-in and Mandrive update is running and I also start Firefox:
Jul 25 21:48:22 localhost mdkapplet[16332]: Computing new updates... Jul 25 21:48:23 localhost mdkapplet[16332]: running: urpmi.update --update Jul 25 21:48:39 localhost mdkapplet[16332]: updating inactive backport media Main Backports (Official2010.1-4), Contrib Backports (Official2010.1-12), Non-free Backports (Official2010.1-20), PLF Free backports, PLF Non-free backports Jul 25 21:48:39 localhost mdkapplet[16332]: running: urpmi.update Main Backports (Official2010.1-4) Jul 25 21:48:46 localhost mdkapplet[16332]: running: urpmi.update Contrib Backports (Official2010.1-12) Jul 25 21:48:48 localhost mdkapplet[16332]: running: urpmi.update Non-free Backports (Official2010.1-20) Jul 25 21:48:51 localhost mdkapplet[16332]: running: urpmi.update PLF Free backports Jul 25 21:48:55 localhost mdkapplet[16332]: running: urpmi.update PLF Non-free backports Jul 25 21:48:57 localhost pulseaudio[26721]: (7440.932| 71.318) client.c: Created 44 "Native client (UNIX socket client)" Jul 25 21:48:57 localhost pulseaudio[26721]: (7440.932| 0.000) protocol-native.c: Protocol version: remote 16, local 16 Jul 25 21:48:57 localhost pulseaudio[26721]: (7440.932| 0.000) protocol-native.c: Got credentials: uid=500 gid=500 success=1 Jul 25 21:48:57 localhost pulseaudio[26721]: (7440.932| 0.000) protocol-native.c: SHM possible: yes Jul 25 21:48:57 localhost pulseaudio[26721]: (7440.932| 0.000) protocol-native.c: Negotiated SHM: yes Jul 25 21:48:57 localhost pulseaudio[26721]: (7440.934| 0.001) module-augment-properties.c: Looking for .desktop file for firefox Jul 25 21:49:19 localhost pulseaudio[26721]: (7462.497| 21.563) asyncq.c: q overrun, queuing locally Jul 25 21:49:19 localhost pulseaudio[26721]: (7462.577| 0.080) asyncq.c: q overrun, queuing locally Jul 25 21:49:19 localhost pulseaudio[26721]: (7462.577| 0.000) asyncq.c: q overrun, queuing locally Jul 25 21:49:19 localhost pulseaudio[26721]: (7462.657| 0.079) asyncq.c: q overrun, queuing locally Jul 25 21:49:19 localhost pulseaudio[26721]: (7462.737| 0.080) asyncq.c: q overrun, queuing locally Jul 25 21:49:19 localhost pulseaudio[26721]: (7462.737| 0.000) asyncq.c: q overrun, queuing locally Jul 25 21:49:19 localhost pulseaudio[26721]: (7462.737| 0.000) asyncq.c: q overrun, queuing locally Jul 25 21:49:19 localhost pulseaudio[26721]: (7462.737| 0.000) asyncq.c: q overrun, queuing locally Jul 25 21:49:19 localhost pulseaudio[26721]: (7462.817| 0.079) asyncq.c: q overrun, queuing locally Jul 25 21:49:19 localhost pulseaudio[26721]: (7462.817| 0.000) asyncq.c: q overrun, queuing locally Jul 25 21:49:19 localhost pulseaudio[26721]: (7462.897| 0.079) asyncq.c: q overrun, queuing locally Jul 25 21:49:51 localhost mdkapplet[16332]: Packages are up to date
2010/7/26 Chris cpollock@embarqmail.com
On Mon, 2010-07-26 at 09:45 +0800, Raymond Yau wrote:
2010/7/26 Chris cpollock@embarqmail.com
On Mon, 2010-07-26 at 07:31 +0800, Raymond Yau wrote:
2010/7/26 Chris cpollock@embarqmail.com
Raymond, attached is a post I made today to the pulseaudio list.
From: Chris cpollock@embarqmail.com To: pulseaudio-discuss@mail.0pointer.de Date: Sun, 25 Jul 2010 12:15:02 -0500 Subject: Re: [pulseaudio-discuss] pulseaudio debug mode On Fri, 2010-07-23 at 08:58 +0100, Colin Guthrie wrote:
'Twas brillig, and Chris at 23/07/10 02:04 did gyre and gimble: > What is the best way to start PA for debugging and still have
all
the
> usual clients running?
If you mean having all the clients connect (e.g. applications
with
libcanberra support or similar for sound events), then there are basically two ways.
The first is as Luke suggests. These clients will automatically reconnect to PA if they need to (provided you have a vaguely
recent
libcanberra), after it is restarted and run in debug mode.
Alternatively you can simply set debug-level to "debug" in
daemon.conf
(in /etc/pulse or ~/.pulse), and then "grep pulseaudio
/var/log/messages"
Col
Colin, link below is for debug output also some other output.
Anything
look out of place that would cause the overruns?
http://pastebin.com/ZWSWmXZt
Most likely you will need to set debug-level to "debug" in
daemon.conf
logout and login , and check the /var/log/messages
I suspect it occur after PA server abort and auto spawn , so please
don't
just post the PA log starting from "asyncq overrun" , you need to
post
from
the last two PA startup sequence before the error occur since we need
to
know why PA auto spawn
Is this what you mean Raymond: http://pastebin.com/4RT7YaG6
No, you don't have "asyncq overrun" error in these log
if you had change the "debug-level", the log still keep in
/var/log/messages
The PA client which can connected to PA server before the PA server start the playing thread is the PA client which autospawn the PA server
The log level has been set to debug all day
### Read from configuration file: /home/chris/.pulse//daemon.conf ### daemonize = no fail = yes high-priority = yes nice-level = -11 realtime-scheduling = yes realtime-priority = 5 allow-module-loading = yes allow-exit = yes use-pid-file = yes system-instance = no cpu-limit = no enable-shm = yes flat-volumes = yes lock-memory = no exit-idle-time = 20 scache-idle-time = 20 dl-search-path = /usr/lib/pulse-0.9.21/modules default-script-file = /etc/pulse/default.pa load-default-script-file = yes log-target = auto log-level = debug resample-method = speex-float-0 enable-remixing = yes enable-lfe-remixing = no default-sample-format = s16le default-sample-rate = 44100 default-sample-channels = 2 default-channel-map = front-left,front-right default-fragments = 4 default-fragment-size-msec = 25 shm-size-bytes = 0 log-meta = no log-time = yes log-backtrace = 0 rlimit-fsize = -1 rlimit-data = -1 rlimit-stack = -1 rlimit-core = -1 rlimit-rss = -1 rlimit-as = -1 rlimit-nproc = -1 rlimit-nofile = 256 rlimit-memlock = -1 rlimit-locks = -1 rlimit-sigpending = -1 rlimit-msgqueue = -1 rlimit-nice = 31 rlimit-rtprio = 9 rlimit-rttime = 1000000
The is what happens after a fresh log-in and Mandrive update is running and I also start Firefox:
Jul 25 21:48:22 localhost mdkapplet[16332]: Computing new updates... Jul 25 21:48:23 localhost mdkapplet[16332]: running: urpmi.update --update Jul 25 21:48:39 localhost mdkapplet[16332]: updating inactive backport media Main Backports (Official2010.1-4), Contrib Backports (Official2010.1-12), Non-free Backports (Official2010.1-20), PLF Free backports, PLF Non-free backports Jul 25 21:48:39 localhost mdkapplet[16332]: running: urpmi.update Main Backports (Official2010.1-4) Jul 25 21:48:46 localhost mdkapplet[16332]: running: urpmi.update Contrib Backports (Official2010.1-12) Jul 25 21:48:48 localhost mdkapplet[16332]: running: urpmi.update Non-free Backports (Official2010.1-20) Jul 25 21:48:51 localhost mdkapplet[16332]: running: urpmi.update PLF Free backports Jul 25 21:48:55 localhost mdkapplet[16332]: running: urpmi.update PLF Non-free backports Jul 25 21:48:57 localhost pulseaudio[26721]: (7440.932| 71.318) client.c: Created 44 "Native client (UNIX socket client)" Jul 25 21:48:57 localhost pulseaudio[26721]: (7440.932| 0.000) protocol-native.c: Protocol version: remote 16, local 16 Jul 25 21:48:57 localhost pulseaudio[26721]: (7440.932| 0.000) protocol-native.c: Got credentials: uid=500 gid=500 success=1 Jul 25 21:48:57 localhost pulseaudio[26721]: (7440.932| 0.000) protocol-native.c: SHM possible: yes Jul 25 21:48:57 localhost pulseaudio[26721]: (7440.932| 0.000) protocol-native.c: Negotiated SHM: yes Jul 25 21:48:57 localhost pulseaudio[26721]: (7440.934| 0.001) module-augment-properties.c: Looking for .desktop file for firefox Jul 25 21:49:19 localhost pulseaudio[26721]: (7462.497| 21.563) asyncq.c: q overrun, queuing locally Jul 25 21:49:19 localhost pulseaudio[26721]: (7462.577| 0.080) asyncq.c: q overrun, queuing locally Jul 25 21:49:19 localhost pulseaudio[26721]: (7462.577| 0.000) asyncq.c: q overrun, queuing locally Jul 25 21:49:19 localhost pulseaudio[26721]: (7462.657| 0.079) asyncq.c: q overrun, queuing locally Jul 25 21:49:19 localhost pulseaudio[26721]: (7462.737| 0.080) asyncq.c: q overrun, queuing locally Jul 25 21:49:19 localhost pulseaudio[26721]: (7462.737| 0.000) asyncq.c: q overrun, queuing locally Jul 25 21:49:19 localhost pulseaudio[26721]: (7462.737| 0.000) asyncq.c: q overrun, queuing locally Jul 25 21:49:19 localhost pulseaudio[26721]: (7462.737| 0.000) asyncq.c: q overrun, queuing locally Jul 25 21:49:19 localhost pulseaudio[26721]: (7462.817| 0.079) asyncq.c: q overrun, queuing locally Jul 25 21:49:19 localhost pulseaudio[26721]: (7462.817| 0.000) asyncq.c: q overrun, queuing locally Jul 25 21:49:19 localhost pulseaudio[26721]: (7462.897| 0.079) asyncq.c: q overrun, queuing locally Jul 25 21:49:51 localhost mdkapplet[16332]: Packages are up to date
I have no idea why "asyncq.c: q overrun, queuing locally" appear
But I have another question ,
did update manager stop pulseaudio server when the update manager want to update pulseaudio package ?
Actually I don't notice yum -y update stop the PA server if it updated pulseaudio package (install new pulseaudio and remove old pulseaudio package) and restart PA server on Fedora 10
'Twas brillig, and Raymond Yau at 26/07/10 04:22 did gyre and gimble:
But I have another question ,
did update manager stop pulseaudio server when the update manager want to update pulseaudio package ?
Actually I don't notice yum -y update stop the PA server if it updated pulseaudio package (install new pulseaudio and remove old pulseaudio package) and restart PA server on Fedora 10
PA is *not* restarted when a new version is installed and I suspect this does not happen on Fedora either (but I could be wrong).
The reason is that PA is a per-user daemon, not a system service. If three users were logged in, then each of their PA servers would need to be killed and restarted but due to console-kit, only the active user would get access to the devices which could cause enumeration issues etc.
It could maybe be handled better, but doing so would be rather complex.
Col
2010/7/26 Colin Guthrie gmane@colin.guthr.ie
'Twas brillig, and Raymond Yau at 26/07/10 04:22 did gyre and gimble:
But I have another question ,
did update manager stop pulseaudio server when the update manager want to update pulseaudio package ?
Actually I don't notice yum -y update stop the PA server if it updated pulseaudio package (install new pulseaudio and remove old pulseaudio package) and restart PA server on Fedora 10
PA is *not* restarted when a new version is installed and I suspect this does not happen on Fedora either (but I could be wrong).
The reason is that PA is a per-user daemon, not a system service. If three users were logged in, then each of their PA servers would need to be killed and restarted but due to console-kit, only the active user would get access to the devices which could cause enumeration issues etc.
It could maybe be handled better, but doing so would be rather complex.
Col
Yes , I know that PA is not a system service
how do you setup PA for three users logged in with each of their PA server running even when you have three sound cards since you will need to hack the udev rule to exclude the other two sound cards ?
I got "Too many inputs per sink" error on PA server during software install/remove on last week when I run pulseaudio on a terminal.
No much info in the server log, the most common PA clients were "tooltips popup" when I move the mouse cursor across the different part/icon on the system bar
Is there any limit on the the number of PA clients connected to PA server ?
2010/7/26 Chris cpollock@embarqmail.com
On Mon, 2010-07-26 at 09:45 +0800, Raymond Yau wrote:
2010/7/26 Chris cpollock@embarqmail.com
On Mon, 2010-07-26 at 07:31 +0800, Raymond Yau wrote:
2010/7/26 Chris cpollock@embarqmail.com
Raymond, attached is a post I made today to the pulseaudio list.
From: Chris cpollock@embarqmail.com To: pulseaudio-discuss@mail.0pointer.de Date: Sun, 25 Jul 2010 12:15:02 -0500 Subject: Re: [pulseaudio-discuss] pulseaudio debug mode On Fri, 2010-07-23 at 08:58 +0100, Colin Guthrie wrote:
'Twas brillig, and Chris at 23/07/10 02:04 did gyre and gimble: > What is the best way to start PA for debugging and still have
all
the
> usual clients running?
If you mean having all the clients connect (e.g. applications
with
libcanberra support or similar for sound events), then there are basically two ways.
The first is as Luke suggests. These clients will automatically reconnect to PA if they need to (provided you have a vaguely
recent
libcanberra), after it is restarted and run in debug mode.
Alternatively you can simply set debug-level to "debug" in
daemon.conf
(in /etc/pulse or ~/.pulse), and then "grep pulseaudio
/var/log/messages"
Col
Colin, link below is for debug output also some other output.
Anything
look out of place that would cause the overruns?
http://pastebin.com/ZWSWmXZt
Most likely you will need to set debug-level to "debug" in
daemon.conf
logout and login , and check the /var/log/messages
I suspect it occur after PA server abort and auto spawn , so please
don't
just post the PA log starting from "asyncq overrun" , you need to
post
from
the last two PA startup sequence before the error occur since we need
to
know why PA auto spawn
Is this what you mean Raymond: http://pastebin.com/4RT7YaG6
No, you don't have "asyncq overrun" error in these log
if you had change the "debug-level", the log still keep in
/var/log/messages
The PA client which can connected to PA server before the PA server start the playing thread is the PA client which autospawn the PA server
The log level has been set to debug all day
### Read from configuration file: /home/chris/.pulse//daemon.conf ### daemonize = no fail = yes high-priority = yes nice-level = -11 realtime-scheduling = yes realtime-priority = 5 allow-module-loading = yes allow-exit = yes use-pid-file = yes system-instance = no cpu-limit = no enable-shm = yes flat-volumes = yes lock-memory = no exit-idle-time = 20 scache-idle-time = 20 dl-search-path = /usr/lib/pulse-0.9.21/modules default-script-file = /etc/pulse/default.pa load-default-script-file = yes log-target = auto log-level = debug resample-method = speex-float-0 enable-remixing = yes enable-lfe-remixing = no default-sample-format = s16le default-sample-rate = 44100 default-sample-channels = 2 default-channel-map = front-left,front-right default-fragments = 4 default-fragment-size-msec = 25 shm-size-bytes = 0 log-meta = no log-time = yes log-backtrace = 0 rlimit-fsize = -1 rlimit-data = -1 rlimit-stack = -1 rlimit-core = -1 rlimit-rss = -1 rlimit-as = -1 rlimit-nproc = -1 rlimit-nofile = 256 rlimit-memlock = -1 rlimit-locks = -1 rlimit-sigpending = -1 rlimit-msgqueue = -1 rlimit-nice = 31 rlimit-rtprio = 9 rlimit-rttime = 1000000
The is what happens after a fresh log-in and Mandrive update is running and I also start Firefox:
Jul 25 21:48:22 localhost mdkapplet[16332]: Computing new updates... Jul 25 21:48:23 localhost mdkapplet[16332]: running: urpmi.update --update Jul 25 21:48:39 localhost mdkapplet[16332]: updating inactive backport media Main Backports (Official2010.1-4), Contrib Backports (Official2010.1-12), Non-free Backports (Official2010.1-20), PLF Free backports, PLF Non-free backports Jul 25 21:48:39 localhost mdkapplet[16332]: running: urpmi.update Main Backports (Official2010.1-4) Jul 25 21:48:46 localhost mdkapplet[16332]: running: urpmi.update Contrib Backports (Official2010.1-12) Jul 25 21:48:48 localhost mdkapplet[16332]: running: urpmi.update Non-free Backports (Official2010.1-20) Jul 25 21:48:51 localhost mdkapplet[16332]: running: urpmi.update PLF Free backports Jul 25 21:48:55 localhost mdkapplet[16332]: running: urpmi.update PLF Non-free backports Jul 25 21:48:57 localhost pulseaudio[26721]: (7440.932| 71.318) client.c: Created 44 "Native client (UNIX socket client)" Jul 25 21:48:57 localhost pulseaudio[26721]: (7440.932| 0.000) protocol-native.c: Protocol version: remote 16, local 16 Jul 25 21:48:57 localhost pulseaudio[26721]: (7440.932| 0.000) protocol-native.c: Got credentials: uid=500 gid=500 success=1 Jul 25 21:48:57 localhost pulseaudio[26721]: (7440.932| 0.000) protocol-native.c: SHM possible: yes Jul 25 21:48:57 localhost pulseaudio[26721]: (7440.932| 0.000) protocol-native.c: Negotiated SHM: yes Jul 25 21:48:57 localhost pulseaudio[26721]: (7440.934| 0.001) module-augment-properties.c: Looking for .desktop file for firefox Jul 25 21:49:19 localhost pulseaudio[26721]: (7462.497| 21.563) asyncq.c: q overrun, queuing locally Jul 25 21:49:19 localhost pulseaudio[26721]: (7462.577| 0.080) asyncq.c: q overrun, queuing locally Jul 25 21:49:19 localhost pulseaudio[26721]: (7462.577| 0.000) asyncq.c: q overrun, queuing locally Jul 25 21:49:19 localhost pulseaudio[26721]: (7462.657| 0.079) asyncq.c: q overrun, queuing locally Jul 25 21:49:19 localhost pulseaudio[26721]: (7462.737| 0.080) asyncq.c: q overrun, queuing locally Jul 25 21:49:19 localhost pulseaudio[26721]: (7462.737| 0.000) asyncq.c: q overrun, queuing locally Jul 25 21:49:19 localhost pulseaudio[26721]: (7462.737| 0.000) asyncq.c: q overrun, queuing locally Jul 25 21:49:19 localhost pulseaudio[26721]: (7462.737| 0.000) asyncq.c: q overrun, queuing locally Jul 25 21:49:19 localhost pulseaudio[26721]: (7462.817| 0.079) asyncq.c: q overrun, queuing locally Jul 25 21:49:19 localhost pulseaudio[26721]: (7462.817| 0.000) asyncq.c: q overrun, queuing locally Jul 25 21:49:19 localhost pulseaudio[26721]: (7462.897| 0.079) asyncq.c: q overrun, queuing locally Jul 25 21:49:51 localhost mdkapplet[16332]: Packages are up to date
you should ask PA developer to add code to debug since this is a queue used by PA and has no relationship with alsa ,
alsa-sink and alsa-source can only post PA_CORE_MESSAGE_UNLOAD_MODULE
modules/alsa/alsa-sink.c: pa_asyncmsgq_post(u->thread_mq.outq, PA_MSGOBJECT(u->core), PA_CORE_MESSAGE_UNLOAD_MODULE, u->module, 0, NULL, NULL); modules/alsa/alsa-source.c: pa_asyncmsgq_post(u->thread_mq.outq, PA_MSGOBJECT(u->core), PA_CORE_MESSAGE_UNLOAD_MODULE, u->module, 0, NULL, NULL);
and you have to copy definition of struct asyncmsgq_item from asyncmsgq.c
void pa_asyncq_post(pa_asyncq*l, void *p) { struct localq *q; + struct asyncmsgq_item *i;
pa_assert(l); pa_assert(p);
+ i=( struct asyncmsgq_item *)p;
if (flush_postq(l, FALSE)) if (pa_asyncq_push(l, p, FALSE) >= 0) return;
/* OK, we couldn't push anything in the queue. So let's queue it * locally and push it later */
if (pa_log_ratelimit()) - pa_log_warn("q overrun, queuing locally"); + pa_log_warn("q overrun, queuing locally code %d",i->code);
2010/7/26 Raymond Yau superquad.vortex2@gmail.com
2010/7/26 Chris cpollock@embarqmail.com
On Mon, 2010-07-26 at 09:45 +0800, Raymond Yau wrote:
2010/7/26 Chris cpollock@embarqmail.com
On Mon, 2010-07-26 at 07:31 +0800, Raymond Yau wrote:
2010/7/26 Chris cpollock@embarqmail.com
Raymond, attached is a post I made today to the pulseaudio list.
From: Chris cpollock@embarqmail.com To: pulseaudio-discuss@mail.0pointer.de Date: Sun, 25 Jul 2010 12:15:02 -0500 Subject: Re: [pulseaudio-discuss] pulseaudio debug mode On Fri, 2010-07-23 at 08:58 +0100, Colin Guthrie wrote: > 'Twas brillig, and Chris at 23/07/10 02:04 did gyre and gimble: > > What is the best way to start PA for debugging and still have
all
the
> > usual clients running? > > If you mean having all the clients connect (e.g. applications
with
> libcanberra support or similar for sound events), then there are > basically two ways. > > The first is as Luke suggests. These clients will automatically > reconnect to PA if they need to (provided you have a vaguely
recent
> libcanberra), after it is restarted and run in debug mode. > > Alternatively you can simply set debug-level to "debug" in
daemon.conf
> (in /etc/pulse or ~/.pulse), and then "grep pulseaudio
/var/log/messages"
> > Col >
Colin, link below is for debug output also some other output.
Anything
look out of place that would cause the overruns?
http://pastebin.com/ZWSWmXZt
Most likely you will need to set debug-level to "debug" in
daemon.conf
logout and login , and check the /var/log/messages
I suspect it occur after PA server abort and auto spawn , so please
don't
just post the PA log starting from "asyncq overrun" , you need to
post
from
the last two PA startup sequence before the error occur since we
need to
know why PA auto spawn
Is this what you mean Raymond: http://pastebin.com/4RT7YaG6
No, you don't have "asyncq overrun" error in these log
if you had change the "debug-level", the log still keep in
/var/log/messages
The PA client which can connected to PA server before the PA server
start
the playing thread is the PA client which autospawn the PA server
The log level has been set to debug all day
### Read from configuration file: /home/chris/.pulse//daemon.conf ### daemonize = no fail = yes high-priority = yes nice-level = -11 realtime-scheduling = yes realtime-priority = 5 allow-module-loading = yes allow-exit = yes use-pid-file = yes system-instance = no cpu-limit = no enable-shm = yes flat-volumes = yes lock-memory = no exit-idle-time = 20 scache-idle-time = 20 dl-search-path = /usr/lib/pulse-0.9.21/modules default-script-file = /etc/pulse/default.pa load-default-script-file = yes log-target = auto log-level = debug resample-method = speex-float-0 enable-remixing = yes enable-lfe-remixing = no default-sample-format = s16le default-sample-rate = 44100 default-sample-channels = 2 default-channel-map = front-left,front-right default-fragments = 4 default-fragment-size-msec = 25 shm-size-bytes = 0 log-meta = no log-time = yes log-backtrace = 0 rlimit-fsize = -1 rlimit-data = -1 rlimit-stack = -1 rlimit-core = -1 rlimit-rss = -1 rlimit-as = -1 rlimit-nproc = -1 rlimit-nofile = 256 rlimit-memlock = -1 rlimit-locks = -1 rlimit-sigpending = -1 rlimit-msgqueue = -1 rlimit-nice = 31 rlimit-rtprio = 9 rlimit-rttime = 1000000
The is what happens after a fresh log-in and Mandrive update is running and I also start Firefox:
Jul 25 21:48:22 localhost mdkapplet[16332]: Computing new updates... Jul 25 21:48:23 localhost mdkapplet[16332]: running: urpmi.update --update Jul 25 21:48:39 localhost mdkapplet[16332]: updating inactive backport media Main Backports (Official2010.1-4), Contrib Backports (Official2010.1-12), Non-free Backports (Official2010.1-20), PLF Free backports, PLF Non-free backports Jul 25 21:48:39 localhost mdkapplet[16332]: running: urpmi.update Main Backports (Official2010.1-4) Jul 25 21:48:46 localhost mdkapplet[16332]: running: urpmi.update Contrib Backports (Official2010.1-12) Jul 25 21:48:48 localhost mdkapplet[16332]: running: urpmi.update Non-free Backports (Official2010.1-20) Jul 25 21:48:51 localhost mdkapplet[16332]: running: urpmi.update PLF Free backports Jul 25 21:48:55 localhost mdkapplet[16332]: running: urpmi.update PLF Non-free backports Jul 25 21:48:57 localhost pulseaudio[26721]: (7440.932| 71.318) client.c: Created 44 "Native client (UNIX socket client)" Jul 25 21:48:57 localhost pulseaudio[26721]: (7440.932| 0.000) protocol-native.c: Protocol version: remote 16, local 16 Jul 25 21:48:57 localhost pulseaudio[26721]: (7440.932| 0.000) protocol-native.c: Got credentials: uid=500 gid=500 success=1 Jul 25 21:48:57 localhost pulseaudio[26721]: (7440.932| 0.000) protocol-native.c: SHM possible: yes Jul 25 21:48:57 localhost pulseaudio[26721]: (7440.932| 0.000) protocol-native.c: Negotiated SHM: yes Jul 25 21:48:57 localhost pulseaudio[26721]: (7440.934| 0.001) module-augment-properties.c: Looking for .desktop file for firefox Jul 25 21:49:19 localhost pulseaudio[26721]: (7462.497| 21.563) asyncq.c: q overrun, queuing locally Jul 25 21:49:19 localhost pulseaudio[26721]: (7462.577| 0.080) asyncq.c: q overrun, queuing locally Jul 25 21:49:19 localhost pulseaudio[26721]: (7462.577| 0.000) asyncq.c: q overrun, queuing locally Jul 25 21:49:19 localhost pulseaudio[26721]: (7462.657| 0.079) asyncq.c: q overrun, queuing locally Jul 25 21:49:19 localhost pulseaudio[26721]: (7462.737| 0.080) asyncq.c: q overrun, queuing locally Jul 25 21:49:19 localhost pulseaudio[26721]: (7462.737| 0.000) asyncq.c: q overrun, queuing locally Jul 25 21:49:19 localhost pulseaudio[26721]: (7462.737| 0.000) asyncq.c: q overrun, queuing locally Jul 25 21:49:19 localhost pulseaudio[26721]: (7462.737| 0.000) asyncq.c: q overrun, queuing locally Jul 25 21:49:19 localhost pulseaudio[26721]: (7462.817| 0.079) asyncq.c: q overrun, queuing locally Jul 25 21:49:19 localhost pulseaudio[26721]: (7462.817| 0.000) asyncq.c: q overrun, queuing locally Jul 25 21:49:19 localhost pulseaudio[26721]: (7462.897| 0.079) asyncq.c: q overrun, queuing locally Jul 25 21:49:51 localhost mdkapplet[16332]: Packages are up to date
you should ask PA developer to add code to debug since this is a queue used by PA and has no relationship with alsa ,
alsa-sink and alsa-source can only post PA_CORE_MESSAGE_UNLOAD_MODULE
modules/alsa/alsa-sink.c: pa_asyncmsgq_post(u->thread_mq.outq, PA_MSGOBJECT(u->core), PA_CORE_MESSAGE_UNLOAD_MODULE, u->module, 0, NULL, NULL); modules/alsa/alsa-source.c: pa_asyncmsgq_post(u->thread_mq.outq, PA_MSGOBJECT(u->core), PA_CORE_MESSAGE_UNLOAD_MODULE, u->module, 0, NULL, NULL);
and you have to copy definition of struct asyncmsgq_item from asyncmsgq.c
void pa_asyncq_post(pa_asyncq*l, void *p) { struct localq *q;
struct asyncmsgq_item *i;
pa_assert(l); pa_assert(p);
i=( struct asyncmsgq_item *)p;
if (flush_postq(l, FALSE)) if (pa_asyncq_push(l, p, FALSE) >= 0) return;
/* OK, we couldn't push anything in the queue. So let's queue it
- locally and push it later */
if (pa_log_ratelimit())
pa_log_warn("q overrun, queuing locally");
pa_log_warn("q overrun, queuing locally code %d",i->code);
you have to find out why this fail to return
flush_postq() return false or pa_asyncq_push() return negative number
if (flush_postq(l, FALSE)) if (pa_asyncq_push(l, p, FALSE) >= 0) return;
'Twas brillig, and Raymond Yau at 26/07/10 05:21 did gyre and gimble:
2010/7/26 Raymond Yau superquad.vortex2@gmail.com
2010/7/26 Chris cpollock@embarqmail.com
On Mon, 2010-07-26 at 09:45 +0800, Raymond Yau wrote:
2010/7/26 Chris cpollock@embarqmail.com
On Mon, 2010-07-26 at 07:31 +0800, Raymond Yau wrote:
2010/7/26 Chris cpollock@embarqmail.com
> Raymond, attached is a post I made today to the pulseaudio list. > > From: Chris cpollock@embarqmail.com > To: pulseaudio-discuss@mail.0pointer.de > Date: Sun, 25 Jul 2010 12:15:02 -0500 > Subject: Re: [pulseaudio-discuss] pulseaudio debug mode > On Fri, 2010-07-23 at 08:58 +0100, Colin Guthrie wrote: >> 'Twas brillig, and Chris at 23/07/10 02:04 did gyre and gimble: >>> What is the best way to start PA for debugging and still have
all
the
>>> usual clients running? >> >> If you mean having all the clients connect (e.g. applications
with
>> libcanberra support or similar for sound events), then there are >> basically two ways. >> >> The first is as Luke suggests. These clients will automatically >> reconnect to PA if they need to (provided you have a vaguely
recent
>> libcanberra), after it is restarted and run in debug mode. >> >> Alternatively you can simply set debug-level to "debug" in
daemon.conf
>> (in /etc/pulse or ~/.pulse), and then "grep pulseaudio
/var/log/messages"
>> >> Col >> > > Colin, link below is for debug output also some other output.
Anything
> look out of place that would cause the overruns? > > http://pastebin.com/ZWSWmXZt > -- >
Most likely you will need to set debug-level to "debug" in
daemon.conf
logout and login , and check the /var/log/messages
I suspect it occur after PA server abort and auto spawn , so please
don't
just post the PA log starting from "asyncq overrun" , you need to
post
from
the last two PA startup sequence before the error occur since we
need to
know why PA auto spawn
Is this what you mean Raymond: http://pastebin.com/4RT7YaG6
No, you don't have "asyncq overrun" error in these log
if you had change the "debug-level", the log still keep in
/var/log/messages
The PA client which can connected to PA server before the PA server
start
the playing thread is the PA client which autospawn the PA server
The log level has been set to debug all day
### Read from configuration file: /home/chris/.pulse//daemon.conf ### daemonize = no fail = yes high-priority = yes nice-level = -11 realtime-scheduling = yes realtime-priority = 5 allow-module-loading = yes allow-exit = yes use-pid-file = yes system-instance = no cpu-limit = no enable-shm = yes flat-volumes = yes lock-memory = no exit-idle-time = 20 scache-idle-time = 20 dl-search-path = /usr/lib/pulse-0.9.21/modules default-script-file = /etc/pulse/default.pa load-default-script-file = yes log-target = auto log-level = debug resample-method = speex-float-0 enable-remixing = yes enable-lfe-remixing = no default-sample-format = s16le default-sample-rate = 44100 default-sample-channels = 2 default-channel-map = front-left,front-right default-fragments = 4 default-fragment-size-msec = 25 shm-size-bytes = 0 log-meta = no log-time = yes log-backtrace = 0 rlimit-fsize = -1 rlimit-data = -1 rlimit-stack = -1 rlimit-core = -1 rlimit-rss = -1 rlimit-as = -1 rlimit-nproc = -1 rlimit-nofile = 256 rlimit-memlock = -1 rlimit-locks = -1 rlimit-sigpending = -1 rlimit-msgqueue = -1 rlimit-nice = 31 rlimit-rtprio = 9 rlimit-rttime = 1000000
The is what happens after a fresh log-in and Mandrive update is running and I also start Firefox:
Jul 25 21:48:22 localhost mdkapplet[16332]: Computing new updates... Jul 25 21:48:23 localhost mdkapplet[16332]: running: urpmi.update --update Jul 25 21:48:39 localhost mdkapplet[16332]: updating inactive backport media Main Backports (Official2010.1-4), Contrib Backports (Official2010.1-12), Non-free Backports (Official2010.1-20), PLF Free backports, PLF Non-free backports Jul 25 21:48:39 localhost mdkapplet[16332]: running: urpmi.update Main Backports (Official2010.1-4) Jul 25 21:48:46 localhost mdkapplet[16332]: running: urpmi.update Contrib Backports (Official2010.1-12) Jul 25 21:48:48 localhost mdkapplet[16332]: running: urpmi.update Non-free Backports (Official2010.1-20) Jul 25 21:48:51 localhost mdkapplet[16332]: running: urpmi.update PLF Free backports Jul 25 21:48:55 localhost mdkapplet[16332]: running: urpmi.update PLF Non-free backports Jul 25 21:48:57 localhost pulseaudio[26721]: (7440.932| 71.318) client.c: Created 44 "Native client (UNIX socket client)" Jul 25 21:48:57 localhost pulseaudio[26721]: (7440.932| 0.000) protocol-native.c: Protocol version: remote 16, local 16 Jul 25 21:48:57 localhost pulseaudio[26721]: (7440.932| 0.000) protocol-native.c: Got credentials: uid=500 gid=500 success=1 Jul 25 21:48:57 localhost pulseaudio[26721]: (7440.932| 0.000) protocol-native.c: SHM possible: yes Jul 25 21:48:57 localhost pulseaudio[26721]: (7440.932| 0.000) protocol-native.c: Negotiated SHM: yes Jul 25 21:48:57 localhost pulseaudio[26721]: (7440.934| 0.001) module-augment-properties.c: Looking for .desktop file for firefox Jul 25 21:49:19 localhost pulseaudio[26721]: (7462.497| 21.563) asyncq.c: q overrun, queuing locally Jul 25 21:49:19 localhost pulseaudio[26721]: (7462.577| 0.080) asyncq.c: q overrun, queuing locally Jul 25 21:49:19 localhost pulseaudio[26721]: (7462.577| 0.000) asyncq.c: q overrun, queuing locally Jul 25 21:49:19 localhost pulseaudio[26721]: (7462.657| 0.079) asyncq.c: q overrun, queuing locally Jul 25 21:49:19 localhost pulseaudio[26721]: (7462.737| 0.080) asyncq.c: q overrun, queuing locally Jul 25 21:49:19 localhost pulseaudio[26721]: (7462.737| 0.000) asyncq.c: q overrun, queuing locally Jul 25 21:49:19 localhost pulseaudio[26721]: (7462.737| 0.000) asyncq.c: q overrun, queuing locally Jul 25 21:49:19 localhost pulseaudio[26721]: (7462.737| 0.000) asyncq.c: q overrun, queuing locally Jul 25 21:49:19 localhost pulseaudio[26721]: (7462.817| 0.079) asyncq.c: q overrun, queuing locally Jul 25 21:49:19 localhost pulseaudio[26721]: (7462.817| 0.000) asyncq.c: q overrun, queuing locally Jul 25 21:49:19 localhost pulseaudio[26721]: (7462.897| 0.079) asyncq.c: q overrun, queuing locally Jul 25 21:49:51 localhost mdkapplet[16332]: Packages are up to date
you should ask PA developer to add code to debug since this is a queue used by PA and has no relationship with alsa ,
alsa-sink and alsa-source can only post PA_CORE_MESSAGE_UNLOAD_MODULE
modules/alsa/alsa-sink.c: pa_asyncmsgq_post(u->thread_mq.outq, PA_MSGOBJECT(u->core), PA_CORE_MESSAGE_UNLOAD_MODULE, u->module, 0, NULL, NULL); modules/alsa/alsa-source.c: pa_asyncmsgq_post(u->thread_mq.outq, PA_MSGOBJECT(u->core), PA_CORE_MESSAGE_UNLOAD_MODULE, u->module, 0, NULL, NULL);
and you have to copy definition of struct asyncmsgq_item from asyncmsgq.c
void pa_asyncq_post(pa_asyncq*l, void *p) { struct localq *q;
struct asyncmsgq_item *i;
pa_assert(l); pa_assert(p);
i=( struct asyncmsgq_item *)p;
if (flush_postq(l, FALSE)) if (pa_asyncq_push(l, p, FALSE) >= 0) return;
/* OK, we couldn't push anything in the queue. So let's queue it
- locally and push it later */
if (pa_log_ratelimit())
pa_log_warn("q overrun, queuing locally");
pa_log_warn("q overrun, queuing locally code %d",i->code);you have to find out why this fail to return
flush_postq() return false or pa_asyncq_push() return negative number
if (flush_postq(l, FALSE)) if (pa_asyncq_push(l, p, FALSE) >= 0) return;
I can add this kind of debug to a package for you Chris if you like. I'm not 100% sure what info it will find out though....
What arch are you using i586 or x86_64?
Col
2010/7/26 Colin Guthrie gmane@colin.guthr.ie
'Twas brillig, and Raymond Yau at 26/07/10 05:21 did gyre and gimble:
2010/7/26 Raymond Yau superquad.vortex2@gmail.com
2010/7/26 Chris cpollock@embarqmail.com
On Mon, 2010-07-26 at 09:45 +0800, Raymond Yau wrote:
2010/7/26 Chris cpollock@embarqmail.com
On Mon, 2010-07-26 at 07:31 +0800, Raymond Yau wrote: > 2010/7/26 Chris cpollock@embarqmail.com > >> Raymond, attached is a post I made today to the pulseaudio list. >> >> From: Chris cpollock@embarqmail.com >> To: pulseaudio-discuss@mail.0pointer.de >> Date: Sun, 25 Jul 2010 12:15:02 -0500 >> Subject: Re: [pulseaudio-discuss] pulseaudio debug mode >> On Fri, 2010-07-23 at 08:58 +0100, Colin Guthrie wrote: >>> 'Twas brillig, and Chris at 23/07/10 02:04 did gyre and gimble: >>>> What is the best way to start PA for debugging and still have
all
the >>>> usual clients running? >>> >>> If you mean having all the clients connect (e.g. applications
with
>>> libcanberra support or similar for sound events), then there are >>> basically two ways. >>> >>> The first is as Luke suggests. These clients will automatically >>> reconnect to PA if they need to (provided you have a vaguely
recent
>>> libcanberra), after it is restarted and run in debug mode. >>> >>> Alternatively you can simply set debug-level to "debug" in daemon.conf >>> (in /etc/pulse or ~/.pulse), and then "grep pulseaudio /var/log/messages" >>> >>> Col >>> >> >> Colin, link below is for debug output also some other output.
Anything
>> look out of place that would cause the overruns? >> >> http://pastebin.com/ZWSWmXZt >> -- >> > > Most likely you will need to set debug-level to "debug" in
daemon.conf
> logout and login , and check the /var/log/messages > > I suspect it occur after PA server abort and auto spawn , so please
don't
> just post the PA log starting from "asyncq overrun" , you need to
post
from > the last two PA startup sequence before the error occur since we
need to
> know why PA auto spawn
Is this what you mean Raymond: http://pastebin.com/4RT7YaG6
No, you don't have "asyncq overrun" error in these log
if you had change the "debug-level", the log still keep in
/var/log/messages
The PA client which can connected to PA server before the PA server
start
the playing thread is the PA client which autospawn the PA server
The log level has been set to debug all day
### Read from configuration file: /home/chris/.pulse//daemon.conf ### daemonize = no fail = yes high-priority = yes nice-level = -11 realtime-scheduling = yes realtime-priority = 5 allow-module-loading = yes allow-exit = yes use-pid-file = yes system-instance = no cpu-limit = no enable-shm = yes flat-volumes = yes lock-memory = no exit-idle-time = 20 scache-idle-time = 20 dl-search-path = /usr/lib/pulse-0.9.21/modules default-script-file = /etc/pulse/default.pa load-default-script-file = yes log-target = auto log-level = debug resample-method = speex-float-0 enable-remixing = yes enable-lfe-remixing = no default-sample-format = s16le default-sample-rate = 44100 default-sample-channels = 2 default-channel-map = front-left,front-right default-fragments = 4 default-fragment-size-msec = 25 shm-size-bytes = 0 log-meta = no log-time = yes log-backtrace = 0 rlimit-fsize = -1 rlimit-data = -1 rlimit-stack = -1 rlimit-core = -1 rlimit-rss = -1 rlimit-as = -1 rlimit-nproc = -1 rlimit-nofile = 256 rlimit-memlock = -1 rlimit-locks = -1 rlimit-sigpending = -1 rlimit-msgqueue = -1 rlimit-nice = 31 rlimit-rtprio = 9 rlimit-rttime = 1000000
The is what happens after a fresh log-in and Mandrive update is running and I also start Firefox:
Jul 25 21:48:22 localhost mdkapplet[16332]: Computing new updates... Jul 25 21:48:23 localhost mdkapplet[16332]: running: urpmi.update --update Jul 25 21:48:39 localhost mdkapplet[16332]: updating inactive backport media Main Backports (Official2010.1-4), Contrib Backports (Official2010.1-12), Non-free Backports (Official2010.1-20), PLF Free backports, PLF Non-free backports Jul 25 21:48:39 localhost mdkapplet[16332]: running: urpmi.update Main Backports (Official2010.1-4) Jul 25 21:48:46 localhost mdkapplet[16332]: running: urpmi.update Contrib Backports (Official2010.1-12) Jul 25 21:48:48 localhost mdkapplet[16332]: running: urpmi.update Non-free Backports (Official2010.1-20) Jul 25 21:48:51 localhost mdkapplet[16332]: running: urpmi.update PLF Free backports Jul 25 21:48:55 localhost mdkapplet[16332]: running: urpmi.update PLF Non-free backports Jul 25 21:48:57 localhost pulseaudio[26721]: (7440.932| 71.318) client.c: Created 44 "Native client (UNIX socket client)" Jul 25 21:48:57 localhost pulseaudio[26721]: (7440.932| 0.000) protocol-native.c: Protocol version: remote 16, local 16 Jul 25 21:48:57 localhost pulseaudio[26721]: (7440.932| 0.000) protocol-native.c: Got credentials: uid=500 gid=500 success=1 Jul 25 21:48:57 localhost pulseaudio[26721]: (7440.932| 0.000) protocol-native.c: SHM possible: yes Jul 25 21:48:57 localhost pulseaudio[26721]: (7440.932| 0.000) protocol-native.c: Negotiated SHM: yes Jul 25 21:48:57 localhost pulseaudio[26721]: (7440.934| 0.001) module-augment-properties.c: Looking for .desktop file for firefox Jul 25 21:49:19 localhost pulseaudio[26721]: (7462.497| 21.563) asyncq.c: q overrun, queuing locally Jul 25 21:49:19 localhost pulseaudio[26721]: (7462.577| 0.080) asyncq.c: q overrun, queuing locally Jul 25 21:49:19 localhost pulseaudio[26721]: (7462.577| 0.000) asyncq.c: q overrun, queuing locally Jul 25 21:49:19 localhost pulseaudio[26721]: (7462.657| 0.079) asyncq.c: q overrun, queuing locally Jul 25 21:49:19 localhost pulseaudio[26721]: (7462.737| 0.080) asyncq.c: q overrun, queuing locally Jul 25 21:49:19 localhost pulseaudio[26721]: (7462.737| 0.000) asyncq.c: q overrun, queuing locally Jul 25 21:49:19 localhost pulseaudio[26721]: (7462.737| 0.000) asyncq.c: q overrun, queuing locally Jul 25 21:49:19 localhost pulseaudio[26721]: (7462.737| 0.000) asyncq.c: q overrun, queuing locally Jul 25 21:49:19 localhost pulseaudio[26721]: (7462.817| 0.079) asyncq.c: q overrun, queuing locally Jul 25 21:49:19 localhost pulseaudio[26721]: (7462.817| 0.000) asyncq.c: q overrun, queuing locally Jul 25 21:49:19 localhost pulseaudio[26721]: (7462.897| 0.079) asyncq.c: q overrun, queuing locally Jul 25 21:49:51 localhost mdkapplet[16332]: Packages are up to date
you should ask PA developer to add code to debug since this is a queue
used
by PA and has no relationship with alsa ,
alsa-sink and alsa-source can only post PA_CORE_MESSAGE_UNLOAD_MODULE
modules/alsa/alsa-sink.c: pa_asyncmsgq_post(u->thread_mq.outq, PA_MSGOBJECT(u->core), PA_CORE_MESSAGE_UNLOAD_MODULE, u->module, 0,
NULL,
NULL); modules/alsa/alsa-source.c: pa_asyncmsgq_post(u->thread_mq.outq, PA_MSGOBJECT(u->core), PA_CORE_MESSAGE_UNLOAD_MODULE, u->module, 0,
NULL,
NULL);
and you have to copy definition of struct asyncmsgq_item from
asyncmsgq.c
void pa_asyncq_post(pa_asyncq*l, void *p) { struct localq *q;
struct asyncmsgq_item *i;
pa_assert(l); pa_assert(p);
i=( struct asyncmsgq_item *)p;
if (flush_postq(l, FALSE)) if (pa_asyncq_push(l, p, FALSE) >= 0) return;
/* OK, we couldn't push anything in the queue. So let's queue it
- locally and push it later */
if (pa_log_ratelimit())
pa_log_warn("q overrun, queuing locally");
pa_log_warn("q overrun, queuing locally code %d",i->code);you have to find out why this fail to return
flush_postq() return false or pa_asyncq_push() return negative number
if (flush_postq(l, FALSE)) if (pa_asyncq_push(l, p, FALSE) >= 0) return;I can add this kind of debug to a package for you Chris if you like. I'm not 100% sure what info it will find out though....
What arch are you using i586 or x86_64?
Col
You have to ask the author since adding pa_log_limit() does not fixed the error message flooding the system log
You will need to know which queue was overrun ? which kind of message (code) cause the queue overrun ?
in theory, pa_asyncq_push() should return positive number in normal condition
some of them seem defined in protocol-native.c and you can use 'grep -ir "pa_asyncmsgq_post" * ' used by which programs
On Mon, 2010-07-26 at 10:29 +0100, Colin Guthrie wrote:
'Twas brillig, and Raymond Yau at 26/07/10 05:21 did gyre and gimble:
2010/7/26 Raymond Yau superquad.vortex2@gmail.com
if (flush_postq(l, FALSE)) if (pa_asyncq_push(l, p, FALSE) >= 0) return;I can add this kind of debug to a package for you Chris if you like. I'm not 100% sure what info it will find out though....
What arch are you using i586 or x86_64?
Col
Using i586 Colin, however, it wouldn't do any good for me since to be honest I have no idea what I'm looking at anyway. And Raymond, for your question about did PA get stopped during it's update, PA did not get updated, all that was happening was that the Mandriva update applet was checking to see if there were any software updates. Just a small snip below of what was going on when MSEC was running this morning.
Jul 26 04:07:31 localhost postfix/qmgr[5447]: 9792932E8FF: removed Jul 26 04:08:57 localhost pulseaudio[26721]: (30240.557| 945.629) ratelimit.c: 59 events suppressed Jul 26 04:08:57 localhost pulseaudio[26721]: (30240.674| 0.116) alsa-sink.c: Underrun! Jul 26 04:08:57 localhost pulseaudio[26721]: (30240.675| 0.001) alsa-sink.c: Increasing wakeup watermark to 110.02 ms Jul 26 04:08:58 localhost pulseaudio[26721]: (30241.305| 0.629) alsa-sink.c: Underrun! Jul 26 04:08:58 localhost pulseaudio[26721]: (30241.305| 0.000) alsa-sink.c: Increasing wakeup watermark to 120.02 ms Jul 26 04:09:00 localhost pulseaudio[26721]: (30243.974| 2.668) alsa-sink.c: Underrun! Jul 26 04:09:00 localhost pulseaudio[26721]: (30243.974| 0.000) alsa-sink.c: Increasing wakeup watermark to 130.02 ms Jul 26 04:09:03 localhost pulseaudio[26721]: (30246.449| 2.475) asyncq.c: q overrun, queuing locally
Jul 26 04:09:03 localhost pulseaudio[26721]: (30246.549| 0.000) asyncq.c: q overrun, queuing locally Jul 26 04:09:08 localhost pulseaudio[26721]: (30251.453| 4.903) ratelimit.c: 506 events suppressed Jul 26 04:09:08 localhost pulseaudio[26721]: (30251.453| 0.000) asyncq.c: q overrun, queuing locally
Jul 26 04:09:20 localhost pulseaudio[26721]: (30264.021| 2.463) alsa-sink.c: Decreasing wakeup watermark to 125.03 ms Jul 26 04:09:23 localhost pulseaudio[26721]: (30266.494| 2.472) ratelimit.c: 465 events suppressed Jul 26 04:09:23 localhost pulseaudio[26721]: (30266.494| 0.000) asyncq.c: q overrun, queuing locally Jul 26 04:09:23 localhost pulseaudio[26721]: (30266.494| 0.000) asyncq.c: q overrun, queuing locally Jul 26 04:09:23 localhost pulseaudio[26721]: (30266.494| 0.000) memblock.c: Pool full
Jul 26 04:10:02 localhost pulseaudio[26721]: (30305.200| 3.552) alsa-sink.c: Decreasing wakeup watermark to 120.05 ms Jul 26 04:10:03 localhost pulseaudio[26721]: (30306.577| 1.376) ratelimit.c: 593 events suppressed Jul 26 04:10:03 localhost pulseaudio[26721]: (30306.577| 0.000) asyncq.c: q overrun, queuing locally
Jul 26 04:10:07 localhost pulseaudio[26721]: (30311.019| 4.382) alsa-sink.c: Increasing wakeup watermark to 130.05 ms Jul 26 04:10:11 localhost pulseaudio[26721]: (30314.446| 3.426) ratelimit.c: 368 events suppressed Jul 26 04:10:11 localhost pulseaudio[26721]: (30314.446| 0.000) asyncq.c: q overrun, queuing locally
Jul 26 04:10:13 localhost pulseaudio[26721]: (30316.718| 2.172) alsa-sink.c: Increasing wakeup watermark to 140.00 ms Jul 26 04:10:15 localhost clamd[21295]: Reading databases from /var/lib/clamav Jul 26 04:10:15 localhost pulseaudio[26721]: (30318.448| 1.729) alsa-sink.c: Increasing minimal latency to 1.00 ms
Jul 26 04:10:35 localhost pulseaudio[26721]: (30338.504| 20.014) alsa-sink.c: Decreasing wakeup watermark to 135.01 ms Jul 26 04:10:40 localhost clamd[21295]: Database correctly reloaded (1136734 signatures) Jul 26 04:10:55 localhost pulseaudio[26721]: (30358.517| 20.013) alsa-sink.c: Decreasing wakeup watermark to 130.02 ms Jul 26 04:11:15 localhost pulseaudio[26721]: (30378.535| 20.017) alsa-sink.c: Decreasing wakeup watermark to 125.03 ms Jul 26 04:11:16 localhost pulseaudio[26721]: (30379.598| 1.063) ratelimit.c: 76 events suppressed Jul 26 04:11:16 localhost pulseaudio[26721]: (30379.598| 0.000) alsa-sink.c: Underrun! Jul 26 04:11:16 localhost pulseaudio[26721]: (30379.598| 0.000) alsa-sink.c: Increasing wakeup watermark to 135.03 ms Jul 26 04:11:37 localhost pulseaudio[26721]: (30400.820| 21.222) alsa-sink.c: Decreasing wakeup watermark to 130.05 ms Jul 26 04:11:57 localhost pulseaudio[26721]: (30420.826| 20.005) alsa-sink.c: Decreasing wakeup watermark to 125.06 ms Jul 26 04:12:17 localhost pulseaudio[26721]: (30440.826| 20.000) alsa-sink.c: Decreasing wakeup watermark to 120.07 ms Jul 26 04:12:37 localhost pulseaudio[26721]: (30460.845| 20.019) alsa-sink.c: Decreasing wakeup watermark to 115.08 ms Jul 26 04:12:57 localhost pulseaudio[26721]: (30480.879| 20.033) alsa-sink.c: Decreasing wakeup watermark to 110.09 ms Jul 26 04:13:17 localhost pulseaudio[26721]: (30500.909| 20.030) alsa-sink.c: Decreasing wakeup watermark to 105.10 ms Jul 26 04:13:17 localhost pulseaudio[26721]: (30501.130| 0.220) asyncq.c: q overrun, queuing locally
participants (3)
-
Chris -
Colin Guthrie -
Raymond Yau