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-i...
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-i...
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/pc...
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/so...
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=HE...
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=09879a4bb58199f64abcb...
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