Re: [PATCH 2/2] add API to allow disabling period interrupt

[Jaroslav Kysela <perex@perex.cz>]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2643 bytes --]

On Tue, 2 Nov 2010, pl bossart wrote:

>>>>>> +int snd_pcm_hw_params_can_disable_period_irq(const snd_pcm_hw_params_t
>>>>>> *params)
>>>>>
>>>>> This function is useless because it cannot be called before
>>>>> snd_pcm_hw_params_set_period_irq().
>>>>
>>>> I don't think so. The info bits from the driver are used in this check
>>>> which are read-only.
>>>
>>> All the snd_pcm_hw_params_can_* functions that read the info bits
>>> are documented to require a completed configuration.  So they actually
>>> don't, and there will never be a flag that depends on the configuration?
>>
>> You're right. The *_can_* check should be removed.
>
> If I remove the *_can_* check and add a flag for snd_pcm_open,
> actually the other set/get routines need to go as well. Everything
> would happen at the opening stages instead of when the hardware params
> are set, you would try to disable the interrupts and if the open fails
> you would fall back to 'normal' mode.

I'm not sure if it's good to have another flag for snd_pcm_open. If we 
accept new open flag, it would be just an optional hint which should be 
verified by the application if it's really enabled using a function.

> The alternative would be to remove the _*can* but keep the set/get
> routines. In that case the hw_params configuration would be rejected
> if the hardware doesn't support this feature.
> Which solution do you guys prefer?

Note that there is a big difference between your new flag and the existing 
ones. The *_can_* functions just reflects the extended read only 
capabilities:

snd_pcm_hw_params_can_mmap_sample_resolution
snd_pcm_hw_params_can_overrange
snd_pcm_hw_params_can_pause
snd_pcm_hw_params_can_resume
snd_pcm_hw_params_can_sync_start

I see two ways:

1) leave set/get functions with this semantics:
    - application tries to set the no period update behaviour for hw_params
      - alsa-lib should check if nonblock flag is set at this moment
    - snd_pcm_hw_params() call
    - application reads back the no period update state and if the flag is
      not set, it will use standard period updates
2) create new optional snd_pcm_open flag
    - application opens device with nonblock and no period update flags
    - snd_pcm_hw_params() call
    - application reads back the no period update state and if the flag is
      not set, it will use standard period updates

Note that we can even implement both methods together like for 
handling the nonblock behaviour.

 						Jaroslav

-----
Jaroslav Kysela <perex@perex.cz>
Linux Kernel Sound Maintainer
ALSA Project, Red Hat, Inc.

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel