[alsa-devel] On non-rewindability of resamplers

[Alexander E. Patrakov]

24.05.2014 11:10, Raymond Yau wrote:
>  >
>  >>
>  >> 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

I am not sure I can continue this line of discussion usefully, because I 
don't understand the purpose. If this is an attempt to understand the 
granularity of hw_ptr (which would indeed be useful), then I cannot 
help. If this is a report of a possible non-rewind-related bug in 
PulseAudio, please start a new thread.

>
>  >
>  >
>  > 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.

OK, this looks very relevant. Is this the same value as would be 
returned by snd_pcm_hw_params_get_fifo_size()? If not, why, and how do I 
view this value?

>
>  >
>  >
>  >
>  >>
>  >> 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

The example is jack plugin (in fact, the only plugin known to me that 
sets mmap_rw to true). It does support rewinds, as I have already 
explained and tested. It works because the periodic transfer of samples 
to JACK is done in a separate realtime thread. Application writes 
samples into a circular mmap-style buffer, ioplug uses the generic 
mmap-style functions for rewinding that buffer, and the thread reads 
from it, just as a real sound card would do. So an application can 
safely rewind any samples that it has written to that buffer but that 
the thread hasn't yet copied to JACK.

Of course it is possible to write a buggy ioplug-based plugin that 
doesn't really support rewinds even though it sets mmap_rw to true (e.g. 
by implementing the transfer callback - the real problem here, if my 
understanding is correct, is that it has no access to the application 
pointer). But in reality I don't know any such plugin.

Still, you are right, and a better idea would be to say: an ioplug-based 
plugin can be assumed to support rewinds if and only if it sets mmap_rw 
to true and does not provide a transfer callback. I say so because such 
architecture forces the plugin to use a low-latency thread to do the 
actual transfers and also avoids the need to care about the application 
pointer altogether. In other words, such plugin implements an 
architecture similar to one of a real DMA-based sound card.

>
>  >
>  >
>  >>
>  >>  >
>  >>  >
>  >>  > 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
>

For me an easier way would be to go to the nearest electronic components 
shop and buy three 3.5mm jacks and some wires to do a non-standard 
interconnection. You only need to capture two channels anyway: one from 
headphones and one from line output.

-- 
Alexander E. Patrakov