On Fri, 21 Sep 2018 10:35:49 +0200, Jussi Laako wrote: > > > The caching is currently enabled for all elements, but changing it > > should be trivial. The patch below adds is_volatile flag to the > > element, and you can set it to true in the quirk somehow for uncached > > controls. > > This patch looks good and what I need! When trying to figure out where > it is safe to set the volatile flag I thought that I could set it > transparently in add_single_ctl_with_resume() in mixer_quirks.c based > on the SNDRV_CTL_ELEM_ACCESS_VOLATILE flag in provided > snd_kcontrol_new access-member. However, add_single_ctl_with_resume() > is allocating just size of usb_mixer_elem_list unlike > snd_create_std_mono_ctl_offset() which in turn is allocating full > usb_mixer_elem_info size. However, the mixer code seems to be assuming > that the item is always usb_mixer_elem_info instead of just list > header item. Is this allocation behavior correct and is the item > turned into usb_mixer_elem_info somewhere, or is this some kind of > bug? So can I safely turn the allocation in > add_single_ctl_with_resume() into zero initialized usb_mixer_elem_info > instead and set the flag there while keeping correct behavior, or am I > missing something? We can check SNDRV_CTL_ELEM_ACCESS_VOLATILE instead of introducing a new flag like my patch, yes. It's just a matter of easiness. Since there is no link from usb_mixer_elem_info to the assigned snd_kcontorl, we'd need to add an extra argument in the call path to inform about the volatileness, and it may become messy. We'll find the simplest way. And, IMO, it'd be better to check the cache behavior at setting, since the cache may be accessed via multiple paths (at reading each element and at resuming the whole system). But it's no requirement, either. Takashi _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
