[alsa-devel] On non-rewindability of resamplers

[Alexander E. Patrakov]

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.

-- 
Alexander E. Patrakov