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.
3.6.2 Buffer Descriptor List
There must be at least two entries in the list, with a maximum of 256 entries.
3.6.3 Buffer Descriptor List Entry
the buffers described by BDLE must start on 128 bytes boundary
refer to azx_setup_periods, if one period represent one BDLE , the buffers described by two periods must start on 128 bytes boundary
with default prealloc_max = 64, pulseaudio are forced to use maximum buffer size / period size which are also 128 bytes aligned
when you specifiy prealloc_max = 4096, one second 48000Hz is also aligned to 128 bytes boundary but one second 44100 Hz is not
Still, the bug (negative reported rewindable amount) also exists without
align_buffer_size=1.
e.g. 48 samples (192 bytes) when using 1ms period time and stereo instead of 4 channels
Not tested.
The implementation dependent FIFO Size affect the number of the bytes that could be fetched by the controller at one time.
3.3.40 Offset 90: {IOB}SDnFIFOS – Input/Output/Bidirectional Stream Descriptor n FIFO Size
FIFO Size (FIFOS): Indicates the maximum number of bytes that could be fetched by the controller at one time. This is the maximum number of bytes that may have been DMA‟d into memory but not yet transmitted on the link, and is also the maximum possible value that the LPIB count will increase by at one time.
you program seen hang when using pulse plugin
I am not interested in any more rewind-related bug reports for the pulse
plugin. This particular bug will be fixed, together with many others, by always returning 0 from the .rewindable callback for ioplug if mmap_rw is false.
why do you assume rewind is supported if mmap_rw is true ? any example
How do I test this? Could you please post some userspace test code or
a kernel patch, together with the instructions?
Attach the patch to dump the values of the audio function group
capability
There was no attachment.
There are three cases
- delay in analog output > delay in digital output e.g, idt codecs
- delay in analog output < delay in digital output e.g. adi codecs
- no delay in audio widgets , digital output and analog output have no
delay difference when output delay in audio function group is non zero ?
Yes, that's logical.
It is unlikely for ordinary user to measure the delay without using oscilloscope since the Analog speaker and digital receiver also have
delay
Correct. Also, while delay in analog speakers can be often rightfully
assumed to be 0 samples, this is not the case for digital receivers. In other words, the delay on the digital path is in fact unknown.
If 13 samples delay in analog output is due to the five bands equalizer in IDT codecs, the headphone should not has same delay since equalizer in not present in the headphone path, may need to implement multi-channel capture to find out any delay between headphone and line out