At Fri, 20 Aug 2010 16:46:25 +0200, David Henningsson wrote: > > 2010-08-19 22:24, Takashi Iwai skrev: > > At Thu, 19 Aug 2010 20:48:56 +0200, > > David Henningsson wrote: > >> > >> 2010-08-19 20:28, Takashi Iwai skrev: > >>> At Thu, 19 Aug 2010 20:17:42 +0200, > >>> David Henningsson wrote: > >>>> > >>>> This patch is helpful for tracking down bugs without having all > >>>> information about the chip. > >>> > >>> I don't want to change coef index in reading a proc file in general. > >> > >> Good point. But I think the solution to that problem would be to > >> - read current index > >> - do the loop > >> - restore current index > >> > >> ...and perhaps protect that with an appropriate mutex (which one)? > >> > >>> If any, you should implement a codec-specific hook. > >> > >> I'm sorry, but I don't really see how that would help...? > > > > If it's specific to a codec, then you know whether reading the coef > > in that way can be harmful or not. It's not only about the race > > via proc file but also the influence of coef on the actual codec > > behavior. > > Oh, so there are chips that are *that* broken... > > Yet it could be a lifesaver so I wouldn't want to give up on the idea > just yet... As mentioned, I don't mind to add it but as a beginning, let's add it conditionally for known-working codecs. Eventually we can put it to the generic part, with a blacklisting if needed. > Do you know off the top of your head approximately what codec chips this > is about, where reading a coef (or setting its index) can cause unwanted > side-effects? I don't remember exactly which one. I thought either an old Realtek or AD codec. Takashi _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
