[alsa-devel] [RFC PATCH 3/4] ALSA: core: add report of max dma burst
Raymond Yau
superquad.vortex2 at gmail.com
Fri Jul 10 04:35:51 CEST 2015
>
>
>>> FIXME:
>>> 1. this was copy/pasted/edited based on the fifo_size fields, not
>>> sure why we would need this IOCTL1
>>
>>
>> fifo_size would fit, but it means that it also changes the current
>> behavior. I don't believe that currently there are many programs
>> relying on this value, but who knows.
>
>
> I saw a mention of fifo_size in the VIA HDA controller, that's why I went
ahead with a different field. The fifo_size could be useful as a max value
for the internal hardware delay, when app use the 'delay' field in the
status structure they get a very dynamic value that isn't necessarily
straightforward to use.
>
>
>>
>>> 2. we also need the ability to set the actual fifo size, if suppported,
>>> by the hardware, to negociate the prefetch amount between application
>>> and driver. By default the default should be max buffering to allow
>>> for lower power, but for low-latency use cases we may want to reduce
>>> the amount of prefetching.
>>
>>
>> Right. So a hw_parmas field looks suitable for that purpose.
>
>
> That 'set' capability is a lot more complicated, I am really having a
hard time with all the constraints for hw_params and how to represent
min,max and step values... If anyone is willing to help on that part I
wouldn't mind, this is really a part of ALSA I never looked into...
What is the usage of runtime->dma_bytes in
snd_pcm_hw_constraints_complete() in core/pcm_native.c ?
Was the usage similar to 128 bytes alignment ?
/* FIXME: remove */
if (runtime->dma_bytes) {
err = snd_pcm_hw_constraint_minmax(runtime,
SNDRV_PCM_HW_PARAM_BUFFER_BYTES, 0, runtime->dma_bytes);
if (err < 0)
return err;
}
More information about the Alsa-devel
mailing list