[alsa-devel] [RFC PATCH] ALSA: hda - Implement a poll loop for jacks as a module parameter

David Henningsson david.henningsson at canonical.com
Fri Oct 12 08:49:08 CEST 2012


On 10/10/2012 05:59 PM, Takashi Iwai wrote:
> At Wed, 10 Oct 2012 17:36:58 +0200,
> David Henningsson wrote:
>>
>> On 10/10/2012 04:07 PM, Takashi Iwai wrote:
>>> At Wed, 10 Oct 2012 15:47:31 +0200,
>>> David Henningsson wrote:
>>>>
>>>> On 10/09/2012 04:57 PM, Takashi Iwai wrote:
>>>>> At Tue, 09 Oct 2012 16:28:07 +0200,
>>>>> David Henningsson wrote:
>>>>>> Or, to make it a bit more pragmatic, what other things are broken with
>>>>>> single_cmd? Could you give an example where this change would be harmful?
>>>>>
>>>>> The single cmd mode itself was introduced as a sort of rescue command
>>>>> without CORB/RIRB.  We shouldn't use it in normal situations.  It's
>>>>> simply no considered use case.
>>>>>
>>>>> With a lack of unsol event, you can't handle the volume knob, or any
>>>>> GPIO events, too.
>>>>
>>>> Those two are quite uncommon, and can be polled too if necessary.
>>>
>>> I wonder from where your love to polling comes...
>>
>> It's not a love for polling. It's a pragmatic view of having people's
>> machines working at best effort.
>
> I'm not against to implement the polling if the hardware is really
> broken and doesn't emit the unsol event properly.
> But preferring the poll is a different question.  The poll should be
> always a second choice.

Of course. Polling should be disabled by default.

>> If we, due to lack of time, hardware,
>> specifications, whatever, can't have the best option available to our
>> users, I prefer to have it working but "secretly performing worse", to
>> not having it working at all.
>
> It works more or less but just without unsol event.  It should be
> enough not to stop most of works, but enough for people noticing the
> problem they face.  Again, if single_cmd mode fallback happens,
> something must be wrong.  This is the thing to be fixed.
>
>> I'm genuinely trying to understand what's so wrong with single cmd mode
>> *in practice*, but when what I get in return from you is stuff about
>> saving the world and peaceful living, I don't know how to interpret that
>> "information".
>
> Using single_cmd mode is like driving a car only with the side brake.

I'm not convinced; but it does not matter much, as you're the boss.

>>>>> Well, do you want to allow 1ms polling?
>>>>
>>>> I can't see why not, if people want to burn CPU cycles, why not let
>>>> them.
>>>
>>> You seem to trust users too much :)
>>
>> Well, there's already a single_cmd module parameter, which if enabled
>> causes "no peaceful living at all", can't be worse than that, can it? ;-)
>
> It's a completely different problem.

It was a joke.

> You are trying to allow user setting up a parameter which may freeze
> the machine immediately by 100% CPU hog.  It won't happen with
> single_cmd mode option.

Fair enough.

I tested with "jackpoll_ms=50 single_cmd=1" on a 2 year old laptop and I 
did not notice any performance difference (neither from the polling nor 
the single_cmd).

If people want less than 50 ms polling, they're probably trying to do 
something extraordinary that we don't imagine right now, and hopefully 
they know how to compile their own kernel, or can present their use case 
to us.

So I just picked 50 ms. Feel free to apply the attached patch.


-- 
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-ALSA-hda-Implement-a-poll-loop-for-jacks-as-a-module.patch
Type: text/x-patch
Size: 7539 bytes
Desc: not available
URL: <http://mailman.alsa-project.org/pipermail/alsa-devel/attachments/20121012/862f510b/attachment.bin>


More information about the Alsa-devel mailing list