Re: [alsa-devel] hw_ptr accuracy with intel8x0 -> PulseAudio issue
2009/12/4 pl bossart bossart.nospam@gmail.com
Hi Raymond, comments below.
- PL
On Wed, Dec 2, 2009 at 8:26 PM, Raymond Yau superquad.vortex2@gmail.com wrote:
- D: alsa-util.c: Trying front:0 with SND_PCM_NO_AUTO_FORMAT ...
- D: alsa-util.c: Managed to open front:0
- D: alsa-util.c: Maximum hw buffer size is 371 ms
- D: alsa-util.c: Set buffer size first (to 4408 samples), period size
second (to 1102 samples)
What is the purpose of these buffer-size and period size during the
probing
phase ? The PA server seem use different values
This is a red herring, PulseAudio tries to open multiple profiles and finds out which ones make sense. You want to look at the result below which is the final configuration.
- I: sink.c: Created sink 0
"alsa_output.pci-0000_00_1e.2.analog-stereo"
with sample spec s16le 2ch 44100Hz and channel map
front-left,front-right
- I: sink.c: alsa.resolution_bits = "16"
- I: sink.c: device.api = "alsa"
- I: sink.c: device.class = "sound"
- I: sink.c: alsa.class = "generic"
- I: sink.c: alsa.subclass = "generic-mix"
- I: sink.c: alsa.name = "Intel ICH6"
- I: sink.c: alsa.id = "Intel ICH"
- I: sink.c: alsa.subdevice = "0"
- I: sink.c: alsa.subdevice_name = "subdevice #0"
- I: sink.c: alsa.device = "0"
- I: sink.c: alsa.card = "0"
- I: sink.c: alsa.card_name = "Intel ICH6"
- I: sink.c: alsa.long_card_name = "Intel ICH6 with AD1981B at
irq
22" 15. I: sink.c: alsa.driver_name = "snd_intel8x0" 16. I: sink.c: device.bus_path = "pci-0000:00:1e.2" 17. I: sink.c: sysfs.path = "/devices/pci0000:00/0000:00:1e.2/sound/card0" 18. I: sink.c: device.bus = "pci" 19. I: sink.c: device.vendor.id = "8086" 20. I: sink.c: device.vendor.name = "Intel Corporation" 21. I: sink.c: device.product.id = "266e" 22. I: sink.c: device.product.name = "82801FB/FBM/FR/FW/FRW (ICH6 Family) AC'97 Audio Controller" 23. I: sink.c: device.form_factor = "internal" 24. I: sink.c: hal.udi = "/org/freedesktop/Hal/devices/pci_8086_266e_sound_card_0" 25. I: sink.c: hal.product = "Intel ICH6 with AD1981B Sound Card" 26. I: sink.c: hal.card_id = "Intel ICH6 with AD1981B" 27. I: sink.c: device.string = "front:0" 28. I: sink.c: device.buffering.buffer_size = "65536" 29. I: sink.c: device.buffering.fragment_size = "65536" 30. I: sink.c: device.access_mode = "mmap+timer" 31. I: sink.c: device.profile.name = "analog-stereo" 32. I: sink.c: device.profile.description = "Analog Stereo" 33. I: sink.c: device.description = "Internal Audio Analog Stereo" 34. I: sink.c: alsa.mixer_name = "Analog Devices AD1981B" 35. I: sink.c: alsa.components = "AC97a:41445374" 36. I: sink.c: module-udev-detect.discovered = "1" 37. I: sink.c: device.icon_name = "audio-card-pci"
intel8x0 does not has hdmi , it seem PA hardcode hdmi for all sound cards instead of using namehint for playback device
Yes, PA will try all possible profiles. Not that smart but unrelated to my problem.
Is it possible to add timestamp in alsa-sink.c: Wrote 31792 bytes (of possible 31792 bytes) statement for debugging
Not sure why this is needed. In that case the driver reports 7948 frames are available, which translates to 31792 bytes. The problem shows in the next call to snd_pcm_avail down to the kernel level, PA only uses the misleading information reported by the driver.
- hwptr 24351 buffer 16384 appl 24332, avail=16403
appl pointer is behind hwprtr ( underrun ) , need timestamp to find out whether PA is unable to write audio data in time since
- D: alsa-sink.c: Not filling up, because too early.
- D: alsa-sink.c: Wakeup from ALSA!
- D: alsa-sink.c: Loop
- D: alsa-sink.c: Buffer time: 371 ms; Sleep time: 351 ms; Process
time: 20 ms
did it adjust the sleeping time when it think too early ?
- D: alsa-sink.c: Loop
- D: alsa-sink.c: Buffer time: 371 ms; Sleep time: 351 ms; Process
time:
20 ms 3. hwptr 7948 buffer 16384 appl 16384, avail=7948 4. D: alsa-sink.c: avail: 31792 (samples 7948) 5. D: alsa-sink.c: 191.29 ms left to play; inc threshold = 0.00 ms; dec threshold = 100.00 ms 6. D: alsa-sink.c: Filling up 7. hwptr 7948 buffer 16384 appl 16384, avail=7948 8. hwptr 7948 buffer 16384 appl 16384, avail=7948 9. D: alsa-sink.c: Wrote 31792 bytes (of possible 31792 bytes) 10. hwptr 7960 buffer 16384 appl 24332, avail=12 11. D: alsa-sink.c: avail: 48 (samples 12) 12. D: alsa-sink.c: 371.25 ms left to play; inc threshold = 0.00 ms;
dec
threshold = 100.00 ms 13. D: alsa-sink.c: Not filling up, because too early. 14. D: alsa-sink.c: Wakeup from ALSA! 15. D: alsa-sink.c: Loop 16. D: alsa-sink.c: Buffer time: 371 ms; Sleep time: 351 ms; Process time: 20 ms 17. hwptr 24351 buffer 16384 appl 24332, avail=16403 18. E: alsa-util.c: avail 16403 delay -19 19. D: alsa-sink.c: avail: 65536 (samples 16384) 20. D: alsa-sink.c: 0.00 ms left to play; inc threshold = 0.00 ms; dec threshold = 100.00 ms 21. D: alsa-sink.c: Filling up
17. hwptr 24351 buffer 16384 appl 24332, avail=16403
appl pointer is behind hwprtr ( underrun ) , need timestamp to find out whether PA is unable to write audio data in time since
Nah, it's not an audio underflow. In the default PulseAudio code, the timer value is increased by 20ms each time this errror condition is reached. PA ends-up waking-up 150ms or so before the deadline and yet it still encounters this error. I don't think it's a problem with PA not refilling the buffer on time, it's more that the information provided by snd_pcm_avail() is misleading. I commented out the portion of the code that increases the watermark and clamped the number of available samples to the buffer size, and it works just fine, no audio underflows. - P
2009/12/4 pl bossart bossart.nospam@gmail.com
- hwptr 24351 buffer 16384 appl 24332, avail=16403
appl pointer is behind hwprtr ( underrun ) , need timestamp to find out whether PA is unable to write audio data in time since
Nah, it's not an audio underflow. In the default PulseAudio code, the timer value is increased by 20ms each time this errror condition is reached. PA ends-up waking-up 150ms or so before the deadline and yet it still encounters this error. I don't think it's a problem with PA not refilling the buffer on time, it's more that the information provided by snd_pcm_avail() is misleading. I commented out the portion of the code that increases the watermark and clamped the number of available samples to the buffer size, and it works just fine, no audio underflows.
- P
Since PA use one period per buffer for intel8x0 ( the hwptr is already at the outside of the buffer )
It is hard to debug without timestamp since it is not easy to know the value of sleeping time
Can you explain what is "hwbuf_unused" ?
1. I: alsa-sink.c: Using 1.0 fragments of size 65536 bytes (371.52ms), buffer size is 65536 bytes (371.52ms) 2. I: alsa-sink.c: Time scheduling watermark is 20.00ms 3. D: alsa-sink.c: hwbuf_unused=0 4. D: alsa-sink.c: Buffer time: 371 ms; Sleep time: 351 ms; Process time: 20 ms 5. D: alsa-sink.c: setting avail_min=15502 6. D: alsa-mixer.c: Activating path analog-output 7. D: alsa-mixer.c: Path analog-output (Analog Output), direction=1, priority=99, probed=yes, supported=yes, has_mute=yes, has_volume=yes, has_dB=yes, min_volume=0, max_volume=31, min_dB=-81, max_dB=12 8. D: alsa-mixer.c: Element Master, direction=1, switch=1, volume=1, enumeration=0, required=0, required_absent=0, mask=0x3600000000f66, n_channels=2, override_map=yes 9. D: alsa-mixer.c: Element Master Mono, direction=1, switch=2, volume=2, enumeration=0, required=0, required_absent=0, mask=0x7ffffffffffff, n_channels=1, override_map=no 10. D: alsa-mixer.c: Element Headphone, direction=1, switch=1, volume=3, enumeration=0, required=0, required_absent=0, mask=0x6, n_channels=2, override_map=no 11. D: alsa-mixer.c: Element PCM, direction=1, switch=1, volume=1, enumeration=0, required=0, required_absent=0, mask=0x402b600000000f66, n_channels=2, override_map=yes 12. D: alsa-mixer.c: Element External Amplifier, direction=1, switch=4, volume=0, enumeration=0, required=0, required_absent=0, mask=0x0, n_channels=0, override_map=no 13. D: alsa-mixer.c: Option on (output-amplifier-on/Amplifier) index=1, priority=10 14. D: alsa-mixer.c: Option off (output-amplifier-off/No Amplifier) index=0, priority=0 15. D: alsa-mixer.c: Setting output-amplifier-on (Amplifier) priority=10 16. D: alsa-mixer.c: Setting output-amplifier-off (No Amplifier) priority=0 17. I: alsa-sink.c: Hardware volume ranges from -81.00 dB to 12.00 dB. 18. I: alsa-sink.c: Fixing base volume to -12.00 dB 19. I: alsa-sink.c: Using hardware volume control. Hardware dB scale supported. 20. I: alsa-sink.c: Using hardware mute control. 21. D: alsa-util.c: snd_pcm_dump(): 22. D: alsa-util.c: Hardware PCM card 0 'Intel ICH6' device 0 subdevice 0 23. D: alsa-util.c: Its setup is: 24. D: alsa-util.c: stream : PLAYBACK 25. D: alsa-util.c: access : MMAP_INTERLEAVED 26. D: alsa-util.c: format : S16_LE 27. D: alsa-util.c: subformat : STD 28. D: alsa-util.c: channels : 2 29. D: alsa-util.c: rate : 44100 30. D: alsa-util.c: exact rate : 44100 (44100/1) 31. D: alsa-util.c: msbits : 16 32. D: alsa-util.c: buffer_size : 16384 33. D: alsa-util.c: period_size : 16384 34. D: alsa-util.c: period_time : 371519 35. D: alsa-util.c: tstamp_mode : ENABLE 36. D: alsa-util.c: period_step : 1 37. D: alsa-util.c: avail_min : 16384 38. D: alsa-util.c: period_event : 0 39. D: alsa-util.c: start_threshold : -1 40. D: alsa-util.c: stop_threshold : 1073741824 41. D: alsa-util.c: silence_threshold: 0 42. D: alsa-util.c: silence_size : 0 43. D: alsa-util.c: boundary : 1073741824 44. D: alsa-util.c: appl_ptr : 0 45. D: alsa-util.c: hw_ptr : 0 46. D: alsa-sink.c: Requested volume: 0: 3% 1: 3% 47. D: alsa-sink.c: Got hardware volume: 0: 3% 1: 3% 48. D: alsa-sink.c: Calculated software volume: 0: 100% 1: 100% (accurate-enough=yes) 49. D: alsa-sink.c: Thread starting up 50. I: core-util.c: Successfully enabled SCHED_RR scheduling for thread, with priority 4, which is lower than the requested 5. 51. D: alsa-sink.c: Loop 52. D: alsa-sink.c: Loop 53. D: alsa-sink.c: Buffer time: 371 ms; Sleep time: 351 ms; Process time: 20 ms 54. hwptr 0 buffer 16384 appl 0, avail=16384 55. D: alsa-sink.c: avail: 65536 (samples 16384) 56. D: alsa-sink.c: 0.00 ms left to play; inc threshold = 0.00 ms; dec threshold = 100.00 ms 57. D: alsa-sink.c: Filling up 58. hwptr 0 buffer 16384 appl 0, avail=16384 59. hwptr 0 buffer 16384 appl 0, avail=16384 60. D: alsa-sink.c: Wrote 65496 bytes (of possible 65536 bytes) 61. hwptr 0 buffer 16384 appl 16374, avail=10 62. hwptr 0 buffer 16384 appl 16374, avail=10 63. D: alsa-sink.c: Wrote 40 bytes (of possible 40 bytes) 64. hwptr 0 buffer 16384 appl 16384, avail=0 65. D: alsa-sink.c: avail: 0 (samples 0) 66. D: alsa-sink.c: 371.52 ms left to play; inc threshold = 0.00 ms; dec threshold = 100.00 ms 67. D: alsa-sink.c: Not filling up, because too early. 68. I: alsa-sink.c: Starting playback. 69. D: alsa-sink.c: Cutting sleep time for the initial iterations by half.
In the default PulseAudio code, the
timer value is increased by 20ms each time this errror condition is reached.
D: alsa-sink.c: Cutting sleep time for the initial iterations by half.
Are you sure the time value is increased by 20 ms in pulseaudio-0.9.21 ?
My au8830 work quite well on pulseaudio-0.9.14 ( Fedora 10 ) with 2 fragments
D: module-hal-detect.c: Loading module-alsa-sink with arguments 'device_id=0 sink_name=alsa_output.pci_12eb_2_sound_card_0_alsa_playback_0 tsched=1'
D: alsa-util.c: Trying front:0 with SND_PCM_NO_AUTO_FORMAT ... D: alsa-util.c: Maximum hw buffer size is 371 ms I: module-alsa-sink.c: Successfully opened device front:0. I: module-alsa-sink.c: Successfully enabled mmap() mode. I: module-alsa-sink.c: Successfully enabled timer-based scheduling mode. I: (alsa-lib)control.c: Invalid CTL front:0 I: alsa-util.c: Unable to attach to mixer front:0: No such file or directory I: alsa-util.c: Successfully attached to mixer 'hw:0' I: alsa-util.c: Using mixer control "Master". I: sink.c: Created sink 0 "alsa_output.pci_12eb_2_sound_card_0_alsa_playback_0" with sample spec s16le 2ch 44100Hz and channel map front-left,front-right I: source.c: Created source 0 "alsa_output.pci_12eb_2_sound_card_0_alsa_playback_0.monitor" with sample spec s16le 2ch 44100Hz and channel map front-left,front-right I: module-alsa-sink.c: Using 2 fragments of size 4096 bytes, buffer time is 46.44ms I: module-alsa-sink.c: Time scheduling watermark is 20.00ms D: module-alsa-sink.c: hwbuf_unused_frames=0 D: module-alsa-sink.c: setting avail_min=4661 I: module-alsa-sink.c: Volume ranges from 0 to 31. I: module-alsa-sink.c: Volume ranges from -46.50 dB to 0.00 dB. I: alsa-util.c: All 2 channels can be mapped to mixer channels. I: module-alsa-sink.c: Using hardware volume control. Hardware dB scale supported. D: alsa-util.c: snd_pcm_dump(): D: alsa-util.c: Hardware PCM card 0 'Aureal Vortex au8830' device 0 subdevice 0 D: alsa-util.c: Its setup is: D: alsa-util.c: stream : PLAYBACK D: alsa-util.c: access : MMAP_INTERLEAVED D: alsa-util.c: format : S16_LE D: alsa-util.c: subformat : STD D: alsa-util.c: channels : 2 D: alsa-util.c: rate : 44100 D: alsa-util.c: exact rate : 44100 (44100/1) D: alsa-util.c: msbits : 16 D: alsa-util.c: buffer_size : 2048 D: alsa-util.c: period_size : 1024 D: alsa-util.c: period_time : 23219 D: alsa-util.c: tstamp_mode : NONE D: alsa-util.c: period_step : 1 D: alsa-util.c: avail_min : 4661 D: alsa-util.c: period_event : 0 D: alsa-util.c: start_threshold : -1 D: alsa-util.c: stop_threshold : -1 D: alsa-util.c: silence_threshold: 0 D: alsa-util.c: silence_size : 0 D: alsa-util.c: boundary : 1073741824 D: alsa-util.c: appl_ptr : 0 D: alsa-util.c: hw_ptr : 0 D: module-alsa-sink.c: Read hardware volume: 0: 72% 1: 72% D: module-alsa-sink.c: Thread starting up D: rtpoll.c: Acquired POSIX realtime signal SIGRTMIN+29 I: module-alsa-sink.c: Starting playback.
https://bugtrack.alsa-project.org/alsa-bug/view.php?id=4776
hyper_sonic 's au8830 a bit lagged .But if switch to integrated i8x0 sound chip music played very well. on pulseaudio 0.9.19 ( 16 fragments )
I: alsa-sink.c: Using 16,0 fragments of size 4096 bytes (23,22ms), buffer size is 65536 bytes (371,52ms) I: alsa-sink.c: Time scheduling watermark is 20,00ms D: alsa-sink.c: hwbuf_unused=0 D: alsa-sink.c: setting avail_min=15502 D: alsa-mixer.c: Activating path analog-output-lfe-on-mono D: alsa-mixer.c: Path analog-output-lfe-on-mono (Analog Output (LFE)), direction=1, priority=40, probed=yes, supported=yes, has_mute=yes, has_volume=yes, has_dB=yes, min_volume=0, max_volume=31, min_dB=-81, max_dB=12 D: alsa-mixer.c: Element Master, direction=1, switch=1, volume=1, enumeration=0, required=0, required_absent=0, mask=0x3600000000f66, n_channels=2, override_map=yes D: alsa-mixer.c: Element Master Mono, direction=1, switch=1, volume=1, enumeration=0, required=4, required_absent=0, mask=0x80, n_channels=1, override_map=yes D: alsa-mixer.c: Element PCM, direction=1, switch=1, volume=1, enumeration=0, required=0, required_absent=0, mask=0x402b600000000f66, n_channels=2, override_map=yes D: alsa-mixer.c: Element External Amplifier, direction=1, switch=4, volume=0, enumeration=0, required=0, required_absent=0, mask=0x0, n_channels=0, override_map=no D: alsa-mixer.c: Option on (output-amplifier-on/Amplifier) index=1, priority=10 D: alsa-mixer.c: Option off (output-amplifier-off/No Amplifier) index=0, priority=0 D: alsa-mixer.c: Setting output-amplifier-on (Amplifier) priority=10 D: alsa-mixer.c: Setting output-amplifier-off (No Amplifier) priority=0 I: alsa-sink.c: Hardware volume ranges from -81,00 dB to 12,00 dB. I: alsa-sink.c: Fixing base volume to -12,00 dB I: alsa-sink.c: Using hardware volume control. Hardware dB scale supported. I: alsa-sink.c: Using hardware mute control. D: alsa-util.c: snd_pcm_dump(): D: alsa-util.c: Hardware PCM card 1 'Aureal Vortex au8830' device 0 subdevice 0 D: alsa-util.c: Its setup is: D: alsa-util.c: stream : PLAYBACK D: alsa-util.c: access : MMAP_INTERLEAVED D: alsa-util.c: format : S16_LE D: alsa-util.c: subformat : STD D: alsa-util.c: channels : 2 D: alsa-util.c: rate : 44100 D: alsa-util.c: exact rate : 44100 (44100/1) D: alsa-util.c: msbits : 16 D: alsa-util.c: buffer_size : 16384 D: alsa-util.c: period_size : 1024 D: alsa-util.c: period_time : 23219 D: alsa-util.c: tstamp_mode : ENABLE D: alsa-util.c: period_step : 1 D: alsa-util.c: avail_min : 15502 D: alsa-util.c: period_event : 0 D: alsa-util.c: start_threshold : -1 D: alsa-util.c: stop_threshold : 1073741824 D: alsa-util.c: silence_threshold: 0 D: alsa-util.c: silence_size : 0 D: alsa-util.c: boundary : 1073741824 D: alsa-util.c: appl_ptr : 0 D: alsa-util.c: hw_ptr : 0 D: alsa-sink.c: Thread starting up I: core-util.c: Successfully enabled SCHED_RR scheduling for thread, with priority 4, which is lower than the requested 5. D: alsa-sink.c: Requested volume: 0: 23% 1: 23% D: alsa-sink.c: Got hardware volume: 0: 24% 1: 24% D: alsa-sink.c: Calculated software volume: 0: 97% 1: 97% (accurate-enough=no) I: alsa-sink.c: Starting playback. D: alsa-sink.c: Cutting sleep time for the initial iterations by half. D: alsa-sink.c: Cutting sleep time for the initial iterations by half. D: alsa-sink.c: Cutting sleep time for the initial iterations by half.
PA ends-up waking-up 150ms or so before the deadline and yet it still encounters this error. I don't think it's a problem with PA not refilling the buffer on time, it's more that the information provided by snd_pcm_avail() is misleading. I commented out the portion of the code that increases the watermark and clamped the number of available samples to the buffer size, and it works just fine, no audio underflows.
- P
Adding the timestamp is the easy way to prove the pulseaudio is writing the audio in time
The problem may be the timer is not running at the same rate as the sound card 's clock
or
snd_pcm_rewindable() and snd_pcm_rewind() has bug since PA server is the only application use snd_pcm_rewind()
http://thread.gmane.org/gmane.linux.alsa.devel/66826/focus=66952
Unfortunately there is no test program to test the snd_pcm_rewind() function
http://thread.gmane.org/gmane.linux.alsa.devel/59470/focus=59641
PCI audio controllers fetch audio from memory in brust mode (i.e. fetch data must faster than sampling rate 48000Hz) , it is doubt that the application can really rewind the application pointer to hardware pointer and perform an immedate rewrite
2009/12/4 pl bossart bossart.nospam@gmail.com
- hwptr 24351 buffer 16384 appl 24332, avail=16403
appl pointer is behind hwprtr ( underrun ) , need timestamp to find out whether PA is unable to write audio data in time since
I commented out the portion of the code that increases the watermark and clamped the number of available samples to the buffer size, and it works just fine, no audio underflows.
Do you mean that the underrun is related the the portion of code that increase the watermark (i.e It is a pulseaudio bug instead of driver bug ) ?
At Sat, 5 Dec 2009 10:17:07 +0800, Raymond Yau wrote:
2009/12/4 pl bossart bossart.nospam@gmail.com
- hwptr 24351 buffer 16384 appl 24332, avail=16403
appl pointer is behind hwprtr ( underrun ) , need timestamp to find out whether PA is unable to write audio data in time since
I commented out the portion of the code that increases the watermark and clamped the number of available samples to the buffer size, and it works just fine, no audio underflows.
Do you mean that the underrun is related the the portion of code that increase the watermark (i.e It is a pulseaudio bug instead of driver bug ) ?
Or, we can try simply to change to periods_min = 2 whether this fixes the PA issues.
periods_min = 1 is anyway fairly fragile. With that setup, apps are supposed (implicitly) to wake up frequently enough to get pointers in sync. This is because you can't trust whether the IRQ wake up is really fast enough. There are machines that aren't.
thanks,
Takashi
2009/12/8 Takashi Iwai tiwai@suse.de
At Sat, 5 Dec 2009 10:17:07 +0800, Raymond Yau wrote:
2009/12/4 pl bossart bossart.nospam@gmail.com
- hwptr 24351 buffer 16384 appl 24332, avail=16403
appl pointer is behind hwprtr ( underrun ) , need timestamp to find
out
whether PA is unable to write audio data in time since
I commented out the portion of the code that increases the watermark
and
clamped the number of available samples to the buffer size, and it
works
just fine, no audio underflows.
Do you mean that the underrun is related the the portion of code that increase the watermark (i.e It is a pulseaudio bug instead of driver bug
)
?
Or, we can try simply to change to periods_min = 2 whether this fixes the PA issues.
periods_min = 1 is anyway fairly fragile. With that setup, apps are supposed (implicitly) to wake up frequently enough to get pointers in sync. This is because you can't trust whether the IRQ wake up is really fast enough. There are machines that aren't.
thanks,
Takashi
The intel8x0 driver has code to handle one period per buffer ,
Is the feature "one period per buffer" designed for dmix ?
static void snd_intel8x0_setup_periods(struct intel8x0 *chip, struct ichdev *ichdev) { int idx; u32 *bdbar = ichdev->bdbar; unsigned long port = ichdev->reg_offset;
iputdword(chip, port + ICH_REG_OFF_BDBAR, ichdev->bdbar_addr); if (ichdev->size == ichdev->fragsize) { ichdev->ack_reload = ichdev->ack = 2; ichdev->fragsize1 = ichdev->fragsize >> 1; for (idx = 0; idx < (ICH_REG_LVI_MASK + 1) * 2; idx += 4) { bdbar[idx + 0] = cpu_to_le32(ichdev->physbuf); bdbar[idx + 1] = cpu_to_le32(0x80000000 | /* interrupt on completion */ ichdev->fragsize1 >> ichdev->pos_shift); bdbar[idx + 2] = cpu_to_le32(ichdev->physbuf + (ichdev->size >> 1)); bdbar[idx + 3] = cpu_to_le32(0x80000000 | /* interrupt on completion */ ichdev->fragsize1 >> ichdev->pos_shift); } ichdev->frags = 2; } else {
The system timer may be running faster or slower than the sound card on differnt machine
PA only adjust the watermark/sleeping time in one direction only
At Wed, 9 Dec 2009 19:55:15 +0800, Raymond Yau wrote:
2009/12/8 Takashi Iwai tiwai@suse.de
At Sat, 5 Dec 2009 10:17:07 +0800, Raymond Yau wrote:
2009/12/4 pl bossart bossart.nospam@gmail.com
- hwptr 24351 buffer 16384 appl 24332, avail=16403
appl pointer is behind hwprtr ( underrun ) , need timestamp to find
out
whether PA is unable to write audio data in time since
I commented out the portion of the code that increases the watermark
and
clamped the number of available samples to the buffer size, and it
works
just fine, no audio underflows.
Do you mean that the underrun is related the the portion of code that increase the watermark (i.e It is a pulseaudio bug instead of driver bug
)
?
Or, we can try simply to change to periods_min = 2 whether this fixes the PA issues.
periods_min = 1 is anyway fairly fragile. With that setup, apps are supposed (implicitly) to wake up frequently enough to get pointers in sync. This is because you can't trust whether the IRQ wake up is really fast enough. There are machines that aren't.
thanks,
Takashi
The intel8x0 driver has code to handle one period per buffer ,
Yes, but it doesn't work so reliably. That's why I asked for testing periods_min = 2.
Is the feature "one period per buffer" designed for dmix ?
No.
The system timer may be running faster or slower than the sound card on differnt machine
Yes.
PA only adjust the watermark/sleeping time in one direction only
Yes.
thanks,
Takashi
'Twas brillig, and Takashi Iwai at 09/12/09 13:46 did gyre and gimble:
PA only adjust the watermark/sleeping time in one direction only
Yes.
Actually there is code in PA to move the watermark in both ways, but obviously reverting it backtowards the "underrun zone" is a bit dangerous, so can't be just a simple "reduce it" back.
http://git.0pointer.de/?p=pulseaudio.git;a=commit;h=050a3a99e1d151b4f55c89f8...
I can't remember the current status (i.e. if the code is disabled or not) but AFAICT it's enabled.
Col
2009/12/9 Colin Guthrie gmane@colin.guthr.ie
'Twas brillig, and Takashi Iwai at 09/12/09 13:46 did gyre and gimble:
PA only adjust the watermark/sleeping time in one direction only
Yes.
Actually there is code in PA to move the watermark in both ways, but obviously reverting it backtowards the "underrun zone" is a bit dangerous, so can't be just a simple "reduce it" back.
http://git.0pointer.de/?p=pulseaudio.git;a=commit;h=050a3a99e1d151b4f55c89f8...
I can't remember the current status (i.e. if the code is disabled or not) but AFAICT it's enabled.
Col
What is hwbuf_unused in the watermark calculation ?
Refer to *Image 1:* *Schematic overview of the playback buffer in the traditional playback model, in the best way the author can visualize this with his limited drawing abilities.*
http://0pointer.de/blog/projects/pulse-glitch-free.html
When the alsa application using 4 periods , the alsa driver is about 75% full at all time. The data remain in the buffer is many time of the minimum period bytes ( 32 bytes in the case of intel8x0 )
1) It seem that 32byes is the PCI brust size ? ( hda driver seem has 128 bytes and usb driver ....)
PulseAudio <= 0.9.10 uses a fragment size of 25ms by default, with four fragments.
Glitch Free mode
If no client specified any requirements we fill up the whole buffer all the time, i.e. have an actual latency of 2s. However, if some applications specified requirements, we take the lowest one and only use as much of the configured hardware buffer as this value allows us. In practice, this means we only partially fill the buffer each time we wake up. Then, we configure a system timer to wake us up 10ms before the buffer would run empty and fill it up again then. If the overall latency is configured to less than 10ms we wakeup after half the latency requested.
Correct me If I am wrong
1) The function of alsa-plugin is to emulate an ALSA device
2) The hardware pointer of this pulse device is the application pointer of the pulseaduio server
3) If PA server did not write any thing up when the timer wake up, this mean that the hardware pointer of the pulse device also stop moving.
_From the viewpoint of the alsa application , the pulse device is also inaccurate
1. hwptr 2858101 buffer 16384 appl 2874469, avail=16 2. D: alsa-sink.c: avail: 64 (samples 16) 3. D: alsa-sink.c: 371.16 ms left to play; inc threshold = 0.00 ms; dec threshold = 100.00 ms 4. D: alsa-sink.c: Not filling up, because too early. 5. D: alsa-sink.c: Wakeup from ALSA! 6. D: alsa-sink.c: Loop 7. D: alsa-sink.c: Buffer time: 371 ms; Sleep time: 351 ms; Process time: 20 ms 8. hwptr 2874490 buffer 16384 appl 2874469, avail=16405
4) why did alsa-time-test using pulse device , abort immediately
./alsa-time-test pulse alsa-time-test: alsa-time-test.c:46: main: Assertion `r == 0' failed. Aborted
2009/12/9 Takashi Iwai tiwai@suse.de
At Wed, 9 Dec 2009 19:55:15 +0800, Raymond Yau wrote:
2009/12/8 Takashi Iwai tiwai@suse.de
At Sat, 5 Dec 2009 10:17:07 +0800, Raymond Yau wrote:
2009/12/4 pl bossart bossart.nospam@gmail.com
> 17. hwptr 24351 buffer 16384 appl 24332, avail=16403
appl pointer is behind hwprtr ( underrun ) , need timestamp to
find
out
whether PA is unable to write audio data in time since
I commented out the portion of the code that increases the
watermark
and
clamped the number of available samples to the buffer size, and it
works
just fine, no audio underflows.
Do you mean that the underrun is related the the portion of code that increase the watermark (i.e It is a pulseaudio bug instead of driver
bug
)
?
Or, we can try simply to change to periods_min = 2 whether this fixes the PA issues.
periods_min = 1 is anyway fairly fragile. With that setup, apps are supposed (implicitly) to wake up frequently enough to get pointers in sync. This is because you can't trust whether the IRQ wake up is really fast enough. There are machines that aren't.
thanks,
Takashi
The intel8x0 driver has code to handle one period per buffer ,
Yes, but it doesn't work so reliably. That's why I asked for testing periods_min = 2.
Is the feature "one period per buffer" designed for dmix ?
No.
The system timer may be running faster or slower than the sound card on differnt machine
Yes.
PA only adjust the watermark/sleeping time in one direction only
Yes.
thanks,
Takashi
Unlike the convention sound card which has only one set of hardware registers, aureal au88x0 chips has 4 set of hardware registers ( sub-buffers as descibed in patent 6167465 ) The maximum period size is 4k bytes and the driver support 2 to 32 periods.
This is exactly as same as the sound card in the figure
*Image 1:* *Schematic overview of the playback buffer in the traditional playback model, in the best way the author can visualize this with his limited drawing abilities.*
http://0pointer.de/blog/projects/pulse-glitch-free.html
1) what is hwbuf_unused_frames ?
2) why PA use snd_pcm_hw_params_get_buffer_size_max() instead of snd_pcm_hw_params_get_buffer_size() after snd_pcm_hw_params() ?
D: alsa-util.c: Maximum hw buffer size is 371 ms
I: module-alsa-sink.c: Using 2 fragments of size 4096 bytes, buffer time is 46.44ms D: alsa-util.c: buffer_size : 2048 D: alsa-util.c: period_size : 1024
3) why PA alway open CTL device "front:0" instead of "hw:0" ?
I: (alsa-lib)control.c: Invalid CTL front:0 I: alsa-util.c: Unable to attach to mixer front:0: No such file or directory I: alsa-util.c: Successfully attached to mixer 'hw:0'
4) did PA has any data to play when the server probe the devices ?
D: module-alsa-sink.c: Thread starting up D: rtpoll.c: Acquired POSIX realtime signal SIGRTMIN+29 I: module-alsa-sink.c: Starting playback.
5) it seem bug in snd_pcm_sw_params_set_avail_min() since 4661 is larger than the buffer size 2048 since PA still think that 371ms is the maximum buffer size
D: alsa-util.c: buffer_size : 2048 D: alsa-util.c: period_size : 1024 D: alsa-util.c: period_time : 23219 D: alsa-util.c: tstamp_mode : NONE D: alsa-util.c: period_step : 1 D: alsa-util.c: avail_min : 4661
6) when using the minimum period size of alsa-pulse plugin and aplay on pulseaudio 0.9.19
it seem that underrun occur between aplay and PA server
I: alsa-sink.c: Increasing wakeup watermark to 7,98 ms D: protocol-native.c: Underrun on 'ALSA Playback', 0 bytes in queue. D: sink-input.c: Requesting rewind due to corking
For pulseaudio-0.9.14 on Fedora 10
D: module-hal-detect.c: Not loaded device /org/freedesktop/Hal/devices/pci_12eb_2_sound_card_0_alsa_playback_1 D: module-hal-detect.c: Loading module-alsa-sink with arguments 'device_id=0 sink_name=alsa_output.pci_12eb_2_sound_card_0_alsa_playback_0 tsched=1' D: alsa-util.c: Trying front:0 with SND_PCM_NO_AUTO_FORMAT ... D: alsa-util.c: Maximum hw buffer size is 371 ms
...
I: module-alsa-sink.c: Successfully opened device front:0. I: module-alsa-sink.c: Successfully enabled mmap() mode. I: module-alsa-sink.c: Successfully enabled timer-based scheduling mode. I: (alsa-lib)control.c: Invalid CTL front:0 I: alsa-util.c: Unable to attach to mixer front:0: No such file or directory I: alsa-util.c: Successfully attached to mixer 'hw:0' I: alsa-util.c: Using mixer control "Master". I: sink.c: Created sink 0 "alsa_output.pci_12eb_2_sound_card_0_alsa_playback_0" with sample spec s16le 2ch 44100Hz and channel map front-left,front-right I: source.c: Created source 0 "alsa_output.pci_12eb_2_sound_card_0_alsa_playback_0.monitor" with sample spec s16le 2ch 44100Hz and channel map front-left,front-right I: module-alsa-sink.c: Using 2 fragments of size 4096 bytes, buffer time is 46.44ms I: module-alsa-sink.c: Time scheduling watermark is 20.00ms D: module-alsa-sink.c: hwbuf_unused_frames=0 D: module-alsa-sink.c: setting avail_min=4661 I: module-alsa-sink.c: Volume ranges from 0 to 31. I: module-alsa-sink.c: Volume ranges from -46.50 dB to 0.00 dB. I: alsa-util.c: All 2 channels can be mapped to mixer channels. I: module-alsa-sink.c: Using hardware volume control. Hardware dB scale supported. D: alsa-util.c: snd_pcm_dump(): D: alsa-util.c: Hardware PCM card 0 'Aureal Vortex au8830' device 0 subdevice 0 D: alsa-util.c: Its setup is: D: alsa-util.c: stream : PLAYBACK D: alsa-util.c: access : MMAP_INTERLEAVED D: alsa-util.c: format : S16_LE D: alsa-util.c: subformat : STD D: alsa-util.c: channels : 2 D: alsa-util.c: rate : 44100 D: alsa-util.c: exact rate : 44100 (44100/1) D: alsa-util.c: msbits : 16 D: alsa-util.c: buffer_size : 2048 D: alsa-util.c: period_size : 1024 D: alsa-util.c: period_time : 23219 D: alsa-util.c: tstamp_mode : NONE D: alsa-util.c: period_step : 1 D: alsa-util.c: avail_min : 4661 D: alsa-util.c: period_event : 0 D: alsa-util.c: start_threshold : -1 D: alsa-util.c: stop_threshold : -1 D: alsa-util.c: silence_threshold: 0 D: alsa-util.c: silence_size : 0 D: alsa-util.c: boundary : 1073741824 D: alsa-util.c: appl_ptr : 0 D: alsa-util.c: hw_ptr : 0 D: module-alsa-sink.c: Read hardware volume: 0: 64% 1: 64% D: module-alsa-sink.c: Thread starting up D: rtpoll.c: Acquired POSIX realtime signal SIGRTMIN+29 I: module-alsa-sink.c: Starting playback.
...
I: module-alsa-sink.c: Trying resume... D: alsa-util.c: Maximum hw buffer size is 371 ms D: module-alsa-sink.c: hwbuf_unused_frames=0 D: module-alsa-sink.c: setting avail_min=4661 I: module-alsa-sink.c: Resumed successfully... I: module-alsa-sink.c: Starting playback. D: module-suspend-on-idle.c: Sink alsa_output.pci_12eb_2_sound_card_0_alsa_playback_0 becomes idle. D: module-suspend-on-idle.c: Sink alsa_output.pci_12eb_2_sound_card_0_alsa_playback_0 becomes busy. D: memblockq.c: memblockq requested: maxlength=33554432, tlength=0, base=4, prebuf=0, minreq=1 maxrewind=0 D: memblockq.c: memblockq sanitized: maxlength=33554432, tlength=33554432, base=4, prebuf=0, minreq=4 maxrewind=0 I: sink-input.c: Created input 1 "ALSA Playback" on alsa_output.pci_12eb_2_sound_card_0_alsa_playback_0 with sample spec s16le 2ch 44100Hz and channel map front-left,front-right I: protocol-native.c: Requested tlength=500.00 ms, minreq=124.99 ms D: protocol-native.c: Early requests mode enabled, configuring sink latency to minreq. D: memblockq.c: memblockq requested: maxlength=4194304, tlength=88200, base=4, prebuf=66152, minreq=22048 maxrewind=0 D: memblockq.c: memblockq sanitized: maxlength=4194304, tlength=88200, base=4, prebuf=66152, minreq=22048 maxrewind=0 I: protocol-native.c: Final latency 624.99 ms = 250.02 ms + 2*124.99 ms + 124.99 ms D: module-alsa-sink.c: latency set to 46.44ms D: module-alsa-sink.c: hwbuf_unused_frames=1 D: module-alsa-sink.c: setting avail_min=4662 D: module-alsa-sink.c: Requesting rewind due to latency change. D: module-alsa-sink.c: Requested to rewind 8192 bytes. D: module-alsa-sink.c: Limited to 3712 bytes. D: module-alsa-sink.c: before: 928 D: module-alsa-sink.c: after: 928 D: module-alsa-sink.c: Rewound 3712 bytes. D: sink.c: Processing rewind... D: sink-input.c: Have to rewind 3712 bytes on render memblockq.
https://bugtrack.alsa-project.org/alsa-bug/view.php?id=4776
hyper_sonic 's au8830 a bit lagged .But if switch to integrated i8x0 sound chip music played very well. on pulseaudio 0.9.19
PA seem to use 16 fragments instead of 2 fragments for au8830
I: alsa-sink.c: Using 16,0 fragments of size 4096 bytes (23,22ms), buffer size is 65536 bytes (371,52ms) I: alsa-sink.c: Time scheduling watermark is 20,00ms D: alsa-sink.c: hwbuf_unused=0 D: alsa-sink.c: setting avail_min=15502 D: alsa-mixer.c: Activating path analog-output-lfe-on-mono D: alsa-mixer.c: Path analog-output-lfe-on-mono (Analog Output (LFE)), direction=1, priority=40, probed=yes, supported=yes, has_mute=yes, has_volume=yes, has_dB=yes, min_volume=0, max_volume=31, min_dB=-81, max_dB=12 D: alsa-mixer.c: Element Master, direction=1, switch=1, volume=1, enumeration=0, required=0, required_absent=0, mask=0x3600000000f66, n_channels=2, override_map=yes D: alsa-mixer.c: Element Master Mono, direction=1, switch=1, volume=1, enumeration=0, required=4, required_absent=0, mask=0x80, n_channels=1, override_map=yes D: alsa-mixer.c: Element PCM, direction=1, switch=1, volume=1, enumeration=0, required=0, required_absent=0, mask=0x402b600000000f66, n_channels=2, override_map=yes D: alsa-mixer.c: Element External Amplifier, direction=1, switch=4, volume=0, enumeration=0, required=0, required_absent=0, mask=0x0, n_channels=0, override_map=no D: alsa-mixer.c: Option on (output-amplifier-on/Amplifier) index=1, priority=10 D: alsa-mixer.c: Option off (output-amplifier-off/No Amplifier) index=0, priority=0 D: alsa-mixer.c: Setting output-amplifier-on (Amplifier) priority=10 D: alsa-mixer.c: Setting output-amplifier-off (No Amplifier) priority=0 I: alsa-sink.c: Hardware volume ranges from -81,00 dB to 12,00 dB. I: alsa-sink.c: Fixing base volume to -12,00 dB I: alsa-sink.c: Using hardware volume control. Hardware dB scale supported. I: alsa-sink.c: Using hardware mute control. D: alsa-util.c: snd_pcm_dump(): D: alsa-util.c: Hardware PCM card 1 'Aureal Vortex au8830' device 0 subdevice 0 D: alsa-util.c: Its setup is: D: alsa-util.c: stream : PLAYBACK D: alsa-util.c: access : MMAP_INTERLEAVED D: alsa-util.c: format : S16_LE D: alsa-util.c: subformat : STD
- why PA use snd_pcm_hw_params_get_buffer_size_max() instead of
snd_pcm_hw_params_get_buffer_size() after snd_pcm_hw_params() ?
Precisely to use the maximum preallocated buffer size.
I: module-alsa-sink.c: Using 2 fragments of size 4096 bytes, buffer time is 46.44ms D: alsa-util.c: buffer_size : 2048 D: alsa-util.c: period_size : 1024
With small buffers like this, I don't see the point of the timer-based scheduling, you will have one interrupt every 23ms.
- it seem bug in snd_pcm_sw_params_set_avail_min() since 4661 is larger
than the buffer size 2048 since PA still think that 371ms is the maximum buffer size
D: alsa-util.c: buffer_size : 2048 D: alsa-util.c: period_size : 1024 D: alsa-util.c: period_time : 23219 D: alsa-util.c: tstamp_mode : NONE D: alsa-util.c: period_step : 1 D: alsa-util.c: avail_min : 4661
This doesn't make sense. But avail_min isn't really used with the timer-based scheduling
For pulseaudio-0.9.14 on Fedora 10
Man, you are using an old version here, the alsa sink code was changed several times already.
2009/12/10 pl bossart bossart.nospam@gmail.com
- why PA use snd_pcm_hw_params_get_buffer_size_max() instead of
snd_pcm_hw_params_get_buffer_size() after snd_pcm_hw_params() ?
Precisely to use the maximum preallocated buffer size.
The driver only allocate 8K bytes for the substream when the application request 2 fragments and 64 Kbytes when the application request 16 fragments
It is wrong for PA to think that 371ms is the buffer size on pulseaudio 0.9.21
If the user select 8 fragements in deamon.conf , the pulseaudio-0.9.21 still calculated the wrong buffer time and wakeup time.
Do you know what is PA 's "hwbuf_unused_frames" ?
/* hw_params callback */ static int snd_vortex_pcm_hw_params(struct snd_pcm_substream *substream, struct snd_pcm_hw_params *hw_params) { vortex_t *chip = snd_pcm_substream_chip(substream); stream_t *stream = (stream_t *) (substream->runtime->private_data); int err;
// Alloc buffer memory. err = snd_pcm_lib_malloc_pages(substream, params_buffer_bytes(hw_params));
I: module-alsa-sink.c: Using 2 fragments of size 4096 bytes, buffer time
is
46.44ms D: alsa-util.c: buffer_size : 2048 D: alsa-util.c: period_size : 1024
With small buffers like this, I don't see the point of the timer-based scheduling, you will have one interrupt every 23ms.
au8810, au8820 and au8830 were designed for those 3D sound game (low latency) and support multiple DMA connections (i.e. hardware mixing ) , they does not need any sound server (software mixing) at all.
- it seem bug in snd_pcm_sw_params_set_avail_min() since 4661 is larger
than the buffer size 2048 since PA still think that 371ms is the maximum buffer size
D: alsa-util.c: buffer_size : 2048 D: alsa-util.c: period_size : 1024 D: alsa-util.c: period_time : 23219 D: alsa-util.c: tstamp_mode : NONE D: alsa-util.c: period_step : 1 D: alsa-util.c: avail_min : 4661
This doesn't make sense. But avail_min isn't really used with the timer-based scheduling
Are you sure ?
For pulseaudio-0.9.14 on Fedora 10
Man, you are using an old version here, the alsa sink code was changed several times already.
PA 0.9.14 run quite well with my au8830 with 2 fragements on Fedora 10 but PA 0.9.19 run badly on hypersonic 's au8830 on Karmic
It seem to be regression of PA
The possible reasons may be
1) PA 's 20ms process time may not enough for hyper_sonic 's CPU ( ICH2 or ICH4 since he is using intelx8x0) and I am a faster CPU since my motherboard is using HDA ( ICH8)
2) PA may only handle 1 or 2 periods or use the wrong buffer size in calculating the watermark
3) snd_pcm_rewindable() is returning a wrong value since au88x0 has FIFO buffer as described in the patent )
http://0pointer.de/blog/projects/pulse-glitch-free.html
The rewriting of the client buffers causing rewriting of the hardware buffer complicates the resampling/converting step immensly. In general the code to implement this model is more complex than for the traditional model. Also, ALSA has not really been designed with this design in mind, which makes some things very hard to get right and suboptimal.
The transfer of the audio data (48000Hz) only occur at ac97 link between AC97 codec and AC97 controller. The AC97 controller fetch audio from memory at the rate of PCI bus instead of the sampling rate of the audio. Therefore rewind the application pointer to hardware pointer and immediate rewrite is almost impossible
4) the default fragments in daemon.conf seem oboselte in PA 0.9.21 but there is no proper documentation
2009/12/10 pl bossart bossart.nospam@gmail.com
- why PA use snd_pcm_hw_params_get_buffer_size_max() instead of
snd_pcm_hw_params_get_buffer_size() after snd_pcm_hw_params() ?
Precisely to use the maximum preallocated buffer size.
D: module-alsa-sink.c: latency set to 46.44ms D: module-alsa-sink.c: hwbuf_unused_frames=1 D: module-alsa-sink.c: setting avail_min=4662 D: module-alsa-sink.c: Requesting rewind due to latency change. D: module-alsa-sink.c: Requested to rewind 8192 bytes. D: module-alsa-sink.c: Limited to 3712 bytes. D: module-alsa-sink.c: before: 928
The driver only allocated the requested buffer size at hw_param callback
As you can see , PA only rewind 8192 bytes only instead of 371 ms ?
2009/12/10 pl bossart bossart.nospam@gmail.com
I: module-alsa-sink.c: Using 2 fragments of size 4096 bytes, buffer time
is
46.44ms D: alsa-util.c: buffer_size : 2048 D: alsa-util.c: period_size : 1024
With small buffers like this, I don't see the point of the timer-based scheduling, you will have one interrupt every 23ms.
Do you mean that this is a limitation of pulseaudio server timer-based scheduling ?
It seem the problem is not related to small buffer since
It work quite well with 2 fragments (8196 bytes) on pulseaudio-0.9.14
D: alsa-util.c: Hardware PCM card 0 'Aureal Vortex au8830' device 0 subdevice 0 D: alsa-util.c: Its setup is: D: alsa-util.c: stream : PLAYBACK D: alsa-util.c: access : MMAP_INTERLEAVED D: alsa-util.c: format : S16_LE D: alsa-util.c: subformat : STD D: alsa-util.c: channels : 2 D: alsa-util.c: rate : 44100 D: alsa-util.c: exact rate : 44100 (44100/1) D: alsa-util.c: msbits : 16 D: alsa-util.c: buffer_size : 2048 D: alsa-util.c: period_size : 1024 D: alsa-util.c: period_time : 23219 D: alsa-util.c: tstamp_mode : NONE D: alsa-util.c: period_step : 1 D: alsa-util.c: avail_min : 4661 D: alsa-util.c: period_event : 0 D: alsa-util.c: start_threshold : -1 D: alsa-util.c: stop_threshold : -1 D: alsa-util.c: silence_threshold: 0 D: alsa-util.c: silence_size : 0 D: alsa-util.c: boundary : 1073741824 D: alsa-util.c: appl_ptr : 0 D: alsa-util.c: hw_ptr : 0
but fail on 16 fragments ( 65536 bytes) on pulseaudio-0.9.19
D: alsa-util.c: Hardware PCM card 1 'Aureal Vortex au8830' device 0 subdevice 0 D: alsa-util.c: Its setup is: D: alsa-util.c: stream : PLAYBACK D: alsa-util.c: access : MMAP_INTERLEAVED D: alsa-util.c: format : S16_LE D: alsa-util.c: subformat : STD D: alsa-util.c: channels : 2 D: alsa-util.c: rate : 44100 D: alsa-util.c: exact rate : 44100 (44100/1) D: alsa-util.c: msbits : 16 D: alsa-util.c: buffer_size : 16384 D: alsa-util.c: period_size : 1024 D: alsa-util.c: period_time : 23219 D: alsa-util.c: tstamp_mode : ENABLE D: alsa-util.c: period_step : 1 D: alsa-util.c: avail_min : 15502 D: alsa-util.c: period_event : 0 D: alsa-util.c: start_threshold : -1 D: alsa-util.c: stop_threshold : 1073741824 D: alsa-util.c: silence_threshold: 0 D: alsa-util.c: silence_size : 0 D: alsa-util.c: boundary : 1073741824 D: alsa-util.c: appl_ptr : 0 D: alsa-util.c: hw_ptr : 0
May be PA server cannot calculate the correct sleeping time when the sound card use more than 2 periods ?
Takashi, I tested with .periods_min=2 and reduced the period_max by half. The underruns reported by PulseAudio are no longer present with this modification. However, there's still something fishy here. In both cases, with 1 or 2 periods, PulseAudio seems to wake-up more often than it should with snd_pcm_poll_descriptors_revents returning a null event. See the sequence below. Not sure if the problem is a bad configuration of the timers of if the driver generates these events? I also noticed that the underrun reported with a single period are associated with the POLLOUT revent. I am not sure this is normal? Thanks for your feedback. - Pierre
D: alsa-sink.c: Waking up in 157.78ms (system clock).
WAKEUP
E: alsa-sink.c: snd_pcm_poll_descriptors_revents() returned zero D: alsa-sink.c: Loop D: alsa-sink.c: Buffer time: 371 ms; Sleep time: 321 ms; Process time: 50 ms D: alsa-sink.c: avail: 1076 (samples 269)
This is not consistent, there are too few samples in the buffer
D: alsa-sink.c: 365.42 ms left to play; inc threshold = 0.00 ms; dec threshold = 100.00 ms D: alsa-sink.c: Not filling up, because too early.
go back to sleep
D: alsa-sink.c: Waking up in 157.71ms (system clock).
WAKEUP
E: alsa-sink.c: snd_pcm_poll_descriptors_revents() returned zero D: alsa-sink.c: Loop D: alsa-sink.c: Buffer time: 371 ms; Sleep time: 321 ms; Process time: 50 ms D: alsa-sink.c: avail: 1136 (samples 284)
again the buffer is still almost full and we have nothing to do
D: alsa-sink.c: 365.08 ms left to play; inc threshold = 0.00 ms; dec threshold = 100.00 ms D: alsa-sink.c: Not filling up, because too early.
2009/12/10 pl bossart bossart.nospam@gmail.com
Takashi, I tested with .periods_min=2 and reduced the period_max by half. The underruns reported by PulseAudio are no longer present with this modification.
why did you reduce periods_max by half since the driver should still support 1024 periods of 32 bytes when you set periods_min = 2 ?
Is it period_bytes_max by half ?
static struct snd_pcm_hardware snd_intel8x0_stream = { .info = (SNDRV_PCM_INFO_MMAP | SNDRV_PCM_INFO_INTERLEAVED | SNDRV_PCM_INFO_BLOCK_TRANSFER | SNDRV_PCM_INFO_MMAP_VALID | SNDRV_PCM_INFO_PAUSE | SNDRV_PCM_INFO_RESUME), .formats = SNDRV_PCM_FMTBIT_S16_LE, .rates = SNDRV_PCM_RATE_48000, .rate_min = 48000, .rate_max = 48000, .channels_min = 2, .channels_max = 2, .buffer_bytes_max = 128 * 1024, .period_bytes_min = 32, .period_bytes_max = 128 * 1024, .periods_min = 1, .periods_max = 1024, .fifo_size = 0, };
why did you reduce periods_max by half since the driver should still support 1024 periods of 32 bytes when you set periods_min = 2 ?
Is it period_bytes_max by half ?
Yes I meant period_bytes_max.
participants (4)
-
Colin Guthrie -
pl bossart -
Raymond Yau -
Takashi Iwai