On 04/01/2009 05:24 PM, Mark Brown wrote: > In that case rather than using a trigger to check if the device is > running it should be possible to use constraints to prevent > reconfiguration of the device when it's not supported - this is more > friendly to apps since they know they won't be allowed to change the > configuration. It was my impression that it is up to the pcm part to install these constraints as this is where SNDRV_PCM_INFO_JOINT_DUPLEX can be put into the snd_pcm_hardware structure. >>> It's especially suspicious since the power of the DAC and ADC is managed >>> via DAPM; the only current user should be safe since it saves then >>> restores the state but it does raise alarm bells. > >> How about making it a function that always disables the four components and >> referring to snd_soc_dapm_sync to restore the state? > > Hrm. For the ADC that's probably OK but powering off the DAC does risk > being audible in the output; that does depend on the hardware, though. > It should do the right thing, I think, but checking for audio artefacts > would be advisable. I can't hear any artefacts with my cheap headphones. The delayed close is audible, though. > It'd probably also help to only do reconfiguration if actually required > rather than always powering down the ADCs and DACs. That's what is done in these lines at the very first in aic3x_hw_params: + if (aic3x->format == params_format(params) && + aic3x->rate == params_rate(params)) + return 0; >> One could reorder aic3x_hw_params to detect the error before the >> first registers are written.. > > Yes. I'll make it three patches then: - one to remove the redundant actions on bias level off - one to reorder hw_params - and one to fix the bug Daniel -- Dipl.-Math. Daniel Glöckner, emlix GmbH, http://www.emlix.com Fon +49 551 30664-0, Fax -11, Bahnhofsallee 1b, 37081 Göttingen, Germany Geschäftsführung: Dr. Uwe Kracke, Dr. Cord Seele, Ust-IdNr.: DE 205 198 055 Sitz der Gesellschaft: Göttingen, Amtsgericht Göttingen HR B 3160 emlix - your embedded linux partner _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
