[alsa-devel] On non-rewindability of resamplers

Raymond Yau superquad.vortex2 at gmail.com
Sat May 10 02:46:52 CEST 2014


>
>
> I acknowledge that there was some confusion regarding the precise meaning
of the flag (especially given three possible situations - accurate to just
one period, accurate to better than one period but worse than one sample,
accurate to one sample), and I am not the authority here.

Can this granularity be measured by

1) open a playback stream with 2 or more periods
2) fill the full buffer and start playback
3) check the value returned by snd_pcm_rewindable () is half of period at
half period time interval
4) repeat the test with 1/4 , 1/8,..., period time interval

> In addition, there seems to be some confusion here between the hardware
periods (which are always 256 samples) and the period size in hw params. If
I understand the other emails correctly, regardless of what the user set in
hw_params, the reported position on ymfpci will be accurate to within 256
samples.
>

http://www.alsa-project.org/~tiwai/writing-an-alsa-driver/ch05s06.html#pcm-interface-operators-pointer-callback

This callback is called when the PCM middle layer inquires the current
hardware position on the buffer. The position must be returned in frames,
ranging from 0 to buffer_size - 1.

This does not implies all drivers must give accurate position at any time,
some drivers may use timer interrupt and increase the pointer by one periods

http://www.alsa-project.org/~tiwai/writing-an-alsa-driver/ch05s07.html#pcm-interface-interrupt-handler-boundary

High frequency timer interrupts

This happens when the hardware doesn't generate interrupts at the period
boundary but issues timer interrupts at a fixed timer rate (e.g. es1968 or
ymfpci drivers). In this case, you need to check the current hardware
position and accumulate the processed sample length at each interrupt. When
the accumulated size exceeds the period size, call snd_pcm_period_elapsed()
and reset the accumulator.

I am also confuse about ymfpci really use timer interrupts.

it does not start timer in snd_ymfpci_hw_start and stop timer in
snd_ymfpci_hw_stop , it call snd_pcm_timer() inside snd_ymfpci_interrupt()

it  read YDSXGR_CTRLSELECT to determine active bank and call
voice->interrupt

https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/commit/sound/pci/ymfpci?id=9bcf655109ae06a8e652671a0de6fe2da5c213c2

it  use per voice volume control to update voice->bank[next_bank].volume
during the interrupt

YMF7xx are just  AC97 controllers which DSP send the mixed audiothrough
AC97 link @ 48000Hz to AC97 codec

Refer to Block Diagram and System Diagram, Audio is fetched by Bus Master
DMA controller , Rate Converter/Mixer resample each voices's audio to
48000Hz if necessary and mix the audio streams , send to AC97 Interface

http://www.4front-tech.com/pguide/audio2.html

DSP_CAP_REALTIME bit tells if the device/operating system supports precise
reporting of output pointer position using SNDCtl_DSP_GETxPTR. Precise
means that accuracy of the reported playback pointer (time) is around few
samples. Without this capability the playback/recording position is
reported using precision of one fragment.

http://thread.gmane.org/gmane.linux.alsa.devel/5597

> hw_ptr granularity is defined only by period_bytes_min (and additional
constraints if any).

https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/commit/sound/soc?id=c0de42bf595238e9dd593405ebc2992cc8470732

hw.period_bytes_min = 256;
hw.fifo_size = dma_data->fifo_size;

Does soc drivers transfer audio in 256 bytes ?

seem twice the values of snd-hda-Intel (pcie bus)

>
> PulseAudio has the following consideration here: if the card cannot
report the position accurately, we need to disable the timestamp-based
scheduling, as this breaks module-combine-sink (or any successor of it),
because it relies on very accurate estimations of the actual sample rate
ratio between two non-identical cards.
>

https://bugs.freedesktop.org/show_bug.cgi?id=47899

if you want to hear sound from two snd-hda-intel at the same time using
combined sink, you may need driver provide the output delay in hda codec

7.3.4.5 Audio Function Group Capabilities

Output Delay is a four bit value representing the number of samples between
when the sample is received from the Link and when it appears as an analog
signal at the pin. This may be a “typical” value. If this is 0, the widgets
along the critical path should be queried, and each individual widget must
report its individual delay.

Figure 85. Audio Function Group Capabilities Response Format

7.3.4.6 Audio Widget Capabilities

Delay indicates the number of sample delays through the widget. This may be
0 if the delay value in the Audio Function Parameters is supplied to
represent the entire path.

http://git.kernel.org/cgit/linux/kernel/git/tiwai/hda-emu.git/tree/codecs

some hda codecs report delay in audio output/input widgets and the ranges
of delay vary from 3 to 13 samples, hda_proc.c did not show output/input
delay in the audio function group

Does it mean that pulseaudio need to add back the difference of output
delay of two hda codecs ?

If yes, this look like combined sink is also not rewindable too when
difference of  output delay is not zero

http://git.alsa-project.org/?p=alsa-plugins.git;a=blob;f=doc/upmix.txt;hb=HEAD

for upmix plugin, this mean that snd_pcm_rewindable may need to return zero
when user specify delay > 0 if you want "glitch free" rewind

Other pulseaudio modules seen does not support rewind (e.g. jack, tunnel,
Bluetooth,...

http://git.alsa-project.org/?p=alsa-plugins.git;a=tree

Other alsa plugins (e.g. Jack, oss,...) seem not support rewind

How about route and plug plugins ?

>
> For cards that are not batch, it will attempt to set both the period size
and the buffer size to something large (tsched_size, the default is 2s) and
let the driver adjust that to something more sensible for the card. I think
that in practice this means periods_min, although it is never mentioned
explicitly in PulseAudio source.

it does not  mean all drivers uses periods_min when applicaition did not
explicitly set  period , period time or period bytes

http://git.alsa-project.org/?p=alsa-lib.git;a=commit;h=09879a4bb58199f64abcb8df506f917c8efc2383

Some driver 's period_bytes_max can be less than (buffer_bytes_max /
periods_min)

>
> For batch cards, the desired period (or, in PA speak, "fragment") time
and the number of periods come from the config, of course subject to
adjustments made by the ALSA library to fit the hardware requirements.

as long as the application use two periods , no safe rewind is possible as
the application need to keep at least two periods fill in the buffer if the
pointer is not accurate.

do you mean that pulseaudio still perform rewind when using AC3 passthrough
on Didital playback device ?

if not , the value of snd_pcm_rewindable() of digital playback device
depends on whether  no audio  bit is set or not

>The defaults are:
>
> ; default-fragments = 4
> ; default-fragment-size-msec = 25
>
>
Does this mean that pulseaudio use this values for all sound card including
hda when user specify this value ?

Seem the values are comment out and not used by pulseaudio as default ,
users have to explicitly set these in the following report

https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/428619/comments/96


More information about the Alsa-devel mailing list