[alsa-devel] On non-rewindability of resamplers

[Raymond Yau]

>
>>
>> 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/pci/hda/hda_intel.c?id=2ae66c26550cd94b0e2606a9275eb0ab7070ad0e
>>
>> 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
>>
>> 1) delay in analog output > delay in digital output  e.g, idt codecs
>> 2) delay in analog output < delay in digital output e.g. adi codecs
>> 3) 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: afg_cap.patch
Type: text/x-diff
Size: 1145 bytes
Desc: not available
URL: <http://mailman.alsa-project.org/pipermail/alsa-devel/attachments/20140524/32d31911/attachment.bin>