20.04.2014 20:44, David Henningsson wrote:
> On 2014-04-19 23:21, Alexander E. Patrakov wrote:
>> Since the dca ALSA plugin is based on extplug, it has a slave and
>> therefore
>> a card. Thus, PulseAudio thinks that it looks like hardware and attempts
>> rewinds, which this plugin cannot handle correctly, because ALSA never
>> notifies extplug plugins about rewinds.
>>
>> The same mishandling of rewinds applies to some other plugins.
>
> This sounds like an alsa-lib bug, and thus it would be wiser to correct
> it in ALSA rather than in PulseAudio?
Yes, this is a bug in alsa-lib. As for the "would it be wiser" question,
I don't have an answer yet. I will try and see what happens. My main
worry is that it will surely make all plugs non-rewindable, and thus has
a very high potential of unfixable regressions for applications that do
rewinds in the legacy non-pulseaudio setup.
>
>>
>> Work around this ALSA bug by switching to IRQ-based scheduling on strange
>> plugin types.
>> ---
>> I have not deleted the "does a card exist" check, but for the AC3 encoder
>> case (which is mentioned in the git log) it is now redundant. Feel free
>> to delete if no other triggering use case is known.
>>
>> P.S. I see this line in alsa-lib/src/pcm/pcm_extplug.c:
>>
>> params->info &= ~(SND_PCM_INFO_MMAP | SND_PCM_INFO_MMAP_VALID);
>>
>> but then also:
>>
>> snd_pcm_access_mask_t saccess_mask = { SND_PCM_ACCBIT_MMAP };
>>
>> How should I understand this - is the intention here to disable mmap
>> access
>> or enable it?
>
> Again, this sounds like an ALSA question?
Yes, it is an ALSA question.
>
> In addition, there is a snd_pcm_rewindable function, but we don't use
> it, and I don't know how well the different ALSA pcm types work with it.
> But it seems to me like the best course of action could be to make sure
> it reports the correct value for all ALSA pcm types, and then for
> PulseAudio to start using it?
As I said, I will try. If this fails, we'll gain a better commit message
for this patch :)
--
Alexander E. Patrakov
