12.05.2014 10:52, I wrote:
12.05.2014 09:11, Raymond Yau wrote:
D: [alsa-sink] alsa-util.c: PCM state is RUNNING I: [alsa-sink] alsa-sink.c: Starting playback. I: [alsa-sink] (alsa-lib)pcm_hw.c: SNDRV_PCM_IOCTL_START failed (-77)
does SNDRV_PCM_IOCTL_START fail mean pcm state is no longer running ?
Note that this comes from pcm_hw.c. As PulseAudio does not use the hw: device in this particular use case, I have to conclude that it comes through the a52 or ioplug code. I am not really familiar with this code.
This error code means -EBADFD. There is indeed some ifdefed-out code that prints the state on -EBADFD, so probably you are right. OTOH there is something strange in the code that may or may not be relevant. I have not tested my findings.
The a52 plugin sets the start threshold of the "slave" to its own start threshold. However, it doesn't write anything to the "slave" until it has enough data for one A52 frame. So, if the start threshold is too low, or if the pcm is started manually, it is quite possible that the "slave" is started without anything written into it. Result: immediate underrun. The dca plugin deals with this situation by inserting one DTS frame of silence before everything else, and writing as many "samples" to the slave as the application samples written into it.
Note that PulseAudio always starts the stream manually after writing the first full buffer.
And the log that you quoted also says:
I: [alsa-sink] (alsa-lib)pcm_hw.c: SNDRV_PCM_IOCTL_START failed (-77) D: [alsa-sink] alsa-util.c: Got POLLERR from ALSA D: [alsa-sink] alsa-util.c: Got POLLOUT from ALSA D: [alsa-sink] alsa-util.c: PCM state is RUNNING
The failure is for the hw plugin, however, the a52 plugin reports that it is running. Quite obvious desynchronization of state between the a52 plugin and its "slave".
hw_ptr granularity is defined only by period_bytes_min (and
additional constraints if any).
Well, this disagrees with my experiments. For S16_LE stereo,
snd_pcm_hw_params_get_period_size_min() says 32 samples for both PCH and HDMI, while the measured granularity is different (8 and 16 samples).
should you use period_bytes_min instead of period_size_min ?
128 bytes / (8 x 2) = 8 samples for 8 channels
for 6 channels playback , the period does not fit exactly the pcie playload size 128 bytes
Will retest later today.
Sorry, there is no userspace API for that. The only way to get the minimum period size is via snd_pcm_hw_params_get_period_size_min, which obtains the result in terms of frames.
does this mean the pulseaudio still keep the audio data until the pulseaudio client close the stream ?
Not ready to answer this yet.
Still don't know for sure.