The appl_ptr can be placed in any position in the ring buffer for
the
application to write data but the sound card fetch data from this
ring
buffer sequentially, however snd_pcm_write() assume the maximum
distance
between appl_ptr and hwptr is only one buffer
https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/commit/sound/pc...
Do you mean hwptr does not decrease by one period when you use
arbitrary
period sizes for hda-Intel ?
I cannot comment on this commit. But
"snd_hda_intel.align_buffer_size=1" indeed existed on my kernel command line (for no good reason now - so removed), and I don't use a strange period size.
Loaded sound module options !!--------------------------
!!Module: snd_hda_intel align_buffer_size : -1 bdl_pos_adj : 32,32,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1
Why only one entry for align_buffer_size if it is specific to hda controller when the computer have two hda controllers ?
https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1324426
https://launchpadlibrarian.net/176540072/Symptom_PulseAudioLog.txt
May 29 06:57:49 Lihkin pulseaudio[1874]: [alsa-sink-92HD81B1X5 Analog] alsa-sink.c: ALSA woke us up to write new data to the device, but there was actually nothing to write!
Most likely this is a bug in the ALSA driver 'snd_hda_intel'. Please report this issue to the ALSA developers. We were woken up with POLLOUT set -- however a subsequent snd_pcm_avail() returned 0 or another value < min_avail.
snd_pcm_avail() returned a value that is exceptionally large: 181132 bytes (1026 ms). Most likely this is a bug in the ALSA driver 'snd_hda_intel'. Please report this issue to the ALSA developers.
Seem pulseaudio can use strange period size
May 29 11:36:52 Lihkin pulseaudio[1306]: [alsa-sink-HDMI 0] alsa-util.c: Its setup is: stream : PLAYBACK access : MMAP_INTERLEAVED format : S16_LE subformat : STD channels : 2 rate : 44100 exact rate : 44100 (44100/1) msbits : 16 buffer_size : 3520 period_size : 352 period_time : 7981 tstamp_mode : ENABLE period_step : 1 avail_min : 352 period_event : 1 start_threshold : -1 stop_threshold : 7926335344172072960 silence_threshold: 0 silence_size : 0 boundary : 7926335344172072960 appl_ptr : 2916662 hw_ptr : 2958425
start_threshold : -1
This mean the playback will automatically start if pulseaudio write any audio data instead of start after write pre buffer
Try aplay with any arbitrary period size/period time and xrun_debug , check whether hw_ptr is updated on every period update in the system log
aplay -v --period-size=352 --buffer-size=3520 -Dhw:0,0 stereo.wav
http://www.alsa-project.org/main/index.php/XRUN_Debug
/proc/asound/card#/pcm0p/xrun_debug
Replace '#' with your card number (usually 0). This proc file can enable various debugging tools. The CONFIG_SND_PCM_XRUN_DEBUG, CONFIG_SND_VERBOSE_PROCFS, CONFIG_SND_DEBUG options must be enabled in your kernel (if xrun_debug proc file is present - this feature is enabled).
# Enable basic debugging, do jiffies check and dump position on each period and hardware pointer update calls # Usefull when the lowlevel (specific) hardware driver is somehow broken echo 29 > /proc/asound/card0/pcm0p/xrun_debug