28.05.2014 13:58, Raymond Yau wrote:
Yes. The test program is attached. For stereo S16_LE output, it
reports 32 samples (i.e. 128 bytes) as the minimum period size.
your program segfault when using NULL plugin
Bug in the null plugin. snd_pcm_null_fast_ops lacks the .rewindable field initialization, thus this callback gets defaulted to NULL. Thanks for reporting.
what other events pulseaudio need to rewind beside
- change in volume of sink/source
Volume change of the sink is supposed to be real time event
User are allowed to change the volume slider even when the sink is not playing or source is not capturing
If the requested volume cannot be satisfied by changing hardware volume controls , does pulseaudio keep the calculated software volume adjustment when the sink start playing while the hardware volume is supposed to be updated immediately ?
The answer depends on the volume mode.
In the flat-volume mode, there is in fact no independent sink volume. If at least one stream is playing, then the volume of the loudest stream is applied as a sink volume, and other streams are attenuated accordingly. So the answer to your question is "no", because starting the stream changes the total volume of the sink, including the hardware part.
In the non-flat volume mode, the answer is "yes".
when user specify ignore_DB=1 or codec does not have any volume control (e.g. SPDIF stereo playback) which force pulseaudio to use software volume.
The software volume will be same as the requested volume(volume slider in sound preference) even when there is no playing stream.
Do this software volume setting saved in pulseaudio database when shutdown and restore on pulseaudio next startup by module-device-restore for the SPDIF stereo profile ?
The volume is saved and restored as a whole. module-device-restore does not care what part of the volume is software and what part is hardware.
- change in volume of streams
since there may be multiple streams (clients) playing at the same time, Do pulseaudio still keep copies of unmixed audio of all connected clients ?
Yes. Each sink input keeps some past audio in a memblockq, just in case if the sink re-asks it.
- change in latency
- sync slaves of combined sinks
I don't think that (4) is valid. It is handled by resampling, not
rewinding.
- explicit rewrite request from the client (if the sink has already
rendered the rewritten data into its buffer)
- state change ("If we are added for the first time...") of the sink
input
If the stream is the first client ,
How about a low latency client connect to server when a high latency client is already playing ?
Do pulseaudio still rewind the sink when low latency client is playing and a high latency client connect to server ?
Every new connection (and by "added for the first time" the comment means exactly this) causes a full rewind.
- corking/uncorking
Do you mean pause of the playing stream while other stream is still playing ?
Yes. The other case is when a music stream is paused automatically while another stream (e.g. VoIP) is about to be played.
- end of underrun (for specific sink inputs)
if appl_ptr is behind hw_ptr , you need to use snd_pcm_forward to advance the appl_ptr to a suitable position which you write enough data so that final appl_ptr is at least one period ahead of hwptr
Why do end of underrun need rewind ?
Because we mean different kinds of underrun. You mean ALSA-level underrun. The comment means PulseAudio-level underrun - i.e. one of the streams failed to supply data in time, while the ALSA card got data without the contribution from that stream.
So PulseAudio mixed a lot of data ahead without that stream, filled in the ALSA buffer, and new data for that stream shows up. Obviously, it needs to be heard right away, and thus already-mixed data should be discarded by an ALSA-level rewind.
- moving streams between sinks
What happen when the sinks have different buffer size ?
Do all playing streams need to re-adjust latency ?
In theory, yes. The total latency is the sum of the latency of the sink and the latency specific to the sink input. This sum needs to be redistributed amongst these two parts.
However, the big comment after "case PA_SINK_MESSAGE_START_MOVE:" in src/pulsecore/sink.c contains some FIXMEs about known bugs in this process.