Which project to choose?

Which project to choose?

[Chris]

[-- Attachment #1.1: Type: text/plain, Size: 2373 bytes --]

I want to submit a bug report on the below. This issue was noted in
Mandriva 2010 and is still present in 2010.1

pulseaudio[24553]: alsa-util.c: snd_pcm_delay() returned a value that is
exceptionally large: -161920 bytes (-917 ms).
localhost pulseaudio[24553]: alsa-util.c: Most likely this is a bug in
the ALSA driver 'snd_ens1371'. Please report this issue to the ALSA
developers.
localhost pulseaudio[24553]: alsa-util.c: snd_pcm_dump():
localhost pulseaudio[24553]: alsa-util.c: Hardware PCM card 0 'Ensoniq
AudioPCI' device 0 subdevice 0
localhost pulseaudio[24553]: alsa-util.c: Its setup is:
localhost pulseaudio[24553]: alsa-util.c:   stream       : PLAYBACK
localhost pulseaudio[24553]: alsa-util.c:   access       :
MMAP_INTERLEAVED
localhost pulseaudio[24553]: alsa-util.c:   format       : S16_LE
localhost pulseaudio[24553]: alsa-util.c:   subformat    : STD
localhost pulseaudio[24553]: alsa-util.c:   channels     : 2
localhost pulseaudio[24553]: alsa-util.c:   rate         : 44100
localhost pulseaudio[24553]: alsa-util.c:   exact rate   : 44101
(1445100000/32768)
localhost pulseaudio[24553]: alsa-util.c:   msbits       : 16
localhost pulseaudio[24553]: alsa-util.c:   buffer_size  : 4408
localhost pulseaudio[24553]: alsa-util.c:   period_size  : 1102
localhost pulseaudio[24553]: alsa-util.c:   period_time  : 24988
localhost pulseaudio[24553]: alsa-util.c:   tstamp_mode  : ENABLE
localhost pulseaudio[24553]: alsa-util.c:   period_step  : 1
localhost pulseaudio[24553]: alsa-util.c:   avail_min    : 1102
localhost pulseaudio[24553]: alsa-util.c:   period_event : 1
localhost pulseaudio[24553]: alsa-util.c:   start_threshold  : -1
localhost pulseaudio[24553]: alsa-util.c:   stop_threshold   :
1155530752
localhost pulseaudio[24553]: alsa-util.c:   silence_threshold: 0
localhost pulseaudio[24553]: alsa-util.c:   silence_size : 0
localhost pulseaudio[24553]: alsa-util.c:   boundary     : 1155530752
localhost pulseaudio[24553]: alsa-util.c:   appl_ptr     : 735801008
localhost pulseaudio[24553]: alsa-util.c:   hw_ptr       : 735846184
localhost pulseaudio[24553]: ratelimit.c: 280 events suppressed
localhost pulseaudio[24553]: asyncq.c: q overrun, queuing locally

Because of the constant disk access when this is happening my system
becomes almost unusable.

-- 
Chris
KeyID 0xE372A7DA98E6705C


[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Which project to choose?

[Raymond Yau]

2010/7/14 Chris <cpollock@embarqmail.com>

> I want to submit a bug report on the below. This issue was noted in
> Mandriva 2010 and is still present in 2010.1
>
> pulseaudio[24553]: alsa-util.c: snd_pcm_delay() returned a value that is
> exceptionally large: -161920 bytes (-917 ms).
> localhost pulseaudio[24553]: alsa-util.c: Most likely this is a bug in
> the ALSA driver 'snd_ens1371'. Please report this issue to the ALSA
> developers.
>

This kind of bug report without a full pulseaudio log is almost useless
without a test case which can reproduce the bug,


> localhost pulseaudio[24553]: alsa-util.c: snd_pcm_dump():
> localhost pulseaudio[24553]: alsa-util.c: Hardware PCM card 0 'Ensoniq
> AudioPCI' device 0 subdevice 0
> localhost pulseaudio[24553]: alsa-util.c: Its setup is:
> localhost pulseaudio[24553]: alsa-util.c:   stream       : PLAYBACK
> localhost pulseaudio[24553]: alsa-util.c:   access       :
> MMAP_INTERLEAVED
> localhost pulseaudio[24553]: alsa-util.c:   format       : S16_LE
> localhost pulseaudio[24553]: alsa-util.c:   subformat    : STD
> localhost pulseaudio[24553]: alsa-util.c:   channels     : 2
> localhost pulseaudio[24553]: alsa-util.c:   rate         : 44100
> localhost pulseaudio[24553]: alsa-util.c:   exact rate   : 44101
> (1445100000/32768)
>

The ens1371 cannot support exactly 44100

Re: Which project to choose?

[Chris]

[-- Attachment #1.1: Type: text/plain, Size: 2805 bytes --]

On Wed, 2010-07-14 at 07:26 +0800, Raymond Yau wrote:
> 2010/7/14 Chris <cpollock@embarqmail.com>
> 
> > I want to submit a bug report on the below. This issue was noted in
> > Mandriva 2010 and is still present in 2010.1
> >
> > pulseaudio[24553]: alsa-util.c: snd_pcm_delay() returned a value that is
> > exceptionally large: -161920 bytes (-917 ms).
> > localhost pulseaudio[24553]: alsa-util.c: Most likely this is a bug in
> > the ALSA driver 'snd_ens1371'. Please report this issue to the ALSA
> > developers.
> >
> 
> This kind of bug report without a full pulseaudio log is almost useless
> without a test case which can reproduce the bug,
> 
> 
> > localhost pulseaudio[24553]: alsa-util.c: snd_pcm_dump():
> > localhost pulseaudio[24553]: alsa-util.c: Hardware PCM card 0 'Ensoniq
> > AudioPCI' device 0 subdevice 0
> > localhost pulseaudio[24553]: alsa-util.c: Its setup is:
> > localhost pulseaudio[24553]: alsa-util.c:   stream       : PLAYBACK
> > localhost pulseaudio[24553]: alsa-util.c:   access       :
> > MMAP_INTERLEAVED
> > localhost pulseaudio[24553]: alsa-util.c:   format       : S16_LE
> > localhost pulseaudio[24553]: alsa-util.c:   subformat    : STD
> > localhost pulseaudio[24553]: alsa-util.c:   channels     : 2
> > localhost pulseaudio[24553]: alsa-util.c:   rate         : 44100
> > localhost pulseaudio[24553]: alsa-util.c:   exact rate   : 44101
> > (1445100000/32768)
> >
> 
> The ens1371 cannot support exactly 44100

Then Raymond, tell me, how do I stop this from happening? It just
happens, I'm not playing any audio when it does. For instance 

Jul 13 17:29:39 localhost pulseaudio[24553]: ratelimit.c: 466 events
suppressed
Jul 13 17:29:39 localhost pulseaudio[24553]: asyncq.c: q overrun,
queuing locally
Jul 13 17:29:39 localhost pulseaudio[24553]: asyncq.c: q overrun,
queuing locally
Jul 13 17:29:39 localhost pulseaudio[24553]: asyncq.c: q overrun,
queuing locally
Jul 13 17:29:39 localhost pulseaudio[24553]: asyncq.c: q overrun,
queuing locally
Jul 13 17:29:39 localhost pulseaudio[24553]: asyncq.c: q overrun,
queuing locally
Jul 13 17:29:39 localhost pulseaudio[24553]: asyncq.c: q overrun,
queuing locally
Jul 13 17:29:39 localhost pulseaudio[24553]: asyncq.c: q overrun,
queuing locally
Jul 13 17:29:39 localhost pulseaudio[24553]: asyncq.c: q overrun,
queuing locally
Jul 13 17:29:39 localhost pulseaudio[24553]: asyncq.c: q overrun,
queuing locally
Jul 13 17:29:39 localhost pulseaudio[24553]: asyncq.c: q overrun,
queuing locally
Jul 13 17:29:39 localhost pulseaudio[24553]: asyncq.c: q overrun,
queuing locally
Jul 13 17:29:44 localhost pulseaudio[24553]: ratelimit.c: 497 events
suppressed

So, is this a pulseaudio issue or an Alsa issue?

-- 
Chris
KeyID 0xE372A7DA98E6705C


[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Which project to choose?

[Raymond Yau]

2010/7/14 Chris <cpollock@embarqmail.com>

> On Wed, 2010-07-14 at 07:26 +0800, Raymond Yau wrote:
> > 2010/7/14 Chris <cpollock@embarqmail.com>
> >
> > > I want to submit a bug report on the below. This issue was noted in
> > > Mandriva 2010 and is still present in 2010.1
> > >
> > > pulseaudio[24553]: alsa-util.c: snd_pcm_delay() returned a value that
> is
> > > exceptionally large: -161920 bytes (-917 ms).
> > > localhost pulseaudio[24553]: alsa-util.c: Most likely this is a bug in
> > > the ALSA driver 'snd_ens1371'. Please report this issue to the ALSA
> > > developers.
> > >
> >
> > This kind of bug report without a full pulseaudio log is almost useless
> > without a test case which can reproduce the bug,
> >
> >
> > > localhost pulseaudio[24553]: alsa-util.c: snd_pcm_dump():
> > > localhost pulseaudio[24553]: alsa-util.c: Hardware PCM card 0 'Ensoniq
> > > AudioPCI' device 0 subdevice 0
> > > localhost pulseaudio[24553]: alsa-util.c: Its setup is:
> > > localhost pulseaudio[24553]: alsa-util.c:   stream       : PLAYBACK
> > > localhost pulseaudio[24553]: alsa-util.c:   access       :
> > > MMAP_INTERLEAVED
> > > localhost pulseaudio[24553]: alsa-util.c:   format       : S16_LE
> > > localhost pulseaudio[24553]: alsa-util.c:   subformat    : STD
> > > localhost pulseaudio[24553]: alsa-util.c:   channels     : 2
> > > localhost pulseaudio[24553]: alsa-util.c:   rate         : 44100
> > > localhost pulseaudio[24553]: alsa-util.c:   exact rate   : 44101
> > > (1445100000/32768)
> > >
> >
> > The ens1371 cannot support exactly 44100
>
> Then Raymond, tell me, how do I stop this from happening? It just
> happens, I'm not playing any audio when it does. For instance
>
> Jul 13 17:29:39 localhost pulseaudio[24553]: ratelimit.c: 466 events
> suppressed
> Jul 13 17:29:39 localhost pulseaudio[24553]: asyncq.c: q overrun,
> queuing locally
> Jul 13 17:29:39 localhost pulseaudio[24553]: asyncq.c: q overrun,
> queuing locally
> Jul 13 17:29:39 localhost pulseaudio[24553]: asyncq.c: q overrun,
> queuing locally
> Jul 13 17:29:39 localhost pulseaudio[24553]: asyncq.c: q overrun,
> queuing locally
> Jul 13 17:29:39 localhost pulseaudio[24553]: asyncq.c: q overrun,
> queuing locally
> Jul 13 17:29:39 localhost pulseaudio[24553]: asyncq.c: q overrun,
> queuing locally
> Jul 13 17:29:39 localhost pulseaudio[24553]: asyncq.c: q overrun,
> queuing locally
> Jul 13 17:29:39 localhost pulseaudio[24553]: asyncq.c: q overrun,
> queuing locally
> Jul 13 17:29:39 localhost pulseaudio[24553]: asyncq.c: q overrun,
> queuing locally
> Jul 13 17:29:39 localhost pulseaudio[24553]: asyncq.c: q overrun,
> queuing locally
> Jul 13 17:29:39 localhost pulseaudio[24553]: asyncq.c: q overrun,
> queuing locally
> Jul 13 17:29:44 localhost pulseaudio[24553]: ratelimit.c: 497 events
> suppressed
>
> So, is this a pulseaudio issue or an Alsa issue?
>
>
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

Re: Which project to choose?

[Chris]

[-- Attachment #1.1: Type: text/plain, Size: 3377 bytes --]

On Wed, 2010-07-14 at 09:20 +0800, Raymond Yau wrote:
> 2010/7/14 Chris <cpollock@embarqmail.com>
> 
> > On Wed, 2010-07-14 at 07:26 +0800, Raymond Yau wrote:
> > > 2010/7/14 Chris <cpollock@embarqmail.com>
> > >
> > > > I want to submit a bug report on the below. This issue was noted in
> > > > Mandriva 2010 and is still present in 2010.1
> > > >
> > > > pulseaudio[24553]: alsa-util.c: snd_pcm_delay() returned a value that
> > is
> > > > exceptionally large: -161920 bytes (-917 ms).
> > > > localhost pulseaudio[24553]: alsa-util.c: Most likely this is a bug in
> > > > the ALSA driver 'snd_ens1371'. Please report this issue to the ALSA
> > > > developers.
> > > >
> > >
> > > This kind of bug report without a full pulseaudio log is almost useless
> > > without a test case which can reproduce the bug,
> > >
> > >
> > > > localhost pulseaudio[24553]: alsa-util.c: snd_pcm_dump():
> > > > localhost pulseaudio[24553]: alsa-util.c: Hardware PCM card 0 'Ensoniq
> > > > AudioPCI' device 0 subdevice 0
> > > > localhost pulseaudio[24553]: alsa-util.c: Its setup is:
> > > > localhost pulseaudio[24553]: alsa-util.c:   stream       : PLAYBACK
> > > > localhost pulseaudio[24553]: alsa-util.c:   access       :
> > > > MMAP_INTERLEAVED
> > > > localhost pulseaudio[24553]: alsa-util.c:   format       : S16_LE
> > > > localhost pulseaudio[24553]: alsa-util.c:   subformat    : STD
> > > > localhost pulseaudio[24553]: alsa-util.c:   channels     : 2
> > > > localhost pulseaudio[24553]: alsa-util.c:   rate         : 44100
> > > > localhost pulseaudio[24553]: alsa-util.c:   exact rate   : 44101
> > > > (1445100000/32768)
> > > >
> > >
> > > The ens1371 cannot support exactly 44100
> >
> > Then Raymond, tell me, how do I stop this from happening? It just
> > happens, I'm not playing any audio when it does. For instance
> >
> > Jul 13 17:29:39 localhost pulseaudio[24553]: ratelimit.c: 466 events
> > suppressed
> > Jul 13 17:29:39 localhost pulseaudio[24553]: asyncq.c: q overrun,
> > queuing locally
> > Jul 13 17:29:39 localhost pulseaudio[24553]: asyncq.c: q overrun,
> > queuing locally
> > Jul 13 17:29:39 localhost pulseaudio[24553]: asyncq.c: q overrun,
> > queuing locally
> > Jul 13 17:29:39 localhost pulseaudio[24553]: asyncq.c: q overrun,
> > queuing locally
> > Jul 13 17:29:39 localhost pulseaudio[24553]: asyncq.c: q overrun,
> > queuing locally
> > Jul 13 17:29:39 localhost pulseaudio[24553]: asyncq.c: q overrun,
> > queuing locally
> > Jul 13 17:29:39 localhost pulseaudio[24553]: asyncq.c: q overrun,
> > queuing locally
> > Jul 13 17:29:39 localhost pulseaudio[24553]: asyncq.c: q overrun,
> > queuing locally
> > Jul 13 17:29:39 localhost pulseaudio[24553]: asyncq.c: q overrun,
> > queuing locally
> > Jul 13 17:29:39 localhost pulseaudio[24553]: asyncq.c: q overrun,
> > queuing locally
> > Jul 13 17:29:39 localhost pulseaudio[24553]: asyncq.c: q overrun,
> > queuing locally
> > Jul 13 17:29:44 localhost pulseaudio[24553]: ratelimit.c: 497 events
> > suppressed
> >
> > So, is this a pulseaudio issue or an Alsa issue?
> >
> >
> 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?


-- 
Chris
KeyID 0xE372A7DA98E6705C


[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Which project to choose?

[Raymond Yau]

2010/7/14 Chris <cpollock@embarqmail.com>

> I want to submit a bug report on the below. This issue was noted in
> Mandriva 2010 and is still present in 2010.1
>
> pulseaudio[24553]: alsa-util.c: snd_pcm_delay() returned a value that is
> exceptionally large: -161920 bytes (-917 ms).
> localhost pulseaudio[24553]: alsa-util.c: Most likely this is a bug in
> the ALSA driver 'snd_ens1371'. Please report this issue to the ALSA
> developers.
> localhost pulseaudio[24553]: alsa-util.c: snd_pcm_dump():
> localhost pulseaudio[24553]: alsa-util.c: Hardware PCM card 0 'Ensoniq
> AudioPCI' device 0 subdevice 0
> localhost pulseaudio[24553]: alsa-util.c: Its setup is:
> localhost pulseaudio[24553]: alsa-util.c:   stream       : PLAYBACK
> localhost pulseaudio[24553]: alsa-util.c:   access       :
> MMAP_INTERLEAVED
> localhost pulseaudio[24553]: alsa-util.c:   format       : S16_LE
> localhost pulseaudio[24553]: alsa-util.c:   subformat    : STD
> localhost pulseaudio[24553]: alsa-util.c:   channels     : 2
> localhost pulseaudio[24553]: alsa-util.c:   rate         : 44100
> localhost pulseaudio[24553]: alsa-util.c:   exact rate   : 44101
> (1445100000/32768)
> localhost pulseaudio[24553]: alsa-util.c:   msbits       : 16
> localhost pulseaudio[24553]: alsa-util.c:   buffer_size  : 4408
> localhost pulseaudio[24553]: alsa-util.c:   period_size  : 1102
> localhost pulseaudio[24553]: alsa-util.c:   period_time  : 24988
> localhost pulseaudio[24553]: alsa-util.c:   tstamp_mode  : ENABLE
> localhost pulseaudio[24553]: alsa-util.c:   period_step  : 1
> localhost pulseaudio[24553]: alsa-util.c:   avail_min    : 1102
> localhost pulseaudio[24553]: alsa-util.c:   period_event : 1
> localhost pulseaudio[24553]: alsa-util.c:   start_threshold  : -1
> localhost pulseaudio[24553]: alsa-util.c:   stop_threshold   :
> 1155530752
> localhost pulseaudio[24553]: alsa-util.c:   silence_threshold: 0
> localhost pulseaudio[24553]: alsa-util.c:   silence_size : 0
> localhost pulseaudio[24553]: alsa-util.c:   boundary     : 1155530752
> localhost pulseaudio[24553]: alsa-util.c:   appl_ptr     : 735801008
> localhost pulseaudio[24553]: alsa-util.c:   hw_ptr       : 735846184
> localhost pulseaudio[24553]: ratelimit.c: 280 events suppressed
> localhost pulseaudio[24553]: asyncq.c: q overrun, queuing locally
>
> Because of the constant disk access when this is happening my system
> becomes almost unusable.
>
>
localhost pulseaudio[24553]: alsa-util.c:   appl_ptr     : 735801008
localhost pulseaudio[24553]: alsa-util.c:   hw_ptr       : 735846184

This is underrun as you can see appl_ptr is behing hw_ptr

However PA server had disabled the underrun detection.

Re: Which project to choose?

[Raymond Yau]

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

Re: Which project to choose?

[David Henningsson]

2010-07-14 13:13, Raymond Yau skrev:

> localhost pulseaudio[24553]: alsa-util.c:   appl_ptr     : 735801008
> localhost pulseaudio[24553]: alsa-util.c:   hw_ptr       : 735846184
> 
> This is underrun as you can see appl_ptr is behing hw_ptr

Ehm, isn't that a ring buffer? I e, there is nothing wrong with appl_ptr
being less than hw_ptr.

> However PA server had disabled the underrun detection.

Please clarify. If you're talking about my patch (disable underruns in
alsa-plugins) here, it has nothing to do with this situation (PA
complaining about its back-end).

The situation above probably isn't even an underrun.

// David

Re: Which project to choose?

[Jaroslav Kysela]

On Wed, 14 Jul 2010, David Henningsson wrote:

> 2010-07-14 13:13, Raymond Yau skrev:
>
>> localhost pulseaudio[24553]: alsa-util.c:   appl_ptr     : 735801008
>> localhost pulseaudio[24553]: alsa-util.c:   hw_ptr       : 735846184
>>
>> This is underrun as you can see appl_ptr is behing hw_ptr
>
> Ehm, isn't that a ring buffer? I e, there is nothing wrong with appl_ptr
> being less than hw_ptr.

For playback, if appl_ptr is less than hw_ptr, it's underrun situation 
(application didn't feed samples in time to the driver's ring buffer).

Note that pointers in ALSA are in range 0..boundary not 
0..ring_buffer_size (boundary is near LONG_MAX value) - it's design to 
detect such situations (underrun, overrun).

 						Jaroslav

-----
Jaroslav Kysela <perex@perex.cz>
Linux Kernel Sound Maintainer
ALSA Project, Red Hat, Inc.

Re: Which project to choose?

[David Henningsson]

2010-07-14 17:25, Jaroslav Kysela skrev:
> On Wed, 14 Jul 2010, David Henningsson wrote:
> 
>> 2010-07-14 13:13, Raymond Yau skrev:
>>
>>> localhost pulseaudio[24553]: alsa-util.c:   appl_ptr     : 735801008
>>> localhost pulseaudio[24553]: alsa-util.c:   hw_ptr       : 735846184
>>>
>>> This is underrun as you can see appl_ptr is behing hw_ptr
>>
>> Ehm, isn't that a ring buffer? I e, there is nothing wrong with appl_ptr
>> being less than hw_ptr.
> 
> For playback, if appl_ptr is less than hw_ptr, it's underrun situation
> (application didn't feed samples in time to the driver's ring buffer).
> 
> Note that pointers in ALSA are in range 0..boundary not
> 0..ring_buffer_size (boundary is near LONG_MAX value) - it's design to
> detect such situations (underrun, overrun).

Okay, thanks for the clarification. But LONG_MAX (as in 2^31) would
still wrap around every thirteen hours (at 44100 Hz), so are we having
bugs, such as e g failure to detect underruns, at those occasions?

// David

Re: Which project to choose?

[Jaroslav Kysela]

On Wed, 14 Jul 2010, David Henningsson wrote:

> 2010-07-14 17:25, Jaroslav Kysela skrev:
>> On Wed, 14 Jul 2010, David Henningsson wrote:
>>
>>> 2010-07-14 13:13, Raymond Yau skrev:
>>>
>>>> localhost pulseaudio[24553]: alsa-util.c:   appl_ptr     : 735801008
>>>> localhost pulseaudio[24553]: alsa-util.c:   hw_ptr       : 735846184
>>>>
>>>> This is underrun as you can see appl_ptr is behing hw_ptr
>>>
>>> Ehm, isn't that a ring buffer? I e, there is nothing wrong with appl_ptr
>>> being less than hw_ptr.
>>
>> For playback, if appl_ptr is less than hw_ptr, it's underrun situation
>> (application didn't feed samples in time to the driver's ring buffer).
>>
>> Note that pointers in ALSA are in range 0..boundary not
>> 0..ring_buffer_size (boundary is near LONG_MAX value) - it's design to
>> detect such situations (underrun, overrun).
>
> Okay, thanks for the clarification. But LONG_MAX (as in 2^31) would
> still wrap around every thirteen hours (at 44100 Hz), so are we having
> bugs, such as e g failure to detect underruns, at those occasions?

>From values above, it looks like a standard underrun (samples didn't 
arrive in time to the ring buffer). Just check 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.

 					Jaroslav

-----
Jaroslav Kysela <perex@perex.cz>
Linux Kernel Sound Maintainer
ALSA Project, Red Hat, Inc.

Re: Which project to choose?

[Chris]

[-- Attachment #1.1: Type: text/plain, Size: 2039 bytes --]

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



-- 
Chris
KeyID 0xE372A7DA98E6705C


[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Which project to choose?

[Raymond Yau]

2010/7/14 Chris <cpollock@embarqmail.com>

> On Wed, 2010-07-14 at 07:26 +0800, Raymond Yau wrote:
> > 2010/7/14 Chris <cpollock@embarqmail.com>
> >
>
>
> Then Raymond, tell me, how do I stop this from happening? It just
> happens, I'm not playing any audio when it does. For instance
>
> Jul 13 17:29:39 localhost pulseaudio[24553]: ratelimit.c: 466 events
> suppressed
> Jul 13 17:29:39 localhost pulseaudio[24553]: asyncq.c: q overrun,
> queuing locally
> Jul 13 17:29:39 localhost pulseaudio[24553]: asyncq.c: q overrun,
> queuing locally
> Jul 13 17:29:39 localhost pulseaudio[24553]: asyncq.c: q overrun,
> queuing locally
>


> Jul 13 17:29:39 localhost pulseaudio[24553]: asyncq.c: q overrun,
> queuing locally
> Jul 13 17:29:44 localhost pulseaudio[24553]: ratelimit.c: 497 events
> suppressed
>
> So, is this a pulseaudio issue or an Alsa issue?
>
>

You have to ask PA developer about "asyncq.c: q overrun,
queuing locally" , this seem to be asyncq_push() cannot be called twice and
I have no idea about this operation has any direct relationship with alsa

Re: Which project to choose?

[Chris]

[-- Attachment #1.1: Type: text/plain, Size: 1436 bytes --]

On Thu, 2010-07-15 at 06:32 +0800, Raymond Yau wrote:
> 2010/7/14 Chris <cpollock@embarqmail.com>
> 
> > On Wed, 2010-07-14 at 07:26 +0800, Raymond Yau wrote:
> > > 2010/7/14 Chris <cpollock@embarqmail.com>
> > >
> >
> >
> > Then Raymond, tell me, how do I stop this from happening? It just
> > happens, I'm not playing any audio when it does. For instance
> >
> > Jul 13 17:29:39 localhost pulseaudio[24553]: ratelimit.c: 466 events
> > suppressed
> > Jul 13 17:29:39 localhost pulseaudio[24553]: asyncq.c: q overrun,
> > queuing locally
> > Jul 13 17:29:39 localhost pulseaudio[24553]: asyncq.c: q overrun,
> > queuing locally
> > Jul 13 17:29:39 localhost pulseaudio[24553]: asyncq.c: q overrun,
> > queuing locally
> >
> 
> 
> > Jul 13 17:29:39 localhost pulseaudio[24553]: asyncq.c: q overrun,
> > queuing locally
> > Jul 13 17:29:44 localhost pulseaudio[24553]: ratelimit.c: 497 events
> > suppressed
> >
> > So, is this a pulseaudio issue or an Alsa issue?
> >
> >
> 
> You have to ask PA developer about "asyncq.c: q overrun,
> queuing locally" , this seem to be asyncq_push() cannot be called twice and
> I have no idea about this operation has any direct relationship with alsa
Raymond, can I send you the output log to look at? It's only 9k bzipp'd.
Maybe you can give me an idea of what I should do and whom I should
contact.

Thanks
Chris


-- 
Chris
KeyID 0xE372A7DA98E6705C


[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Which project to choose?

[Raymond Yau]

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.

Re: Which project to choose?

[Raymond Yau]

2010/7/14 David Henningsson <launchpad.web@epost.diwic.se>

> 2010-07-14 13:13, Raymond Yau skrev:
>
> > localhost pulseaudio[24553]: alsa-util.c:   appl_ptr     : 735801008
> > localhost pulseaudio[24553]: alsa-util.c:   hw_ptr       : 735846184
> >
> > This is underrun as you can see appl_ptr is behing hw_ptr
>
> Ehm, isn't that a ring buffer? I e, there is nothing wrong with appl_ptr
> being less than hw_ptr.
>

I think Jaroslav Kysela had already explained to you that this is an
underrun

The ring buffer size is only 4408 , appl_ptr is 45176 frames behind hw_ptr
and you can deduce the underrun occur for more than 1 second (45176/44100)

>> pulseaudio[24553]: alsa-util.c: snd_pcm_delay() returned a value that is
exceptionally large: -161920 bytes (-917 ms).



localhost pulseaudio[24553]: alsa-util.c:   buffer_size  : 4408
localhost pulseaudio[24553]: alsa-util.c:   period_size  : 1102
localhost pulseaudio[24553]: alsa-util.c:   period_time  : 24988

...

localhost pulseaudio[24553]: alsa-util.c:   start_threshold  : -1
localhost pulseaudio[24553]: alsa-util.c:   stop_threshold   :
1155530752



> > However PA server had disabled the underrun detection.
>
> Please clarify. If you're talking about my patch (disable underruns in
> alsa-plugins) here, it has nothing to do with this situation (PA
> complaining about its back-end).
>
>
This seem has no relationship to your patch which only ignore the client
side underrun

The PA server has already disabled underrun detection ( no-XRUN check mode )

http://thread.gmane.org/gmane.linux.alsa.devel/60371/focus=60531

It is the responsibility of PA server to ensure underrun/overrun would not
occur on the sound driver if it disabled underrun  detection

Re: Which project to choose?

[Chris]

[-- Attachment #1.1: Type: text/plain, Size: 905 bytes --]

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
-- 
Chris
KeyID 0xE372A7DA98E6705C


[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Which project to choose?

[Colin Guthrie]

'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.
> 
> https://qa.mandriva.com/show_bug.cgi?id=60169

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....


-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mandriva Linux Contributor [http://www.mandriva.com/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]

Re: Which project to choose?

[Raymond Yau]

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

http://www.pulseaudio.org/wiki/BrokenSoundDrivers

Re: Which project to choose?

[Jaroslav Kysela]

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.
>>
>> https://qa.mandriva.com/show_bug.cgi?id=60169
>
> 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.

Re: Which project to choose?

[Raymond Yau]

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.
> >
> > https://qa.mandriva.com/show_bug.cgi?id=60169
>
> 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

Re: Which project to choose?

[Chris]

[-- Attachment #1.1: Type: text/plain, Size: 1657 bytes --]

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.
> >>
> >> https://qa.mandriva.com/show_bug.cgi?id=60169
> >
> > 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.

-- 
Chris
KeyID 0xE372A7DA98E6705C


[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Which project to choose?

[Raymond Yau]

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.
> > >>
> > >> https://qa.mandriva.com/show_bug.cgi?id=60169
> > >
> > > 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.
>
>
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 ?

Re: Which project to choose?

[Chris]

[-- Attachment #1.1: Type: text/plain, Size: 2287 bytes --]

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.
> > > >>
> > > >> https://qa.mandriva.com/show_bug.cgi?id=60169
> > > >
> > > > 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.
> >
> >
> 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???

-- 
Chris
KeyID 0xE372A7DA98E6705C


[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Which project to choose?

[Raymond Yau]

2010/7/15 Jaroslav Kysela <perex@perex.cz>

> On Wed, 14 Jul 2010, David Henningsson wrote:
>
> > 2010-07-14 17:25, Jaroslav Kysela skrev:
> >> On Wed, 14 Jul 2010, David Henningsson wrote:
> >>
> >>> 2010-07-14 13:13, Raymond Yau skrev:
> >>>
> >>>> localhost pulseaudio[24553]: alsa-util.c:   appl_ptr     : 735801008
> >>>> localhost pulseaudio[24553]: alsa-util.c:   hw_ptr       : 735846184
> >>>>
> >>>> This is underrun as you can see appl_ptr is behing hw_ptr
> >>>
> >>> Ehm, isn't that a ring buffer? I e, there is nothing wrong with
> appl_ptr
> >>> being less than hw_ptr.
> >>
> >> For playback, if appl_ptr is less than hw_ptr, it's underrun situation
> >> (application didn't feed samples in time to the driver's ring buffer).
> >>
> >> Note that pointers in ALSA are in range 0..boundary not
> >> 0..ring_buffer_size (boundary is near LONG_MAX value) - it's design to
> >> detect such situations (underrun, overrun).
> >
> > Okay, thanks for the clarification. But LONG_MAX (as in 2^31) would
> > still wrap around every thirteen hours (at 44100 Hz), so are we having
> > bugs, such as e g failure to detect underruns, at those occasions?
>
> >From values above, it looks like a standard underrun (samples didn't
> arrive in time to the ring buffer). Just check 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.
>
>                                        Jaroslav
>

Looking  at the ens1371 specification , it seem to me that alsa-lib cannot
perform rewind too
I guess those 44101 rate is not really the best supported rate


4.2 Bus Master Cache Control (CCB)
This block control the transfer of data between the PCI memory and the
internal memory.
The Serial block signal when a cache fill/transfer is required in three
memory buffers

5.5 PCI Data transfer

Only brust read/write transfers are allowed. All data transfer are 8 Long
Word brust transfers

Re: Which project to choose?

[Chris]

[-- Attachment #1.1: Type: text/plain, Size: 2524 bytes --]

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.
> > > >>
> > > >> https://qa.mandriva.com/show_bug.cgi?id=60169
> > > >
> > > > 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.
> >
> >
> 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


-- 
Chris
KeyID 0xE372A7DA98E6705C


[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Which project to choose?

[Raymond Yau]

2010/7/15 Jaroslav Kysela <perex@perex.cz>

> On Wed, 14 Jul 2010, David Henningsson wrote:
>
> > 2010-07-14 17:25, Jaroslav Kysela skrev:
> >> On Wed, 14 Jul 2010, David Henningsson wrote:
> >>
> >>> 2010-07-14 13:13, Raymond Yau skrev:
> >>>
> >>>> localhost pulseaudio[24553]: alsa-util.c:   appl_ptr     : 735801008
> >>>> localhost pulseaudio[24553]: alsa-util.c:   hw_ptr       : 735846184
> >>>>
> >>>> This is underrun as you can see appl_ptr is behing hw_ptr
> >>>
> >>> Ehm, isn't that a ring buffer? I e, there is nothing wrong with
> appl_ptr
> >>> being less than hw_ptr.
> >>
> >> For playback, if appl_ptr is less than hw_ptr, it's underrun situation
> >> (application didn't feed samples in time to the driver's ring buffer).
> >>
> >> Note that pointers in ALSA are in range 0..boundary not
> >> 0..ring_buffer_size (boundary is near LONG_MAX value) - it's design to
> >> detect such situations (underrun, overrun).
> >
> > Okay, thanks for the clarification. But LONG_MAX (as in 2^31) would
> > still wrap around every thirteen hours (at 44100 Hz), so are we having
> > bugs, such as e g failure to detect underruns, at those occasions?
>
> >From values above, it looks like a standard underrun (samples didn't
> arrive in time to the ring buffer). Just check 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.
>
>                                        Jaroslav
>

If "AC97 2ch->4ch Copy Switch" is specific to ens1373 , this mean ens1373
will need to has  it own ENS1371.conf

static struct snd_kcontrol_new snd_ens1373_rear __devinitdata =
{
    .iface =    SNDRV_CTL_ELEM_IFACE_MIXER,
    .name =        "AC97 2ch->4ch Copy Switch",
    .info =        snd_es1373_rear_info,
    .get =        snd_es1373_rear_get,
    .put =        snd_es1373_rear_put,
};


ENS1371.pcm.rear.0 {
       @args [ CARD ]
       @args.CARD {
               type string
       }
       type hooks
        slave.pcm {
               type hw
               card $CARD
               device 1
       }
       hooks.0 {
               type ctl_elems
                hook_args [
                        {
                               interface MIXER
                               name "AC97 2ch->4ch Copy Switch"
                               lock true
                               preserve true
                                value 0
                      }
               ]
       }


http://git.alsa-project.org/?p=alsa-lib.git;a=blobdiff;f=src/conf/cards/ENS1371.conf;h=5c0de7d44ba5cc3f6761ba5a7c3250467a65a8e5;hp=a9499dae963090bdb408620659ac98989bb8bc3d;hb=a8a71d5781e7cc53bf9ff9ce75d2b93883297bea;hpb=50212fde09291eeffc7e48082d7bf4b7d713a80b

Re: Which project to choose?

[Jaroslav Kysela]

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.
>>>>>>
>>>>>> https://qa.mandriva.com/show_bug.cgi?id=60169
>>>>>
>>>>> 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.
>>>
>>>
>> 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.

Re: Which project to choose?

[Jaroslav Kysela]

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.
>>>>
>>>> https://qa.mandriva.com/show_bug.cgi?id=60169
>>>
>>> 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.

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.

Re: Which project to choose?

[Raymond Yau]

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.
> >>>>
> >>>> https://qa.mandriva.com/show_bug.cgi?id=60169
> >>>
> >>> 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.
>
> 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=4df443bbe682055a41e7c2248877dcc7682a69b8

Re: Which project to choose?

[Raymond Yau]

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.
> >
> > https://qa.mandriva.com/show_bug.cgi?id=60169
>
> 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!

Re: Which project to choose?

[Chris]

[-- Attachment #1.1: Type: text/plain, Size: 2399 bytes --]

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.
> > >
> > > https://qa.mandriva.com/show_bug.cgi?id=60169
> >
> > 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

-- 
Chris
KeyID 0xE372A7DA98E6705C


[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Which project to choose?

[Raymond Yau]

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

Re: Which project to choose?

[Colin Guthrie]

'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 Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mandriva Linux Contributor [http://www.mandriva.com/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]

Re: Which project to choose?

[Chris]

[-- Attachment #1.1: Type: text/plain, Size: 2792 bytes --]

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:

http://ez-files.net/953712

Does this have any meaning?

Thanks for any assistance.

Chris

-- 
Chris
KeyID 0xE372A7DA98E6705C


[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Which project to choose?

[Raymond Yau]

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:
>
> http://ez-files.net/953712
>
> 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

Re: Which project to choose?

[Chris]

[-- Attachment #1.1: Type: text/plain, Size: 4356 bytes --]

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:
> >
> > http://ez-files.net/953712
> >
> > 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:

http://ez-files.net/135882



-- 
Chris
KeyID 0xE372A7DA98E6705C


[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Which project to choose?

[Raymond Yau]

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:
> > >
> > > http://ez-files.net/953712
> > >
> > > 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:
>
> http://ez-files.net/135882
>
>
>
>
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

Re: Which project to choose?

[Chris]

[-- Attachment #1.1: Type: text/plain, Size: 5030 bytes --]

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


-- 
Chris
KeyID 0xE372A7DA98E6705C


[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Which project to choose?

[Chris]

[-- Attachment #1.1: Type: text/plain, Size: 7123 bytes --]

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..


-- 
Chris
KeyID 0xE372A7DA98E6705C


[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Which project to choose?

[Raymond Yau]

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

Re: Which project to choose?

[Chris]

[-- Attachment #1.1: Type: text/plain, Size: 2710 bytes --]

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:

http://pastebin.com/db20pXi9


-- 
Chris
KeyID 0xE372A7DA98E6705C


[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Which project to choose?

[Raymond Yau]

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:
>
> http://pastebin.com/db20pXi9
>
>
>
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);

Re: Which project to choose?

[Chris]

[-- Attachment #1.1: Type: text/plain, Size: 2392 bytes --]

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:
> >
> > http://pastebin.com/db20pXi9
> >
> >
> >


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.

http://pastebin.com/3JwveDsJ

-- 
Chris
KeyID 0xE372A7DA98E6705C


[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Which project to choose?

[Raymond Yau]

2010/7/22 Chris <cpollock@embarqmail.com>

> On Thu, 2010-07-22 at 11:03 +0800, Raymond Yau wrote:
> >
> >
> > 2010/7/22 Chris <cpollock@embarqmail.com>
> >
> >
> >         >
> >         > AFAIK, the most buggy PA client is pavucontrol because
> >         >
> >         > 1) it has those vumeters which need to get audio data from
> >         the
> >         > playback and capture devices of the sound card ,
> >         > 2) when you move the slider to left ( over 100%) and this
> >         force PA to
> >         > provide software gain
> >         >
> >         > You should notice that the new gnome-volume-control is
> >         actually a
> >         > simplified version of pavucontrol
> >
> >
> >         Hmm, I just pulled up PulseAudio Volume Control and see no
> >         vumeters, I
> >         can't figure out though why the drive thrashing at various
> >         times whether
> >         I have a stream playing or not.
> >
> >
> > Did you click the input device tab page of the gnome volume control ?
> >
> > The vumeter is "Input level"  above the volume control slider ?
> >
> > You should noticed that the following message appear in the pulseaudio
> > log
> >
> > I: source-output.c : Created output 0 "Peak detect" on alsa_input
> >
> > I.source-output:c    application.id = "org.gnome.volume.control"
> > I.source-output:c    media.name = "Peak detect"
> > I.source-output:c    application.name = "GNOME Volume control dialog"
> >
> > when you using mplayer to play music and open pavucontrol to
> >
> > pavucontrol sometime abort suddenly  when you aborte mplayer but this
> > is not 100% reproducible
> >
> > pavucontrol
> > ** ( pavucontrol:3232) : DEBUG: failed to initialize device manager
> > extension: No such extension
> > ** (pavucontrol:3056) : DEBUG: Ignoring sink-input due to it being
> > designated as an event and thuse handled by the event widget
> >
> >
> > The point is after the complete intergration of pulseaudio in to the
> > system ( libcanberra, mixer-applet , ... )
> >
> > I think "pulseaudio -k; pulseaudio -vvvv" is no longer the correct way
> > to debug since there are lots of PA clients running at the desktop
> >
> > You have to ask the mandriva maintainer how to increase the debug
> > level of PA server and have to perform a logout/login to debug the PA
> > server
>
> Thanks Raymond, so I should contact Colin and go from there? I'm not
> sure what to even tell him though. I thank you for all your help.
>
> Chris
>

There are over 15 PA clients running when you are using gnome desktop

running  "pulseaudio -k  " to shutdown PA server , this kill all the PA
clients
restart PA  server by  "pulseaudio -vvvv" , only one or two PA clients (e.g.
consolekit, .. ) can connected back to PA server

This command "pulseaudio -k;pulseaudio -vvvv" cannot  provide a normal
environment to debug PA server since most of PA clients are killed

Re: Which project to choose?

[Raymond Yau]

2010/7/14 David Henningsson <launchpad.web@epost.diwic.se>

> 2010-07-14 13:13, Raymond Yau skrev:
>
> > localhost pulseaudio[24553]: alsa-util.c:   appl_ptr     : 735801008
> > localhost pulseaudio[24553]: alsa-util.c:   hw_ptr       : 735846184
> >
> > This is underrun as you can see appl_ptr is behing hw_ptr
>
> Ehm, isn't that a ring buffer? I e, there is nothing wrong with appl_ptr
> being less than hw_ptr.
>
> > However PA server had disabled the underrun detection.
>
> Please clarify. If you're talking about my patch (disable underruns in
> alsa-plugins) here, it has nothing to do with this situation (PA
> complaining about its back-end).
>
> The situation above probably isn't even an underrun.
>


The other possible reason may be PA did not handle clock drifting properly

how did PA calculate the sleeping time using 44100 or 1445100000/32768 ? ,

ens1371 's clock is running faster than the system clock

localhost pulseaudio[24553]: alsa-util.c:   rate         : 44100
localhost pulseaudio[24553]: alsa-util.c:   exact rate   : 44101
(1445100000/32768)

Re: Which project to choose?

[Raymond Yau]

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.
> >
> > https://qa.mandriva.com/show_bug.cgi?id=60169
>
> 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
?

Re: Which project to choose?

[Colin Guthrie]

'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.
>>>
>>> https://qa.mandriva.com/show_bug.cgi?id=60169
>>
>> 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

-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mandriva Linux Contributor [http://www.mandriva.com/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]

Re: Which project to choose?

[Raymond Yau]

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.
> >>>
> >>> https://qa.mandriva.com/show_bug.cgi?id=60169
> >>
> >> 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

Re: Which project to choose?

[Raymond Yau]

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.
>> >>>
>> >>> https://qa.mandriva.com/show_bug.cgi?id=60169
>> >>
>> >> 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