[alsa-devel] Which project to choose?
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.
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
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?
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
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?
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
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
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.
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
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.
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
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.
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
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/ENS1...
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
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)
participants (4)
-
Chris -
David Henningsson -
Jaroslav Kysela -
Raymond Yau