On Tue, Aug 16, 2016 at 12:45:39PM +0800, wens Tsai wrote: > On Mon, Aug 15, 2016 at 7:42 PM, Mark Brown <broonie@xxxxxxxxxx> wrote: > > On Mon, Aug 15, 2016 at 05:43:55PM +0800, wens Tsai wrote: > > > >> What is unexpected is any attempt to play anything under this state makes > >> the playback software (in my case mpg321) stall, and later report an I/O > >> error. My guess is that the DAC is still disabled by DAPM, so it doesn't > >> send any DRQs, and thus the DMA engine is not consuming any data from > >> userspace. > > > > This is normal for ASoC - like you say it'll be becasue the hardware > > isn't powered up. > > > >> I think we should just enable the digital bits of the DAC/ADC all the > >> time. Or maybe transfer and then discard data if the DAC is off. Not > >> sure if this is doable though. I expect playback software to work, and > >> not block, regardless of the hardware status. > > > > Powering things up all the time will have a major effect on battery life > > for systems that care about that. The expectation is that systems with > > this sort of hardware won't normally be offering end users direct > > control of the routing, it'll be something that's handled during system > > integration. > > Ok. So I guess one solution would be to move the mute controls out of > DAPM, and maybe change some other mux like paths into actual muxes, so > there's at least one usable path at all times. I'm not sure that's even a requirement. IIRC, but Mark might correct me, you just need to expose whatever the reset state is. Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
