Re: [alsa-devel] Which project to choose?
2010/7/14 Chris cpollock@embarqmail.com
On Wed, 2010-07-14 at 10:09 +0800, Raymond Yau wrote:
> You need to provide a full pulseaudio log and a test case which can > reproduce your problem > > open a new terminal > > pulseaudio -k ; pulseaudio -vvvvv Where should I post this Raymond?AFAIK , this mailing list has a limit of the message size
BTW ,
did the program abort when you run alsa-time-test and pipe the output to "tail -n 500"
http://thread.gmane.org/gmane.linux.alsa.devel/60371/focus=60520
Beware that the program generate a log of output
Raymond, I've ran bzip2 on the output of pulseaudio -k ; pulseaudio -vvvvv and it went from 129k to 9k. Should I fwd to you or post on the list?
--
appl_ptr is also behind the hw_ptr in 0.9.21-0.1mdv2010.0
https://qa.mandriva.com/show_bug.cgi?id=56473#c15
Apr 12 15:21:43 localhost pulseaudio[13701]: alsa-util.c: appl_ptr :
28465776 Apr 12 15:21:43 localhost pulseaudio[13701]: alsa-util.c: hw_ptr : 28555040
and also appl_ptr is also behind the hw_ptr for snd_via82xx
https://qa.mandriva.com/show_bug.cgi?id=56473#c0
Dec 14 20:26:29 localhost pulseaudio[4331]: alsa-util.c: appl_ptr : 767919576 Dec 14 20:26:29 localhost pulseaudio[4331]: alsa-util.c: hw_ptr : 767990616
On Wed, 2010-07-14 at 20:23 +0800, Raymond Yau wrote:
2010/7/14 Chris cpollock@embarqmail.com
On Wed, 2010-07-14 at 10:09 +0800, Raymond Yau wrote:
> You need to provide a full pulseaudio log and a test case which can > reproduce your problem > > open a new terminal > > pulseaudio -k ; pulseaudio -vvvvv Where should I post this Raymond?AFAIK , this mailing list has a limit of the message size
BTW ,
did the program abort when you run alsa-time-test and pipe the output to "tail -n 500"
http://thread.gmane.org/gmane.linux.alsa.devel/60371/focus=60520
Beware that the program generate a log of output
Raymond, I've ran bzip2 on the output of pulseaudio -k ; pulseaudio -vvvvv and it went from 129k to 9k. Should I fwd to you or post on the list?
--
appl_ptr is also behind the hw_ptr in 0.9.21-0.1mdv2010.0
https://qa.mandriva.com/show_bug.cgi?id=56473#c15
Apr 12 15:21:43 localhost pulseaudio[13701]: alsa-util.c: appl_ptr :
28465776 Apr 12 15:21:43 localhost pulseaudio[13701]: alsa-util.c: hw_ptr : 28555040
and also appl_ptr is also behind the hw_ptr for snd_via82xx
https://qa.mandriva.com/show_bug.cgi?id=56473#c0
Dec 14 20:26:29 localhost pulseaudio[4331]: alsa-util.c: appl_ptr : 767919576 Dec 14 20:26:29 localhost pulseaudio[4331]: alsa-util.c: hw_ptr : 767990616
I posted both of those bug reports. Honestly, I just want it to work without all the error output to syslog and thrashing of my HD for minutes at a time. As I said, I've got the output of pulseaudio -vvvvv if anyone would like to look at it and tell me what I need to do to fix the problem.
Chris
2010/7/15 Chris cpollock@embarqmail.com
On Wed, 2010-07-14 at 20:23 +0800, Raymond Yau wrote:
2010/7/14 Chris cpollock@embarqmail.com
On Wed, 2010-07-14 at 10:09 +0800, Raymond Yau wrote:
> You need to provide a full pulseaudio log and a test case which can > reproduce your problem > > open a new terminal > > pulseaudio -k ; pulseaudio -vvvvv Where should I post this Raymond?AFAIK , this mailing list has a limit of the message size
BTW ,
did the program abort when you run alsa-time-test and pipe the
output
to "tail -n 500"
http://thread.gmane.org/gmane.linux.alsa.devel/60371/focus=60520
Beware that the program generate a log of output
Raymond, I've ran bzip2 on the output of pulseaudio -k ; pulseaudio -vvvvv and it went from 129k to 9k. Should I fwd to you or post on the list?
--
appl_ptr is also behind the hw_ptr in 0.9.21-0.1mdv2010.0
https://qa.mandriva.com/show_bug.cgi?id=56473#c15
Apr 12 15:21:43 localhost pulseaudio[13701]: alsa-util.c: appl_ptr :
28465776 Apr 12 15:21:43 localhost pulseaudio[13701]: alsa-util.c: hw_ptr
:
28555040
and also appl_ptr is also behind the hw_ptr for snd_via82xx
https://qa.mandriva.com/show_bug.cgi?id=56473#c0
Dec 14 20:26:29 localhost pulseaudio[4331]: alsa-util.c: appl_ptr : 767919576 Dec 14 20:26:29 localhost pulseaudio[4331]: alsa-util.c: hw_ptr : 767990616
I posted both of those bug reports. Honestly, I just want it to work without all the error output to syslog and thrashing of my HD for minutes at a time. As I said, I've got the output of pulseaudio -vvvvv if anyone would like to look at it and tell me what I need to do to fix the problem.
Chris
Just upload your current pulseaudio.log and output of alsa-info.sh to mandriva 's bugzilla
Cannot obtain any conclusion based on the log which you have posted last year ( xmms)
as Jaroslav Kysela said , need the real system time between I/O operations and you'll see if it's issue in the ALSA driver or a task scheduling problem.
On Thu, 2010-07-15 at 08:08 +0800, Raymond Yau wrote:
I posted both of those bug reports. Honestly, I just want it to work without all the error output to syslog and thrashing of my HD for minutes at a time. As I said, I've got the output of pulseaudio -vvvvv if anyone would like to look at it and tell me what I need to do to fix the problem.
Chris
Just upload your current pulseaudio.log and output of alsa-info.sh to mandriva 's bugzilla
Cannot obtain any conclusion based on the log which you have posted last year ( xmms)
as Jaroslav Kysela said , need the real system time between I/O operations and you'll see if it's issue in the ALSA driver or a task scheduling problem.
Here is the bug report with the outputs uploaded.
https://qa.mandriva.com/show_bug.cgi?id=60169
'Twas brillig, and Chris at 15/07/10 02:38 did gyre and gimble:
On Thu, 2010-07-15 at 08:08 +0800, Raymond Yau wrote:
I posted both of those bug reports. Honestly, I just want it to work without all the error output to syslog and thrashing of my HD for minutes at a time. As I said, I've got the output of pulseaudio -vvvvv if anyone would like to look at it and tell me what I need to do to fix the problem.
Chris
Just upload your current pulseaudio.log and output of alsa-info.sh to mandriva 's bugzilla
Cannot obtain any conclusion based on the log which you have posted last year ( xmms)
as Jaroslav Kysela said , need the real system time between I/O operations and you'll see if it's issue in the ALSA driver or a task scheduling problem.
Here is the bug report with the outputs uploaded.
Well seeing as my process when getting such a bug is to report it here on behalf of the user, I suspect that this has reached a stalemate....
On Thu, 15 Jul 2010, Colin Guthrie wrote:
'Twas brillig, and Chris at 15/07/10 02:38 did gyre and gimble:
On Thu, 2010-07-15 at 08:08 +0800, Raymond Yau wrote:
I posted both of those bug reports. Honestly, I just want it to work without all the error output to syslog and thrashing of my HD for minutes at a time. As I said, I've got the output of pulseaudio -vvvvv if anyone would like to look at it and tell me what I need to do to fix the problem.
Chris
Just upload your current pulseaudio.log and output of alsa-info.sh to mandriva 's bugzilla
Cannot obtain any conclusion based on the log which you have posted last year ( xmms)
as Jaroslav Kysela said , need the real system time between I/O operations and you'll see if it's issue in the ALSA driver or a task scheduling problem.
Here is the bug report with the outputs uploaded.
Well seeing as my process when getting such a bug is to report it here on behalf of the user, I suspect that this has reached a stalemate....
Please, provide also /var/log/messages output for xrun_debug=11 - see http://www.alsa-project.org/main/index.php/XRUN_Debug for more details. We can detect the ALSA ring buffer issues in this way, too.
Jaroslav
----- Jaroslav Kysela perex@perex.cz Linux Kernel Sound Maintainer ALSA Project, Red Hat, Inc.
On Thu, 2010-07-15 at 16:07 +0200, Jaroslav Kysela wrote:
On Thu, 15 Jul 2010, Colin Guthrie wrote:
'Twas brillig, and Chris at 15/07/10 02:38 did gyre and gimble:
On Thu, 2010-07-15 at 08:08 +0800, Raymond Yau wrote:
I posted both of those bug reports. Honestly, I just want it to work without all the error output to syslog and thrashing of my HD for minutes at a time. As I said, I've got the output of pulseaudio -vvvvv if anyone would like to look at it and tell me what I need to do to fix the problem.
Chris
Just upload your current pulseaudio.log and output of alsa-info.sh to mandriva 's bugzilla
Cannot obtain any conclusion based on the log which you have posted last year ( xmms)
as Jaroslav Kysela said , need the real system time between I/O operations and you'll see if it's issue in the ALSA driver or a task scheduling problem.
Here is the bug report with the outputs uploaded.
Well seeing as my process when getting such a bug is to report it here on behalf of the user, I suspect that this has reached a stalemate....
Please, provide also /var/log/messages output for xrun_debug=11 - see http://www.alsa-project.org/main/index.php/XRUN_Debug for more details. We can detect the ALSA ring buffer issues in this way, too.
Jaroslav
See pastebin file http://pastebin.com/MdENbSNd Hopefully I did this correctly.
2010/7/16 Chris cpollock@embarqmail.com
On Thu, 2010-07-15 at 16:07 +0200, Jaroslav Kysela wrote:
On Thu, 15 Jul 2010, Colin Guthrie wrote:
'Twas brillig, and Chris at 15/07/10 02:38 did gyre and gimble:
On Thu, 2010-07-15 at 08:08 +0800, Raymond Yau wrote:
I posted both of those bug reports. Honestly, I just want it to work without all the error output to syslog and thrashing of my HD for minutes at a time. As I said, I've got the output of pulseaudio
-vvvvv
if anyone would like to look at it and tell me what I need to do to
fix
the problem.
Chris
Just upload your current pulseaudio.log and output of alsa-info.sh to mandriva 's bugzilla
Cannot obtain any conclusion based on the log which you have posted
last
year ( xmms)
as Jaroslav Kysela said , need the real system time between I/O
operations
and you'll see if it's issue in the ALSA driver or a task scheduling problem.
Here is the bug report with the outputs uploaded.
Well seeing as my process when getting such a bug is to report it here on behalf of the user, I suspect that this has reached a stalemate....
Please, provide also /var/log/messages output for xrun_debug=11 - see http://www.alsa-project.org/main/index.php/XRUN_Debug for more details.
We
can detect the ALSA ring buffer issues in this way, too.
JaroslavSee pastebin file http://pastebin.com/MdENbSNd Hopefully I did this correctly.
You have to provide the PA server log since we just want to know how PA server handle the underrun condition when the PA client use small buffer size
Did "aplay -Dhw:0,0 --buffer-size=128 any.wav" get underrun ?
On Fri, 2010-07-16 at 07:15 +0800, Raymond Yau wrote:
2010/7/16 Chris cpollock@embarqmail.com
On Thu, 2010-07-15 at 16:07 +0200, Jaroslav Kysela wrote:
On Thu, 15 Jul 2010, Colin Guthrie wrote:
'Twas brillig, and Chris at 15/07/10 02:38 did gyre and gimble:
On Thu, 2010-07-15 at 08:08 +0800, Raymond Yau wrote:
> I posted both of those bug reports. Honestly, I just want it to work > without all the error output to syslog and thrashing of my HD for > minutes at a time. As I said, I've got the output of pulseaudio
-vvvvv
> if anyone would like to look at it and tell me what I need to do to
fix
> the problem. > > Chris > > > Just upload your current pulseaudio.log and output of alsa-info.sh to mandriva 's bugzilla
Cannot obtain any conclusion based on the log which you have posted
last
year ( xmms)
as Jaroslav Kysela said , need the real system time between I/O
operations
and you'll see if it's issue in the ALSA driver or a task scheduling problem.
Here is the bug report with the outputs uploaded.
Well seeing as my process when getting such a bug is to report it here on behalf of the user, I suspect that this has reached a stalemate....
Please, provide also /var/log/messages output for xrun_debug=11 - see http://www.alsa-project.org/main/index.php/XRUN_Debug for more details.
We
can detect the ALSA ring buffer issues in this way, too.
JaroslavSee pastebin file http://pastebin.com/MdENbSNd Hopefully I did this correctly.
You have to provide the PA server log since we just want to know how PA server handle the underrun condition when the PA client use small buffer size
Did "aplay -Dhw:0,0 --buffer-size=128 any.wav" get underrun
I'll check, how the heck to I stop xrun_debug from running???
On Thu, 15 Jul 2010, Chris wrote:
On Fri, 2010-07-16 at 07:15 +0800, Raymond Yau wrote:
2010/7/16 Chris cpollock@embarqmail.com
On Thu, 2010-07-15 at 16:07 +0200, Jaroslav Kysela wrote:
On Thu, 15 Jul 2010, Colin Guthrie wrote:
'Twas brillig, and Chris at 15/07/10 02:38 did gyre and gimble:
On Thu, 2010-07-15 at 08:08 +0800, Raymond Yau wrote:
>> I posted both of those bug reports. Honestly, I just want it to work >> without all the error output to syslog and thrashing of my HD for >> minutes at a time. As I said, I've got the output of pulseaudio
-vvvvv
>> if anyone would like to look at it and tell me what I need to do to
fix
>> the problem. >> >> Chris >> >> >> > Just upload your current pulseaudio.log and output of alsa-info.sh to > mandriva 's bugzilla > > Cannot obtain any conclusion based on the log which you have posted
last
> year ( xmms) > > as Jaroslav Kysela said , need the real system time between I/O
operations
> and you'll see if it's issue in the ALSA driver or a task scheduling > problem.
Here is the bug report with the outputs uploaded.
Well seeing as my process when getting such a bug is to report it here on behalf of the user, I suspect that this has reached a stalemate....
Please, provide also /var/log/messages output for xrun_debug=11 - see http://www.alsa-project.org/main/index.php/XRUN_Debug for more details.
We
can detect the ALSA ring buffer issues in this way, too.
JaroslavSee pastebin file http://pastebin.com/MdENbSNd Hopefully I did this correctly.
You have to provide the PA server log since we just want to know how PA server handle the underrun condition when the PA client use small buffer size
Did "aplay -Dhw:0,0 --buffer-size=128 any.wav" get underrun
I'll check, how the heck to I stop xrun_debug from running???
Just use value 0 instead 11.
Jaroslav
----- Jaroslav Kysela perex@perex.cz Linux Kernel Sound Maintainer ALSA Project, Red Hat, Inc.
On Fri, 2010-07-16 at 07:15 +0800, Raymond Yau wrote:
2010/7/16 Chris cpollock@embarqmail.com
On Thu, 2010-07-15 at 16:07 +0200, Jaroslav Kysela wrote:
On Thu, 15 Jul 2010, Colin Guthrie wrote:
'Twas brillig, and Chris at 15/07/10 02:38 did gyre and gimble:
On Thu, 2010-07-15 at 08:08 +0800, Raymond Yau wrote:
> I posted both of those bug reports. Honestly, I just want it to work > without all the error output to syslog and thrashing of my HD for > minutes at a time. As I said, I've got the output of pulseaudio
-vvvvv
> if anyone would like to look at it and tell me what I need to do to
fix
> the problem. > > Chris > > > Just upload your current pulseaudio.log and output of alsa-info.sh to mandriva 's bugzilla
Cannot obtain any conclusion based on the log which you have posted
last
year ( xmms)
as Jaroslav Kysela said , need the real system time between I/O
operations
and you'll see if it's issue in the ALSA driver or a task scheduling problem.
Here is the bug report with the outputs uploaded.
Well seeing as my process when getting such a bug is to report it here on behalf of the user, I suspect that this has reached a stalemate....
Please, provide also /var/log/messages output for xrun_debug=11 - see http://www.alsa-project.org/main/index.php/XRUN_Debug for more details.
We
can detect the ALSA ring buffer issues in this way, too.
JaroslavSee pastebin file http://pastebin.com/MdENbSNd Hopefully I did this correctly.
You have to provide the PA server log since we just want to know how PA server handle the underrun condition when the PA client use small buffer size
Did "aplay -Dhw:0,0 --buffer-size=128 any.wav" get underrun ?
[chris@localhost ~]$ aplay -Dhw:0,0 --buffer-size=128 /home/chris/Documents/gotmail.wav aplay: main:654: audio open error: Device or resource busy
Frankly I'm ready to just say the heck with it. I'm totally lost with about 99.9% of what every one is talking about on this thread.
Chris
On Thu, 15 Jul 2010, Chris wrote:
On Thu, 2010-07-15 at 16:07 +0200, Jaroslav Kysela wrote:
On Thu, 15 Jul 2010, Colin Guthrie wrote:
'Twas brillig, and Chris at 15/07/10 02:38 did gyre and gimble:
On Thu, 2010-07-15 at 08:08 +0800, Raymond Yau wrote:
I posted both of those bug reports. Honestly, I just want it to work without all the error output to syslog and thrashing of my HD for minutes at a time. As I said, I've got the output of pulseaudio -vvvvv if anyone would like to look at it and tell me what I need to do to fix the problem.
Chris
Just upload your current pulseaudio.log and output of alsa-info.sh to mandriva 's bugzilla
Cannot obtain any conclusion based on the log which you have posted last year ( xmms)
as Jaroslav Kysela said , need the real system time between I/O operations and you'll see if it's issue in the ALSA driver or a task scheduling problem.
Here is the bug report with the outputs uploaded.
Well seeing as my process when getting such a bug is to report it here on behalf of the user, I suspect that this has reached a stalemate....
Please, provide also /var/log/messages output for xrun_debug=11 - see http://www.alsa-project.org/main/index.php/XRUN_Debug for more details. We can detect the ALSA ring buffer issues in this way, too.
JaroslavSee pastebin file http://pastebin.com/MdENbSNd Hopefully I did this correctly.
Thanks. The hardware ring buffer pointers looks OK so it does not appear like a problem in our ALSA code. I would really consult these problems with PulseAudio developers. Return back, if they say that it's really ALSA issue, not the system scheduler issue.
Note that for your configuration, you have the ring buffer containing only 0.1 second (it means that standard underruns can happen more frequently - usuall symptom is for example moving a window in X GUI).
Jaroslav
----- Jaroslav Kysela perex@perex.cz Linux Kernel Sound Maintainer ALSA Project, Red Hat, Inc.
2010/7/16 Jaroslav Kysela perex@perex.cz
On Thu, 15 Jul 2010, Chris wrote:
On Thu, 2010-07-15 at 16:07 +0200, Jaroslav Kysela wrote:
On Thu, 15 Jul 2010, Colin Guthrie wrote:
'Twas brillig, and Chris at 15/07/10 02:38 did gyre and gimble:
On Thu, 2010-07-15 at 08:08 +0800, Raymond Yau wrote:
> I posted both of those bug reports. Honestly, I just want it to work > without all the error output to syslog and thrashing of my HD for > minutes at a time. As I said, I've got the output of pulseaudio
-vvvvv
> if anyone would like to look at it and tell me what I need to do to
fix
> the problem. > > Chris > > > Just upload your current pulseaudio.log and output of alsa-info.sh to mandriva 's bugzilla
Cannot obtain any conclusion based on the log which you have posted
last
year ( xmms)
as Jaroslav Kysela said , need the real system time between I/O
operations
and you'll see if it's issue in the ALSA driver or a task scheduling problem.
Here is the bug report with the outputs uploaded.
Well seeing as my process when getting such a bug is to report it here on behalf of the user, I suspect that this has reached a stalemate....
Please, provide also /var/log/messages output for xrun_debug=11 - see http://www.alsa-project.org/main/index.php/XRUN_Debug for more details.
We
can detect the ALSA ring buffer issues in this way, too.
JaroslavSee pastebin file http://pastebin.com/MdENbSNd Hopefully I did this correctly.
Thanks. The hardware ring buffer pointers looks OK so it does not appear like a problem in our ALSA code. I would really consult these problems with PulseAudio developers. Return back, if they say that it's really ALSA issue, not the system scheduler issue.
Note that for your configuration, you have the ring buffer containing only 0.1 second (it means that standard underruns can happen more frequently
usuall symptom is for example moving a window in X GUI).
Jaroslav
Refer to the log , the values of pos and hwptr seem multiple of 8
5.5 PCI Data transfer
Only brust read/write transfers are allowed. All data transfer are 8 Long Word brust transfers
This mean that the driver may need to limit the period bytes to be multiple of 8 Long Word since interrupt occur when a cache fill/transfer between the PCI memory and the internal memory.
snd_pcm_hw_constraint_step(runtime, 0, SNDRV_PCM_HW_PARAM_PERIOD_BYTES, 32);
and you may also need to set "rewind_safeguard" in PA too.
http://git.0pointer.de/?p=pulseaudio.git;a=commit;h=4df443bbe682055a41e7c224...
2010/7/15 Colin Guthrie gmane@colin.guthr.ie
'Twas brillig, and Chris at 15/07/10 02:38 did gyre and gimble:
On Thu, 2010-07-15 at 08:08 +0800, Raymond Yau wrote:
I posted both of those bug reports. Honestly, I just want it to work without all the error output to syslog and thrashing of my HD for minutes at a time. As I said, I've got the output of pulseaudio -vvvvv if anyone would like to look at it and tell me what I need to do to fix the problem.
Chris
Just upload your current pulseaudio.log and output of alsa-info.sh to mandriva 's bugzilla
Cannot obtain any conclusion based on the log which you have posted last year ( xmms)
as Jaroslav Kysela said , need the real system time between I/O
operations
and you'll see if it's issue in the ALSA driver or a task scheduling problem.
Here is the bug report with the outputs uploaded.
Well seeing as my process when getting such a bug is to report it here on behalf of the user, I suspect that this has reached a stalemate....
it depend on whether PA developer willing to provide system time between
I/O operations of PA server
However , he can still use a small buffer size to force the PA server into underrun and we can know how PA server handle this situtation
aplay -D pulse --buffer-size=128 any.wav
2010/7/15 Colin Guthrie gmane@colin.guthr.ie
'Twas brillig, and Chris at 15/07/10 02:38 did gyre and gimble:
On Thu, 2010-07-15 at 08:08 +0800, Raymond Yau wrote:
I posted both of those bug reports. Honestly, I just want it to work without all the error output to syslog and thrashing of my HD for minutes at a time. As I said, I've got the output of pulseaudio -vvvvv if anyone would like to look at it and tell me what I need to do to fix the problem.
Chris
Just upload your current pulseaudio.log and output of alsa-info.sh to mandriva 's bugzilla
Cannot obtain any conclusion based on the log which you have posted last year ( xmms)
as Jaroslav Kysela said , need the real system time between I/O
operations
and you'll see if it's issue in the ALSA driver or a task scheduling problem.
Here is the bug report with the outputs uploaded.
Well seeing as my process when getting such a bug is to report it here on behalf of the user, I suspect that this has reached a stalemate....
Refer to https://qa.mandriva.com/show_bug.cgi?id=56473#c10
I have installed mandriva 2010 on virtual box
when using xmms and libao output plugin to play system sound startup3.wav
xmms hang at the end of the playback only when enable buffering in libao output plugin.(configure output plugin in xmms, unfortunately default is enable buffering buffer size 3000 chunk size 1000) ,
xmms does not hang when you disable the buffer or using liboss/libALSA output plugin
The last message in the pulseaudio server is D: protocol-native.c 'underrun on libao[xmms] playback stream' , 0 bytes in queue.
The sound card seem running since hw_ptr and appl_ptr are increasing when cat /proc/asound/card0/pcm0p/sub0/status
After a while , the following message appear
E:alsa-sink.c : ALSA woke us up to write new data , but there was actually nothing to write!
On Mon, 2010-07-19 at 09:44 +0800, Raymond Yau wrote:
2010/7/15 Colin Guthrie gmane@colin.guthr.ie
'Twas brillig, and Chris at 15/07/10 02:38 did gyre and gimble:
On Thu, 2010-07-15 at 08:08 +0800, Raymond Yau wrote:
I posted both of those bug reports. Honestly, I just want it to work without all the error output to syslog and thrashing of my HD for minutes at a time. As I said, I've got the output of pulseaudio -vvvvv if anyone would like to look at it and tell me what I need to do to fix the problem.
Chris
Just upload your current pulseaudio.log and output of alsa-info.sh to mandriva 's bugzilla
Cannot obtain any conclusion based on the log which you have posted last year ( xmms)
as Jaroslav Kysela said , need the real system time between I/O
operations
and you'll see if it's issue in the ALSA driver or a task scheduling problem.
Here is the bug report with the outputs uploaded.
Well seeing as my process when getting such a bug is to report it here on behalf of the user, I suspect that this has reached a stalemate....
Refer to https://qa.mandriva.com/show_bug.cgi?id=56473#c10
I have installed mandriva 2010 on virtual box
when using xmms and libao output plugin to play system sound startup3.wav
xmms hang at the end of the playback only when enable buffering in libao output plugin.(configure output plugin in xmms, unfortunately default is enable buffering buffer size 3000 chunk size 1000) ,
xmms does not hang when you disable the buffer or using liboss/libALSA output plugin
The last message in the pulseaudio server is D: protocol-native.c 'underrun on libao[xmms] playback stream' , 0 bytes in queue.
The sound card seem running since hw_ptr and appl_ptr are increasing when cat /proc/asound/card0/pcm0p/sub0/status
After a while , the following message appear
E:alsa-sink.c : ALSA woke us up to write new data , but there was actually nothing to write!
The above is exactly what I see periodically Raymond, so, what, if any, is the fix?
Chris
2010/7/19 Chris cpollock@embarqmail.com
On Mon, 2010-07-19 at 09:44 +0800, Raymond Yau wrote:
Refer to https://qa.mandriva.com/show_bug.cgi?id=56473#c10
I have installed mandriva 2010 on virtual box
when using xmms and libao output plugin to play system sound startup3.wav
xmms hang at the end of the playback only when enable buffering in libao output plugin.(configure output plugin in xmms, unfortunately default is enable buffering buffer size 3000 chunk size 1000) ,
xmms does not hang when you disable the buffer or using liboss/libALSA output plugin
The last message in the pulseaudio server is D: protocol-native.c 'underrun on libao[xmms] playback stream' , 0 bytes
in
queue.
The sound card seem running since hw_ptr and appl_ptr are increasing when cat /proc/asound/card0/pcm0p/sub0/status
After a while , the following message appear
E:alsa-sink.c : ALSA woke us up to write new data , but there was
actually
nothing to write!
The above is exactly what I see periodically Raymond, so, what, if any, is the fix?
Chris
Do you mean that you cannot reproduce the xmms hang bug on your ens1371 or via8237 ?
xmms always hang/freeze at 4 second as xmms display the total length of startup3.wav is 5 seconds
you have to ask mandriva 's maintainer why enable buffering is the default option since xmms did not hang when I disable buffering in libao plugin
For fefora 10 and 13 , they only provide liboss, libALSA and libpulse plugin for xmms I have no idea about the chunk size in libao plugin
'Twas brillig, and Raymond Yau at 19/07/10 07:35 did gyre and gimble:
2010/7/19 Chris cpollock@embarqmail.com
On Mon, 2010-07-19 at 09:44 +0800, Raymond Yau wrote:
Refer to https://qa.mandriva.com/show_bug.cgi?id=56473#c10
I have installed mandriva 2010 on virtual box
when using xmms and libao output plugin to play system sound startup3.wav
xmms hang at the end of the playback only when enable buffering in libao output plugin.(configure output plugin in xmms, unfortunately default is enable buffering buffer size 3000 chunk size 1000) ,
xmms does not hang when you disable the buffer or using liboss/libALSA output plugin
The last message in the pulseaudio server is D: protocol-native.c 'underrun on libao[xmms] playback stream' , 0 bytes
in
queue.
The sound card seem running since hw_ptr and appl_ptr are increasing when cat /proc/asound/card0/pcm0p/sub0/status
After a while , the following message appear
E:alsa-sink.c : ALSA woke us up to write new data , but there was
actually
nothing to write!
The above is exactly what I see periodically Raymond, so, what, if any, is the fix?
Chris
Do you mean that you cannot reproduce the xmms hang bug on your ens1371 or via8237 ?
xmms always hang/freeze at 4 second as xmms display the total length of startup3.wav is 5 seconds
you have to ask mandriva 's maintainer why enable buffering is the default option since xmms did not hang when I disable buffering in libao plugin
For fefora 10 and 13 , they only provide liboss, libALSA and libpulse plugin for xmms I have no idea about the chunk size in libao plugin
With a clean user account, I could not reproduce either problem with the default settings.
FWIW, running PA under virtualbox is quite different to running it under a real system. For example PA will enable the non-timer based mode automatically when under a virtual machine.
Col
On Mon, 2010-07-19 at 08:53 +0100, Colin Guthrie wrote:
'Twas brillig, and Raymond Yau at 19/07/10 07:35 did gyre and gimble:
2010/7/19 Chris cpollock@embarqmail.com
On Mon, 2010-07-19 at 09:44 +0800, Raymond Yau wrote:
Refer to https://qa.mandriva.com/show_bug.cgi?id=56473#c10
I have installed mandriva 2010 on virtual box
when using xmms and libao output plugin to play system sound startup3.wav
xmms hang at the end of the playback only when enable buffering in libao output plugin.(configure output plugin in xmms, unfortunately default is enable buffering buffer size 3000 chunk size 1000) ,
xmms does not hang when you disable the buffer or using liboss/libALSA output plugin
The last message in the pulseaudio server is D: protocol-native.c 'underrun on libao[xmms] playback stream' , 0 bytes
in
queue.
The sound card seem running since hw_ptr and appl_ptr are increasing when cat /proc/asound/card0/pcm0p/sub0/status
After a while , the following message appear
E:alsa-sink.c : ALSA woke us up to write new data , but there was
actually
nothing to write!
The above is exactly what I see periodically Raymond, so, what, if any, is the fix?
Chris
Do you mean that you cannot reproduce the xmms hang bug on your ens1371 or via8237 ?
xmms always hang/freeze at 4 second as xmms display the total length of startup3.wav is 5 seconds
you have to ask mandriva 's maintainer why enable buffering is the default option since xmms did not hang when I disable buffering in libao plugin
For fefora 10 and 13 , they only provide liboss, libALSA and libpulse plugin for xmms I have no idea about the chunk size in libao plugin
With a clean user account, I could not reproduce either problem with the default settings.
FWIW, running PA under virtualbox is quite different to running it under a real system. For example PA will enable the non-timer based mode automatically when under a virtual machine.
Col
Colin, I've just re-enabled PA using the Ensoniq/Creative AudioPCI ES1371+ driver, this is according to the Mandriva Control Center sound setup. However, it also shows the VIA VT82xx audio driver when initially loaded, when I click on 'ok' it shows the Ensoniq driver. I've again run pulseaudio -k ; pulseaudio -vvvvv while playing a cd with mplayer. I've uploaded the output here:
Does this have any meaning?
Thanks for any assistance.
Chris
2010/7/20 Chris cpollock@embarqmail.com
On Mon, 2010-07-19 at 08:53 +0100, Colin Guthrie wrote:
'Twas brillig, and Raymond Yau at 19/07/10 07:35 did gyre and gimble:
2010/7/19 Chris cpollock@embarqmail.com
On Mon, 2010-07-19 at 09:44 +0800, Raymond Yau wrote:
Refer to https://qa.mandriva.com/show_bug.cgi?id=56473#c10
I have installed mandriva 2010 on virtual box
when using xmms and libao output plugin to play system sound
startup3.wav
xmms hang at the end of the playback only when enable buffering in
libao
output plugin.(configure output plugin in xmms, unfortunately default
is
enable buffering buffer size 3000 chunk size 1000) ,
xmms does not hang when you disable the buffer or using
liboss/libALSA
output plugin
The last message in the pulseaudio server is D: protocol-native.c 'underrun on libao[xmms] playback stream' , 0
bytes
in
queue.
The sound card seem running since hw_ptr and appl_ptr are increasing
when
cat /proc/asound/card0/pcm0p/sub0/status
After a while , the following message appear
E:alsa-sink.c : ALSA woke us up to write new data , but there was
actually
nothing to write!
The above is exactly what I see periodically Raymond, so, what, if
any,
is the fix?
Chris
Do you mean that you cannot reproduce the xmms hang bug on your ens1371
or
via8237 ?
xmms always hang/freeze at 4 second as xmms display the total length of startup3.wav is 5 seconds
you have to ask mandriva 's maintainer why enable buffering is the
default
option since xmms did not hang when I disable buffering in libao plugin
For fefora 10 and 13 , they only provide liboss, libALSA and libpulse
plugin
for xmms I have no idea about the chunk size in libao plugin
With a clean user account, I could not reproduce either problem with the default settings.
FWIW, running PA under virtualbox is quite different to running it under a real system. For example PA will enable the non-timer based mode automatically when under a virtual machine.
Col
Colin, I've just re-enabled PA using the Ensoniq/Creative AudioPCI ES1371+ driver, this is according to the Mandriva Control Center sound setup. However, it also shows the VIA VT82xx audio driver when initially loaded, when I click on 'ok' it shows the Ensoniq driver. I've again run pulseaudio -k ; pulseaudio -vvvvv while playing a cd with mplayer. I've uploaded the output here:
Does this have any meaning?
Thanks for any assistance.
Chris
Please note that alsaplayer is not aplay
you can easily make underrun/overrun occur on pulse device by specify a buffer size which is smaller than PA server used
aplay -Dpulse -v --buffer-size=128 /usr/share/sounds/*.wav
arecord -v -Dpulse -f cd -d 60 --buffer-size=128 test.wav
can you provide pulseaudio log for the underrun/overrun by aplay/arecord ?
mandriva 2010 seem still support ALSA OSS emulation
unless you have a hardware mixing sound card , you have to configure your gmplayer to use alsa or pulse
more .mplayer/gui.conf ao_driver = "oss" <--------pulse or alsa ao_alsa_device = "hw:0,0" <----- pulse or default
On Tue, 2010-07-20 at 09:23 +0800, Raymond Yau wrote:
2010/7/20 Chris cpollock@embarqmail.com
On Mon, 2010-07-19 at 08:53 +0100, Colin Guthrie wrote:
'Twas brillig, and Raymond Yau at 19/07/10 07:35 did gyre and gimble:
2010/7/19 Chris cpollock@embarqmail.com
On Mon, 2010-07-19 at 09:44 +0800, Raymond Yau wrote:
> Refer to https://qa.mandriva.com/show_bug.cgi?id=56473#c10
I have installed mandriva 2010 on virtual box
when using xmms and libao output plugin to play system sound
startup3.wav
xmms hang at the end of the playback only when enable buffering in
libao
output plugin.(configure output plugin in xmms, unfortunately default
is
enable buffering buffer size 3000 chunk size 1000) ,
xmms does not hang when you disable the buffer or using
liboss/libALSA
output plugin
The last message in the pulseaudio server is D: protocol-native.c 'underrun on libao[xmms] playback stream' , 0
bytes
in
queue.
The sound card seem running since hw_ptr and appl_ptr are increasing
when
cat /proc/asound/card0/pcm0p/sub0/status
After a while , the following message appear
E:alsa-sink.c : ALSA woke us up to write new data , but there was
actually
nothing to write!
The above is exactly what I see periodically Raymond, so, what, if
any,
is the fix?
Chris
Do you mean that you cannot reproduce the xmms hang bug on your ens1371
or
via8237 ?
xmms always hang/freeze at 4 second as xmms display the total length of startup3.wav is 5 seconds
you have to ask mandriva 's maintainer why enable buffering is the
default
option since xmms did not hang when I disable buffering in libao plugin
For fefora 10 and 13 , they only provide liboss, libALSA and libpulse
plugin
for xmms I have no idea about the chunk size in libao plugin
With a clean user account, I could not reproduce either problem with the default settings.
FWIW, running PA under virtualbox is quite different to running it under a real system. For example PA will enable the non-timer based mode automatically when under a virtual machine.
Col
Colin, I've just re-enabled PA using the Ensoniq/Creative AudioPCI ES1371+ driver, this is according to the Mandriva Control Center sound setup. However, it also shows the VIA VT82xx audio driver when initially loaded, when I click on 'ok' it shows the Ensoniq driver. I've again run pulseaudio -k ; pulseaudio -vvvvv while playing a cd with mplayer. I've uploaded the output here:
Does this have any meaning?
Thanks for any assistance.
Chris
Please note that alsaplayer is not aplay
you can easily make underrun/overrun occur on pulse device by specify a buffer size which is smaller than PA server used
aplay -Dpulse -v --buffer-size=128 /usr/share/sounds/*.wav
arecord -v -Dpulse -f cd -d 60 --buffer-size=128 test.wav
can you provide pulseaudio log for the underrun/overrun by aplay/arecord ?
mandriva 2010 seem still support ALSA OSS emulation
unless you have a hardware mixing sound card , you have to configure your gmplayer to use alsa or pulse
more .mplayer/gui.conf ao_driver = "oss" <--------pulse or alsa ao_alsa_device = "hw:0,0" <----- pulse or default
Ok Raymond, the gui.conf now reads:
ao_driver = "alsa" ao_alsa_device = "default"
After setting this and again playing a cd mplayer was very choppy, there was an error window but I couldn't read it since it was flashing so fast. MPlayer eventually died though the process was still running. I had to manually kill it. Below is the link to the new log file:
2010/7/20 Chris cpollock@embarqmail.com
On Tue, 2010-07-20 at 09:23 +0800, Raymond Yau wrote:
2010/7/20 Chris cpollock@embarqmail.com
On Mon, 2010-07-19 at 08:53 +0100, Colin Guthrie wrote:
'Twas brillig, and Raymond Yau at 19/07/10 07:35 did gyre and gimble:
2010/7/19 Chris cpollock@embarqmail.com
On Mon, 2010-07-19 at 09:44 +0800, Raymond Yau wrote:
>> > Refer to https://qa.mandriva.com/show_bug.cgi?id=56473#c10 > > I have installed mandriva 2010 on virtual box > > when using xmms and libao output plugin to play system sound
startup3.wav
> > xmms hang at the end of the playback only when enable buffering
in
libao
> output plugin.(configure output plugin in xmms, unfortunately
default
is
> enable buffering buffer size 3000 chunk size 1000) , > > xmms does not hang when you disable the buffer or using
liboss/libALSA
> output plugin > > The last message in the pulseaudio server is > D: protocol-native.c 'underrun on libao[xmms] playback stream' ,
0
bytes
in > queue. > > The sound card seem running since hw_ptr and appl_ptr are
increasing
when
> cat /proc/asound/card0/pcm0p/sub0/status > > After a while , the following message appear > > E:alsa-sink.c : ALSA woke us up to write new data , but there was actually > nothing to write! The above is exactly what I see periodically Raymond, so, what, if
any,
is the fix?
Chris
Do you mean that you cannot reproduce the xmms hang bug on your
ens1371
or
via8237 ?
xmms always hang/freeze at 4 second as xmms display the total
length of
startup3.wav is 5 seconds
you have to ask mandriva 's maintainer why enable buffering is the
default
option since xmms did not hang when I disable buffering in libao
plugin
For fefora 10 and 13 , they only provide liboss, libALSA and
libpulse
plugin
for xmms I have no idea about the chunk size in libao plugin
With a clean user account, I could not reproduce either problem with
the
default settings.
FWIW, running PA under virtualbox is quite different to running it
under
a real system. For example PA will enable the non-timer based mode automatically when under a virtual machine.
Col
Colin, I've just re-enabled PA using the Ensoniq/Creative AudioPCI ES1371+ driver, this is according to the Mandriva Control Center sound setup. However, it also shows the VIA VT82xx audio driver when
initially
loaded, when I click on 'ok' it shows the Ensoniq driver. I've again
run
pulseaudio -k ; pulseaudio -vvvvv while playing a cd with mplayer. I've uploaded the output here:
Does this have any meaning?
Thanks for any assistance.
Chris
Please note that alsaplayer is not aplay
you can easily make underrun/overrun occur on pulse device by specify a buffer size which is smaller than PA server used
aplay -Dpulse -v --buffer-size=128 /usr/share/sounds/*.wav
arecord -v -Dpulse -f cd -d 60 --buffer-size=128 test.wav
can you provide pulseaudio log for the underrun/overrun by aplay/arecord
?
mandriva 2010 seem still support ALSA OSS emulation
unless you have a hardware mixing sound card , you have to configure your gmplayer to use alsa or pulse
more .mplayer/gui.conf ao_driver = "oss" <--------pulse or alsa ao_alsa_device = "hw:0,0" <----- pulse or default
Ok Raymond, the gui.conf now reads:
ao_driver = "alsa" ao_alsa_device = "default"
After setting this and again playing a cd mplayer was very choppy, there was an error window but I couldn't read it since it was flashing so fast. MPlayer eventually died though the process was still running. I had to manually kill it. Below is the link to the new log file:
AFAIK , mplayer does not support CD playback ? ( seem only VCD or DVD )
most likely mandriva had patched the shortcut of gmplayer to use padsp and that 's why you can see "OSS Emulation[mplayer]" in the pulseaudio log
How about using ALSA OSS emulation instead of padsp ?
mplayer -v -ao oss any.wav
Trying preferred audio driver 'oss', options '[none]' ao2: 44100 Hz 2 chans s16le audio_setup: using '/dev/dsp' dsp device audio_setup: using '/dev/mixer' mixer device audio_setup: using 'pcm' mixer device audio_setup: sample format: s16le (requested: s16le) audio_setup: using 2 channels (requested: 2) audio_setup: using 44100 Hz samplerate (requested: 44100) audio_setup: frags: 16/16 (4096 bytes/frag) free: 65536
This force mplayer to use power two period size (4096 bytes) and this may meet the requirement of ens1371 if PCI data transfer are 8 Long bytes brust transfer
5.5 PCI Data transfer
Only brust read/write transfers are allowed. All data transfer are 8 Long Word brust transfers
As your PA server using period size 1102 which is not multiple of 8 ( 32 bytes )
It seem that you have customised the deamon.conf since PA server using maximum buffer size
The sound quality seem ok when playing audio using mplayer inside the virtualbox
The following messages sometime come up at the beginning of the playback only when watching videos using mplayer -ao alsa:device=pulse
ao_alsa: write error: Broken pipe ao_alsa: trying to *reset* *soundcard* ao_alsa: write error: Broken pipe ao_alsa: trying to *reset* *soundcard*
The sound quality is still fine when watching video using
mplayer -v -ao alsa:device=pulse mplayer -v -ao alsa:device=hw=0 mplayer -v -ao pulse mplayer -v ao oss
On Tue, 2010-07-20 at 19:41 +0800, Raymond Yau wrote:
2010/7/20 Chris cpollock@embarqmail.com
AFAIK , mplayer does not support CD playback ? ( seem only VCD or DVD )
most likely mandriva had patched the shortcut of gmplayer to use padsp and that 's why you can see "OSS Emulation[mplayer]" in the pulseaudio log
How about using ALSA OSS emulation instead of padsp ?
mplayer -v -ao oss any.wav
Trying preferred audio driver 'oss', options '[none]' ao2: 44100 Hz 2 chans s16le audio_setup: using '/dev/dsp' dsp device audio_setup: using '/dev/mixer' mixer device audio_setup: using 'pcm' mixer device audio_setup: sample format: s16le (requested: s16le) audio_setup: using 2 channels (requested: 2) audio_setup: using 44100 Hz samplerate (requested: 44100) audio_setup: frags: 16/16 (4096 bytes/frag) free: 65536
This force mplayer to use power two period size (4096 bytes) and this may meet the requirement of ens1371 if PCI data transfer are 8 Long bytes brust transfer
5.5 PCI Data transfer
Only brust read/write transfers are allowed. All data transfer are 8 Long Word brust transfers
As your PA server using period size 1102 which is not multiple of 8 ( 32 bytes )
It seem that you have customised the deamon.conf since PA server using maximum buffer size
The sound quality seem ok when playing audio using mplayer inside the virtualbox
The following messages sometime come up at the beginning of the playback only when watching videos using mplayer -ao alsa:device=pulse
ao_alsa: write error: Broken pipe ao_alsa: trying to *reset* *soundcard* ao_alsa: write error: Broken pipe ao_alsa: trying to *reset* *soundcard*
The sound quality is still fine when watching video using
mplayer -v -ao alsa:device=pulse mplayer -v -ao alsa:device=hw=0 mplayer -v -ao pulse mplayer -v ao oss _______________________________________________
Before I try the above Raymond, what would cause the below when the system is sitting here basically idle? I'm not even home to do anything when this happened?
Jul 20 11:32:43 localhost pulseaudio[28711]: asyncq.c: q overrun, queuing locally Jul 20 11:32:43 localhost pulseaudio[28711]: asyncq.c: q overrun, queuing locally Jul 20 11:32:43 localhost pulseaudio[28711]: asyncq.c: q overrun, queuing locally Jul 20 11:32:43 localhost pulseaudio[28711]: asyncq.c: q overrun, queuing locally Jul 20 11:32:43 localhost pulseaudio[28711]: asyncq.c: q overrun, queuing locally Jul 20 11:32:43 localhost pulseaudio[28711]: asyncq.c: q overrun, queuing locally Jul 20 11:32:43 localhost pulseaudio[28711]: asyncq.c: q overrun, queuing locally Jul 20 11:32:43 localhost pulseaudio[28711]: asyncq.c: q overrun, queuing locally Jul 20 11:32:43 localhost pulseaudio[28711]: asyncq.c: q overrun, queuing locally Jul 20 11:32:43 localhost pulseaudio[28711]: asyncq.c: q overrun, queuing locally Jul 20 11:32:45 localhost pulseaudio[28711]: ratelimit.c: 240 events suppressed Jul 20 11:32:45 localhost pulseaudio[28711]: asyncq.c: q overrun, queuing locally Jul 20 11:32:45 localhost pulseaudio[28711]: asyncq.c: q overrun, queuing locally Jul 20 11:32:45 localhost pulseaudio[28711]: asyncq.c: q overrun, queuing locally Jul 20 11:32:45 localhost pulseaudio[28711]: asyncq.c: q overrun, queuing locally Jul 20 11:32:45 localhost pulseaudio[28711]: asyncq.c: q overrun, queuing locally Jul 20 11:32:45 localhost pulseaudio[28711]: asyncq.c: q overrun, queuing locally Jul 20 11:32:45 localhost pulseaudio[28711]: asyncq.c: q overrun, queuing locally Jul 20 11:32:45 localhost pulseaudio[28711]: asyncq.c: q overrun, queuing locally Jul 20 11:32:45 localhost pulseaudio[28711]: asyncq.c: q overrun, queuing locally Jul 20 11:32:45 localhost pulseaudio[28711]: asyncq.c: q overrun, queuing locally Jul 20 11:32:45 localhost pulseaudio[28711]: asyncq.c: q overrun, queuing locally
The only thing that is going on just prior this is:
Jul 20 11:32:02 localhost mdkapplet[17869]: Computing new updates... Jul 20 11:32:04 localhost mdkapplet[17869]: running: urpmi.update --update Jul 20 11:32:10 localhost mdkapplet[17869]: 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 20 11:32:10 localhost mdkapplet[17869]: running: urpmi.update Main Backports (Official2010.1-4) Jul 20 11:32:12 localhost mdkapplet[17869]: running: urpmi.update Contrib Backports (Official2010.1-12) Jul 20 11:32:14 localhost mdkapplet[17869]: running: urpmi.update Non-free Backports (Official2010.1-20) Jul 20 11:32:16 localhost mdkapplet[17869]: running: urpmi.update PLF Free backports Jul 20 11:32:17 localhost mdkapplet[17869]: running: urpmi.update PLF Non-free backports
2010/7/21 Chris cpollock@embarqmail.com
Before I try the above Raymond, what would cause the below when the system is sitting here basically idle? I'm not even home to do anything when this happened?
Jul 20 11:32:43 localhost pulseaudio[28711]: asyncq.c: q overrun, queuing locally Jul 20 11:32:43 localhost pulseaudio[28711]: asyncq.c: q overrun, queuing locally Jul 20 11:32:43 localhost pulseaudio[28711]: asyncq.c: q overrun, queuing locally Jul 20 11:32:43 localhost pulseaudio[28711]: asyncq.c: q overrun, queuing locally Jul 20 11:32:43 localhost pulseaudio[28711]: asyncq.c: q overrun, queuing locally Jul 20 11:32:43 localhost pulseaudio[28711]: asyncq.c: q overrun, queuing locally Jul 20 11:32:43 localhost pulseaudio[28711]: asyncq.c: q overrun, queuing locally Jul 20 11:32:43 localhost pulseaudio[28711]: asyncq.c: q overrun, queuing locally Jul 20 11:32:43 localhost pulseaudio[28711]: asyncq.c: q overrun, queuing locally Jul 20 11:32:43 localhost pulseaudio[28711]: asyncq.c: q overrun, queuing locally Jul 20 11:32:45 localhost pulseaudio[28711]: ratelimit.c: 240 events suppressed Jul 20 11:32:45 localhost pulseaudio[28711]: asyncq.c: q overrun, queuing locally Jul 20 11:32:45 localhost pulseaudio[28711]: asyncq.c: q overrun, queuing locally Jul 20 11:32:45 localhost pulseaudio[28711]: asyncq.c: q overrun, queuing locally Jul 20 11:32:45 localhost pulseaudio[28711]: asyncq.c: q overrun, queuing locally Jul 20 11:32:45 localhost pulseaudio[28711]: asyncq.c: q overrun, queuing locally Jul 20 11:32:45 localhost pulseaudio[28711]: asyncq.c: q overrun, queuing locally Jul 20 11:32:45 localhost pulseaudio[28711]: asyncq.c: q overrun, queuing locally Jul 20 11:32:45 localhost pulseaudio[28711]: asyncq.c: q overrun, queuing locally Jul 20 11:32:45 localhost pulseaudio[28711]: asyncq.c: q overrun, queuing locally Jul 20 11:32:45 localhost pulseaudio[28711]: asyncq.c: q overrun, queuing locally Jul 20 11:32:45 localhost pulseaudio[28711]: asyncq.c: q overrun, queuing locally
I don't think the system is idle , you still have the gnome-volume-mixer-applet / kmix connected to PA server using pulse api
pactl stat
pactl list
you have to ask PA developers because I cannot reproduce "asyncq.c: q overrun," in the virtualbox
On Wed, 2010-07-21 at 16:17 +0800, Raymond Yau wrote:
2010/7/21 Chris cpollock@embarqmail.com
Before I try the above Raymond, what would cause the below when the system is sitting here basically idle? I'm not even home to do anything when this happened?
Jul 20 11:32:43 localhost pulseaudio[28711]: asyncq.c: q overrun, queuing locally Jul 20 11:32:43 localhost pulseaudio[28711]: asyncq.c: q overrun, queuing locally Jul 20 11:32:43 localhost pulseaudio[28711]: asyncq.c: q overrun, queuing locally Jul 20 11:32:43 localhost pulseaudio[28711]: asyncq.c: q overrun, queuing locally Jul 20 11:32:43 localhost pulseaudio[28711]: asyncq.c: q overrun, queuing locally Jul 20 11:32:43 localhost pulseaudio[28711]: asyncq.c: q overrun, queuing locally Jul 20 11:32:43 localhost pulseaudio[28711]: asyncq.c: q overrun, queuing locally Jul 20 11:32:43 localhost pulseaudio[28711]: asyncq.c: q overrun, queuing locally Jul 20 11:32:43 localhost pulseaudio[28711]: asyncq.c: q overrun, queuing locally Jul 20 11:32:43 localhost pulseaudio[28711]: asyncq.c: q overrun, queuing locally Jul 20 11:32:45 localhost pulseaudio[28711]: ratelimit.c: 240 events suppressed Jul 20 11:32:45 localhost pulseaudio[28711]: asyncq.c: q overrun, queuing locally Jul 20 11:32:45 localhost pulseaudio[28711]: asyncq.c: q overrun, queuing locally Jul 20 11:32:45 localhost pulseaudio[28711]: asyncq.c: q overrun, queuing locally Jul 20 11:32:45 localhost pulseaudio[28711]: asyncq.c: q overrun, queuing locally Jul 20 11:32:45 localhost pulseaudio[28711]: asyncq.c: q overrun, queuing locally Jul 20 11:32:45 localhost pulseaudio[28711]: asyncq.c: q overrun, queuing locally Jul 20 11:32:45 localhost pulseaudio[28711]: asyncq.c: q overrun, queuing locally Jul 20 11:32:45 localhost pulseaudio[28711]: asyncq.c: q overrun, queuing locally Jul 20 11:32:45 localhost pulseaudio[28711]: asyncq.c: q overrun, queuing locally Jul 20 11:32:45 localhost pulseaudio[28711]: asyncq.c: q overrun, queuing locally Jul 20 11:32:45 localhost pulseaudio[28711]: asyncq.c: q overrun, queuing locally
I don't think the system is idle , you still have the gnome-volume-mixer-applet / kmix connected to PA server using pulse api
pactl stat
pactl list
you have to ask PA developers because I cannot reproduce "asyncq.c: q overrun," in the virtualbox
Raymond, outputs of above are here:
2010/7/22 Chris cpollock@embarqmail.com
On Wed, 2010-07-21 at 16:17 +0800, Raymond Yau wrote:
2010/7/21 Chris cpollock@embarqmail.com
Before I try the above Raymond, what would cause the below when the system is sitting here basically idle? I'm not even home to do anything when this happened?
Jul 20 11:32:43 localhost pulseaudio[28711]: asyncq.c: q overrun, queuing locally Jul 20 11:32:45 localhost pulseaudio[28711]: ratelimit.c: 240 events suppressed Jul 20 11:32:45 localhost pulseaudio[28711]: asyncq.c: q overrun, queuing locally Jul 20 11:32:45 localhost pulseaudio[28711]: asyncq.c: q overrun, queuing locally Jul 20 11:32:45 localhost pulseaudio[28711]: asyncq.c: q overrun, queuing locally Jul 20 11:32:45 localhost pulseaudio[28711]: asyncq.c: q overrun, queuing locally Jul 20 11:32:45 localhost pulseaudio[28711]: asyncq.c: q overrun, queuing locally Jul 20 11:32:45 localhost pulseaudio[28711]: asyncq.c: q overrun, queuing locally Jul 20 11:32:45 localhost pulseaudio[28711]: asyncq.c: q overrun, queuing locally Jul 20 11:32:45 localhost pulseaudio[28711]: asyncq.c: q overrun, queuing locally Jul 20 11:32:45 localhost pulseaudio[28711]: asyncq.c: q overrun, queuing locally Jul 20 11:32:45 localhost pulseaudio[28711]: asyncq.c: q overrun, queuing locally Jul 20 11:32:45 localhost pulseaudio[28711]: asyncq.c: q overrun, queuing locally
I don't think the system is idle , you still have the gnome-volume-mixer-applet / kmix connected to PA server using pulse api
pactl stat
pactl list
you have to ask PA developers because I cannot reproduce "asyncq.c: q overrun," in the virtualbox
Raymond, outputs of above are here:
you only have three PA clients when your system is idle,
1. Client #0 2. Driver: module-console-kit.c 3. Properties: 4. application.name = "ConsoleKit Session /org/freedesktop/ConsoleKit/Session9" 5. console-kit.session = "/org/freedesktop/ConsoleKit/Session9" 6. 7. Client #1 8. Driver: protocol-native.c 9. application.name = "GNOME Volume Control Media Keys" 10. native-protocol.peer = "UNIX socket client" 11. native-protocol.version = "16" 12. application.id = "org.gnome.VolumeControl" 13. application.icon_name = "multimedia-volume-control" 14. application.version = "2.30.2" 15. application.process.id = "30012" 16. application.process.user = "chris" 17. application.process.host = "localhost" 18. application.process.binary = "gnome-settings-daemon" 19. application.language = "en_US.utf8" 20. window.x11.display = ":0.0" 21. 22. Client #2 23. Driver: protocol-native.c 24. application.name = "GNOME Volume Control Applet" 25. native-protocol.peer = "UNIX socket client" 26. native-protocol.version = "16" 27. application.id = "org.gnome.VolumeControl" 28. application.icon_name = "multimedia-volume-control" 29. application.version = "2.30.0" 30. application.process.id = "30031" 31. application.process.user = "chris" 32. application.process.host = "localhost" 33. application.process.binary = "gnome-volume-control-applet" 34. application.language = "en_US.utf8" 35. window.x11.display = ":0.0"
on Fedora 10 , there are 17 PA clients when I just open gnome-terminal to run pactl
consolekit, x11-xsmp, nm-applet, imsetting-applet, gnome-panel, trashapplet, wnckapplet, nautilus, clock-applet, mixer2-applet, gdm-user-switch-applet, notification-area-applet, mono, meta-city, gnome-terminal, gpk-update-icon and pactl
Just look at the driver modules, they only post PA_CORE_MESSAGE_UNLOAD_MODULE and PA_MESSAGE_SHUTDOWN , and wait for PA_MESSAGE_SHUTDOWN
i.e. the driver modules are unlikely to cause "asyncq overrun"
grep -ir "pa_asyncmsgq" * 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); alsa/alsa-sink.c: pa_asyncmsgq_wait_for(u->thread_mq.inq, PA_MESSAGE_SHUTDOWN); alsa/alsa-sink.c: pa_asyncmsgq_send(u->thread_mq.inq, NULL, PA_MESSAGE_SHUTDOWN, NULL, 0, NULL); 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); alsa/alsa-source.c: pa_asyncmsgq_wait_for(u->thread_mq.inq, PA_MESSAGE_SHUTDOWN); alsa/alsa-source.c: pa_asyncmsgq_send(u->thread_mq.inq, NULL, PA_MESSAGE_SHUTDOWN, NULL, 0, NULL); bluetooth/module-bluetooth-device.c: pa_asyncmsgq_post(u->thread_mq.outq, PA_MSGOBJECT(u->core), PA_CORE_MESSAGE_UNLOAD_MODULE, u->module, 0, NULL, NULL); bluetooth/module-bluetooth-device.c: pa_asyncmsgq_wait_for(u->thread_mq.inq, PA_MESSAGE_SHUTDOWN); bluetooth/module-bluetooth-device.c: pa_asyncmsgq_send(u->thread_mq.inq, NULL, PA_MESSAGE_SHUTDOWN, NULL, 0, NULL); coreaudio/module-coreaudio-device.c: pa_asyncmsgq *async_msgq; coreaudio/module-coreaudio-device.c: pa_assert_se(pa_asyncmsgq_send(u->async_msgq, PA_MSGOBJECT(u->sinks->pa_sink), coreaudio/module-coreaudio-device.c: pa_assert_se(pa_asyncmsgq_send(u->async_msgq, PA_MSGOBJECT(u->sources->pa_source), coreaudio/module-coreaudio-device.c: pa_asyncmsgq_post(u->thread_mq.outq, PA_MSGOBJECT(u->module->core), PA_CORE_MESSAGE_UNLOAD_MODULE, u->module, 0, NULL, NULL); coreaudio/module-coreaudio-device.c: pa_asyncmsgq_wait_for(u->thread_mq.inq, PA_MESSAGE_SHUTDOWN); coreaudio/module-coreaudio-device.c: u->async_msgq = pa_asyncmsgq_new(0); coreaudio/module-coreaudio-device.c: pa_asyncmsgq_send(u->thread_mq.inq, NULL, PA_MESSAGE_SHUTDOWN, NULL, 0, NULL); coreaudio/module-coreaudio-device.c: pa_asyncmsgq_unref(u->async_msgq); jack/module-jack-source.c: pa_asyncmsgq *jack_msgq; jack/module-jack-source.c: pa_asyncmsgq_post(u->thread_mq.outq, PA_MSGOBJECT(u->core), PA_CORE_MESSAGE_UNLOAD_MODULE, u->module, 0, NULL, NULL); jack/module-jack-source.c: pa_asyncmsgq_post(u->jack_msgq, PA_MSGOBJECT(u->source), SOURCE_MESSAGE_POST, NULL, frame_time, &chunk, NULL); jack/module-jack-source.c: pa_asyncmsgq_post(u->thread_mq.outq, PA_MSGOBJECT(u->core), PA_CORE_MESSAGE_UNLOAD_MODULE, u->module, 0, NULL, NULL); jack/module-jack-source.c: pa_asyncmsgq_wait_for(u->thread_mq.inq, PA_MESSAGE_SHUTDOWN); jack/module-jack-source.c: pa_asyncmsgq_post(u->jack_msgq, PA_MSGOBJECT(u->source), SOURCE_MESSAGE_ON_SHUTDOWN, NULL, 0, NULL, NULL); jack/module-jack-source.c: u->jack_msgq = pa_asyncmsgq_new(0); jack/module-jack-source.c: pa_asyncmsgq_send(u->thread_mq.inq, NULL, PA_MESSAGE_SHUTDOWN, NULL, 0, NULL); jack/module-jack-source.c: pa_asyncmsgq_unref(u->jack_msgq); jack/module-jack-sink.c: * via pa_asyncmsgq. The cost is an additional context switch which jack/module-jack-sink.c: pa_asyncmsgq *jack_msgq; jack/module-jack-sink.c: pa_asyncmsgq_post(u->thread_mq.outq, PA_MSGOBJECT(u->core), PA_CORE_MESSAGE_UNLOAD_MODULE, u->module, 0, NULL, NULL); jack/module-jack-sink.c: pa_assert_se(pa_asyncmsgq_send(u->jack_msgq, PA_MSGOBJECT(u->sink), SINK_MESSAGE_RENDER, &frame_time, nframes, NULL) == 0); jack/module-jack-sink.c: pa_asyncmsgq_post(u->thread_mq.outq, PA_MSGOBJECT(u->core), PA_CORE_MESSAGE_UNLOAD_MODULE, u->module, 0, NULL, NULL); jack/module-jack-sink.c: pa_asyncmsgq_wait_for(u->thread_mq.inq, PA_MESSAGE_SHUTDOWN); jack/module-jack-sink.c: pa_asyncmsgq_post(u->jack_msgq, PA_MSGOBJECT(u->sink), SINK_MESSAGE_ON_SHUTDOWN, NULL, 0, NULL, NULL); jack/module-jack-sink.c: pa_asyncmsgq_post(u->jack_msgq, PA_MSGOBJECT(u->sink), SINK_MESSAGE_BUFFER_SIZE, NULL, nframes, NULL, NULL); jack/module-jack-sink.c: u->jack_msgq = pa_asyncmsgq_new(0); jack/module-jack-sink.c: pa_asyncmsgq_send(u->thread_mq.inq, NULL, PA_MESSAGE_SHUTDOWN, NULL, 0, NULL); jack/module-jack-sink.c: pa_asyncmsgq_unref(u->jack_msgq);
module-solaris.c: pa_asyncmsgq_post(u->thread_mq.outq, PA_MSGOBJECT(u->core), PA_CORE_MESSAGE_UNLOAD_MODULE, u->module, 0, NULL, NULL); module-solaris.c: pa_asyncmsgq_wait_for(u->thread_mq.inq, PA_MESSAGE_SHUTDOWN); module-solaris.c: pa_asyncmsgq_send(u->thread_mq.inq, NULL, PA_MESSAGE_SHUTDOWN, NULL, 0, NULL); oss/module-oss.c: pa_asyncmsgq_post(u->thread_mq.outq, PA_MSGOBJECT(u->core), PA_CORE_MESSAGE_UNLOAD_MODULE, u->module, 0, NULL, NULL); oss/module-oss.c: pa_asyncmsgq_wait_for(u->thread_mq.inq, PA_MESSAGE_SHUTDOWN); oss/module-oss.c: pa_asyncmsgq_send(u->thread_mq.inq, NULL, PA_MESSAGE_SHUTDOWN, NULL, 0, NULL);
On Thu, 2010-07-22 at 08:33 +0800, Raymond Yau wrote:
2010/7/22 Chris cpollock@embarqmail.com
On Wed, 2010-07-21 at 16:17 +0800, Raymond Yau wrote:
2010/7/21 Chris cpollock@embarqmail.com
Before I try the above Raymond, what would cause the below when the system is sitting here basically idle? I'm not even home to do anything when this happened?
Jul 20 11:32:43 localhost pulseaudio[28711]: asyncq.c: q overrun, queuing locally Jul 20 11:32:45 localhost pulseaudio[28711]: ratelimit.c: 240 events suppressed Jul 20 11:32:45 localhost pulseaudio[28711]: asyncq.c: q overrun, queuing locally Jul 20 11:32:45 localhost pulseaudio[28711]: asyncq.c: q overrun, queuing locally Jul 20 11:32:45 localhost pulseaudio[28711]: asyncq.c: q overrun, queuing locally Jul 20 11:32:45 localhost pulseaudio[28711]: asyncq.c: q overrun, queuing locally Jul 20 11:32:45 localhost pulseaudio[28711]: asyncq.c: q overrun, queuing locally Jul 20 11:32:45 localhost pulseaudio[28711]: asyncq.c: q overrun, queuing locally Jul 20 11:32:45 localhost pulseaudio[28711]: asyncq.c: q overrun, queuing locally Jul 20 11:32:45 localhost pulseaudio[28711]: asyncq.c: q overrun, queuing locally Jul 20 11:32:45 localhost pulseaudio[28711]: asyncq.c: q overrun, queuing locally Jul 20 11:32:45 localhost pulseaudio[28711]: asyncq.c: q overrun, queuing locally Jul 20 11:32:45 localhost pulseaudio[28711]: asyncq.c: q overrun, queuing locally
I don't think the system is idle , you still have the gnome-volume-mixer-applet / kmix connected to PA server using pulse api
pactl stat
pactl list
you have to ask PA developers because I cannot reproduce "asyncq.c: q overrun," in the virtualbox
Raymond, outputs of above are here:
you only have three PA clients when your system is idle,
Does this output look better Raymond? On the first one I'd started PA from the cli instead of through MCC.
On Tue, 2010-07-20 at 19:41 +0800, Raymond Yau wrote:
AFAIK , mplayer does not support CD playback ? ( seem only VCD or DVD )
most likely mandriva had patched the shortcut of gmplayer to use padsp and that 's why you can see "OSS Emulation[mplayer]" in the pulseaudio log
How about using ALSA OSS emulation instead of padsp ?
mplayer -v -ao oss any.wav
Trying preferred audio driver 'oss', options '[none]' ao2: 44100 Hz 2 chans s16le audio_setup: using '/dev/dsp' dsp device audio_setup: using '/dev/mixer' mixer device audio_setup: using 'pcm' mixer device audio_setup: sample format: s16le (requested: s16le) audio_setup: using 2 channels (requested: 2) audio_setup: using 44100 Hz samplerate (requested: 44100) audio_setup: frags: 16/16 (4096 bytes/frag) free: 65536
This force mplayer to use power two period size (4096 bytes) and this may meet the requirement of ens1371 if PCI data transfer are 8 Long bytes brust transfer
5.5 PCI Data transfer
Only brust read/write transfers are allowed. All data transfer are 8 Long Word brust transfers
As your PA server using period size 1102 which is not multiple of 8 ( 32 bytes )
It seem that you have customised the deamon.conf since PA server using maximum buffer size
The sound quality seem ok when playing audio using mplayer inside the virtualbox
The following messages sometime come up at the beginning of the playback only when watching videos using mplayer -ao alsa:device=pulse
ao_alsa: write error: Broken pipe ao_alsa: trying to *reset* *soundcard* ao_alsa: write error: Broken pipe ao_alsa: trying to *reset* *soundcard*
The sound quality is still fine when watching video using
mplayer -v -ao alsa:device=pulse mplayer -v -ao alsa:device=hw=0 mplayer -v -ao pulse mplayer -v ao oss _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
Here's the output of the above: [chris@localhost Documents]$ mplayer -v -ao oss gotmail00.wav MPlayer SVN-1.rc4.0.r31086.3plf2010.1-4.4.3 (C) 2000-2010 MPlayer Team CPU vendor name: AuthenticAMD max cpuid level: 1 CPU: AMD Sempron(tm) Processor 2800+ (Family: 15, Model: 44, Stepping: 2) extended cpuid-level: 24 extended cache-info: 16810304 Detected cache-line size is 64 bytes Testing OS support for SSE... yes. Tests of OS support for SSE passed. CPUflags: MMX: 1 MMX2: 1 3DNow: 1 3DNowExt: 1 SSE: 1 SSE2: 1 SSSE3: 0 Compiled with runtime CPU detection. get_path('codecs.conf') -> '/home/chris/.mplayer/codecs.conf' Reading /home/chris/.mplayer/codecs.conf: Can't open '/home/chris/.mplayer/codecs.conf': No such file or directory Reading /etc/mplayer/codecs.conf: Can't open '/etc/mplayer/codecs.conf': No such file or directory Using built-in default codecs.conf. Configuration: --prefix=/usr --datadir=/usr/share/mplayer --confdir=/etc/mplayer --libdir=/usr/lib --enable-largefiles --enable-runtime-cpudetection --enable-mmx --enable-3dnow --enable-sse --enable-sse2 --enable-fastmemcpy --enable-freetype --enable-nas --disable-sighandler --enable-gui --language=all --disable-libdvdcss-internal --enable-lirc --enable-tv --enable-joystick --enable-gl --disable-svga --enable-directfb --enable-mencoder --enable-theora --enable-menu --disable-ggi --codecsdir=/usr/lib/codecs --disable-arts --enable-pulse --disable-openal --enable-zr --enable-xvmc --disable-ivtv CommandLine: '-v' '-ao' 'oss' 'gotmail00.wav' init_freetype Using MMX (with tiny bit MMX2) Optimized OnScreenDisplay get_path('fonts') -> '/home/chris/.mplayer/fonts' Using nanosleep() timing get_path('input.conf') -> '/home/chris/.mplayer/input.conf' Can't open input config file /home/chris/.mplayer/input.conf: No such file or directory Can't open input config file /etc/mplayer/input.conf: No such file or directory Falling back on default (hardcoded) input config Opening joystick device /dev/input/js0 Can't open joystick device /dev/input/js0: No such file or directory Can't init input joystick Setting up LIRC support... mplayer: could not connect to socket mplayer: No such file or directory Failed to open LIRC support. You will not be able to use your remote control. get_path('gotmail00.wav.conf') -> '/home/chris/.mplayer/gotmail00.wav.conf'
Playing gotmail00.wav. get_path('sub/') -> '/home/chris/.mplayer/sub/' [file] File size is 9946 bytes STREAM: [file] gotmail00.wav STREAM: Description: File STREAM: Author: Albeu STREAM: Comment: based on the code from ??? (probably Arpi) LAVF_check: WAV format Checking for YUV4MPEG2 ASF_check: not ASF guid! Checking for REAL Checking for SMJPEG Searching demuxer type for filename gotmail00.wav ext: .wav Trying demuxer 17 based on filename extension ==> Found audio stream: 0 ======= WAVE Format ======= Format Tag: 1 (0x1) Channels: 1 Samplerate: 11000 avg byte/sec: 11000 Block align: 1 bits/sample: 8 cbSize: 0 ========================================================================== demux_audio: audio data 0x2C - 0x26D9 Audio only file format detected. get_path('sub/') -> '/home/chris/.mplayer/sub/' ========================================================================== Opening audio decoder: [pcm] Uncompressed PCM audio decoder dec_audio: Allocating 2048 + 65536 = 67584 bytes for output buffer. AUDIO: 11000 Hz, 1 ch, u8, 88.0 kbit/100.00% (ratio: 11000->11000) Selected audio codec: [pcm] afm: pcm (Uncompressed PCM) ========================================================================== Building audio filter chain for 11000Hz/1ch/u8 -> 0Hz/0ch/??... [libaf] Adding filter dummy [dummy] Was reinitialized: 11000Hz/1ch/u8 [dummy] Was reinitialized: 11000Hz/1ch/u8 Trying preferred audio driver 'oss', options '[none]' ao2: 11000 Hz 1 chans u8 audio_setup: using '/dev/dsp' dsp device audio_setup: using '/dev/mixer' mixer device audio_setup: using 'pcm' mixer device audio_setup: sample format: u8 (requested: u8) audio_setup: using 1 channels (requested: 1) audio_setup: using 11000 Hz samplerate (requested: 11000) audio_setup: frags: 2/2 (8192 bytes/frag) free: 16384 AO: [oss] 11000Hz 1ch u8 (1 bytes per sample) AO: Description: OSS/ioctl audio output AO: Author: A'rpi Building audio filter chain for 11000Hz/1ch/u8 -> 11000Hz/1ch/u8... [dummy] Was reinitialized: 11000Hz/1ch/u8 [dummy] Was reinitialized: 11000Hz/1ch/u8 Video: no video Freeing 0 unused video chunks. Starting playback... ds_fill_buffer: EOF reached (stream: audio) ds_fill_buffer: EOF reached (stream: audio) Increasing filtered audio buffer size from 0 to 9901 ds_fill_buffer: EOF reached (stream: audio) ds_fill_buffer: EOF reached (stream: audio) EOF code: 1 9) of 0.9 (00.9) 0.0%
Uninit audio filters... [libaf] Removing filter dummy Uninit audio: pcm vo: x11 uninit called but X11 not initialized..
2010/7/15 Colin Guthrie gmane@colin.guthr.ie
'Twas brillig, and Chris at 15/07/10 02:38 did gyre and gimble:
On Thu, 2010-07-15 at 08:08 +0800, Raymond Yau wrote:
I posted both of those bug reports. Honestly, I just want it to work without all the error output to syslog and thrashing of my HD for minutes at a time. As I said, I've got the output of pulseaudio -vvvvv if anyone would like to look at it and tell me what I need to do to fix the problem.
Chris
Just upload your current pulseaudio.log and output of alsa-info.sh to mandriva 's bugzilla
Cannot obtain any conclusion based on the log which you have posted last year ( xmms)
as Jaroslav Kysela said , need the real system time between I/O
operations
and you'll see if it's issue in the ALSA driver or a task scheduling problem.
Here is the bug report with the outputs uploaded.
Well seeing as my process when getting such a bug is to report it here on behalf of the user, I suspect that this has reached a stalemate....
Can I remove pulseaudio from mandriva 2000 ?
I just want to test libcanberra-alsa alone ( i.e. libcanberra without pulseaudio )
when PA server abort, and libcanberra-pulse cannot connect to PA server ,
Will libcanberra use libcanberra-alsa connect to PA using alsa-pulse plugin ?
'Twas brillig, and Raymond Yau at 24/07/10 04:51 did gyre and gimble:
2010/7/15 Colin Guthrie gmane@colin.guthr.ie
'Twas brillig, and Chris at 15/07/10 02:38 did gyre and gimble:
On Thu, 2010-07-15 at 08:08 +0800, Raymond Yau wrote:
I posted both of those bug reports. Honestly, I just want it to work without all the error output to syslog and thrashing of my HD for minutes at a time. As I said, I've got the output of pulseaudio -vvvvv if anyone would like to look at it and tell me what I need to do to fix the problem.
Chris
Just upload your current pulseaudio.log and output of alsa-info.sh to mandriva 's bugzilla
Cannot obtain any conclusion based on the log which you have posted last year ( xmms)
as Jaroslav Kysela said , need the real system time between I/O
operations
and you'll see if it's issue in the ALSA driver or a task scheduling problem.
Here is the bug report with the outputs uploaded.
Well seeing as my process when getting such a bug is to report it here on behalf of the user, I suspect that this has reached a stalemate....
Can I remove pulseaudio from mandriva 2000 ?
I just want to test libcanberra-alsa alone ( i.e. libcanberra without pulseaudio )
when PA server abort, and libcanberra-pulse cannot connect to PA server ,
Will libcanberra use libcanberra-alsa connect to PA using alsa-pulse plugin ?
Use draksound (or via Mandriva Control Center) to disable pulseaudio and the ALSA backend for canberra should be used instead.
It's based on the alternatives system and the file /etc/sound/profiles/alsa/canberra.conf
Col
2010/7/25 Colin Guthrie gmane@colin.guthr.ie
'Twas brillig, and Raymond Yau at 24/07/10 04:51 did gyre and gimble:
2010/7/15 Colin Guthrie gmane@colin.guthr.ie
'Twas brillig, and Chris at 15/07/10 02:38 did gyre and gimble:
On Thu, 2010-07-15 at 08:08 +0800, Raymond Yau wrote:
I posted both of those bug reports. Honestly, I just want it to work without all the error output to syslog and thrashing of my HD for minutes at a time. As I said, I've got the output of pulseaudio
-vvvvv
if anyone would like to look at it and tell me what I need to do to
fix
the problem.
Chris
Just upload your current pulseaudio.log and output of alsa-info.sh to mandriva 's bugzilla
Cannot obtain any conclusion based on the log which you have posted
last
year ( xmms)
as Jaroslav Kysela said , need the real system time between I/O
operations
and you'll see if it's issue in the ALSA driver or a task scheduling problem.
Here is the bug report with the outputs uploaded.
Well seeing as my process when getting such a bug is to report it here on behalf of the user, I suspect that this has reached a stalemate....
Can I remove pulseaudio from mandriva 2000 ?
I just want to test libcanberra-alsa alone ( i.e. libcanberra without pulseaudio )
when PA server abort, and libcanberra-pulse cannot connect to PA server ,
Will libcanberra use libcanberra-alsa connect to PA using alsa-pulse
plugin
?
Use draksound (or via Mandriva Control Center) to disable pulseaudio and the ALSA backend for canberra should be used instead.
It's based on the alternatives system and the file /etc/sound/profiles/alsa/canberra.conf
Col http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
I have used Mandriva Control Centerl to disable pulseaudio and select alsa driver . Perform logout and login by MCC
aplay -v test.wav indicate that it is using dmix
there is no driver specified in .mplayer/config but when I run
mplayer -v test.wav
AO : [pulse] 44100 Hz
it seem that mplayer auto spawn PA server .
Did I miss out anything to disable pulseaudio since I assume that MCC had performed all the necessary action ?
more /etc/asound/profiles/alsa/canberra.conf CANBERRA_DRIVER=alsa
but
ls /etc/asound/profiles/current seem to be empty
2010/7/26 Raymond Yau superquad.vortex2@gmail.com
2010/7/25 Colin Guthrie gmane@colin.guthr.ie
'Twas brillig, and Raymond Yau at 24/07/10 04:51 did gyre and gimble:
2010/7/15 Colin Guthrie gmane@colin.guthr.ie
'Twas brillig, and Chris at 15/07/10 02:38 did gyre and gimble:
On Thu, 2010-07-15 at 08:08 +0800, Raymond Yau wrote:
> I posted both of those bug reports. Honestly, I just want it to work > without all the error output to syslog and thrashing of my HD for > minutes at a time. As I said, I've got the output of pulseaudio
-vvvvv
> if anyone would like to look at it and tell me what I need to do to
fix
> the problem. > > Chris > > > Just upload your current pulseaudio.log and output of alsa-info.sh to mandriva 's bugzilla
Cannot obtain any conclusion based on the log which you have posted
last
year ( xmms)
as Jaroslav Kysela said , need the real system time between I/O
operations
and you'll see if it's issue in the ALSA driver or a task scheduling problem.
Here is the bug report with the outputs uploaded.
Well seeing as my process when getting such a bug is to report it here on behalf of the user, I suspect that this has reached a stalemate....
Can I remove pulseaudio from mandriva 2000 ?
I just want to test libcanberra-alsa alone ( i.e. libcanberra without pulseaudio )
when PA server abort, and libcanberra-pulse cannot connect to PA server
,
Will libcanberra use libcanberra-alsa connect to PA using alsa-pulse
plugin
?
Use draksound (or via Mandriva Control Center) to disable pulseaudio and the ALSA backend for canberra should be used instead.
It's based on the alternatives system and the file /etc/sound/profiles/alsa/canberra.conf
Col http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
I have used Mandriva Control Centerl to disable pulseaudio and select alsa driver . Perform logout and login by MCC
aplay -v test.wav indicate that it is using dmix
there is no driver specified in .mplayer/config but when I run
mplayer -v test.wav
AO : [pulse] 44100 Hz
it seem that mplayer auto spawn PA server .
Did I miss out anything to disable pulseaudio since I assume that MCC had performed all the necessary action ?
more /etc/asound/profiles/alsa/canberra.conf CANBERRA_DRIVER=alsa
but
ls /etc/asound/profiles/current seem to be empty
After logout/login one more time . the pulseaudio seem to be disabled
The only thing is mixer applet disappeared from the system tray
is this a bug in MCC or I have to manually configured mixer applet not to use pulseaudio
2010/7/15 Chris cpollock@embarqmail.com
On Thu, 2010-07-15 at 08:08 +0800, Raymond Yau wrote:
I posted both of those bug reports. Honestly, I just want it to work without all the error output to syslog and thrashing of my HD for minutes at a time. As I said, I've got the output of pulseaudio -vvvvv if anyone would like to look at it and tell me what I need to do to fix the problem.
Chris
Just upload your current pulseaudio.log and output of alsa-info.sh to mandriva 's bugzilla
Cannot obtain any conclusion based on the log which you have posted last year ( xmms)
as Jaroslav Kysela said , need the real system time between I/O
operations
and you'll see if it's issue in the ALSA driver or a task scheduling problem.
Here is the bug report with the outputs uploaded.
https://qa.mandriva.com/show_bug.cgi?id=60169
Refer to your pulseaudio.log , it seem that you cannot reproduce the problems (underrun or asynqc overrun)
BTW , did alsa-time-test really fail if you run the alsa-time-test with your ens1371 using Takashi Iwai 's method
http://thread.gmane.org/gmane.linux.alsa.devel/60371/focus=60520
participants (4)
-
Chris -
Colin Guthrie -
Jaroslav Kysela -
Raymond Yau