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

[Takashi Iwai <tiwai@suse.de>]

At Fri, 12 Oct 2012 08:49:08 +0200,
David Henningsson wrote:
> 
> 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.

The point is that it isn't designed to be used for such a purpose.
You can drive on route66 over north American continent only with a
side brake, too.  But the car manufacturer would warn you if you do
that, or if you set up a car and let other drivers try.

Similarly, single_cmd isn't designed to be used as the primary
communication method.  The hardware manufacturers never tested this
mode in that way.


> >>>>> 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.

Yeah, 50ms sounds reasonable.


thanks,

Takashi