On Fri, Mar 14, 2014 at 10:47:50AM +0100, Mike Looijmans wrote:
Don't drop CCs on kernel lists if you want people to read replies - the bit about always CCing maintainers applies too...
*Any* glitch in an active digital audio path will be noticable to users,
The reconfiguration only occurs when switching from say 44100 to 48000 sampling rates (but not when going from 24 to 16 bits, for example). I don't think users will actually expect a switch from one sampling rate to another to proceed without any glitch or delay.
This has a wider effect than just the digital playback path though doesn't it - the capture path for example, and if this is a modern device there's doubtless charge pumps in play.
If you're taking several minutes to do a bias level transition there's something seriously wrong with either the hardware or with the way it's being managed by the driver.
Good enough for human ears, but this project uses codecs for measurement and is sensitive to microvolt changes in reference voltages and such. The audible effects are gone in less than a second, but the measurable effects last a lot longer.
Less than a second still sounds like an awfully long time here and if you've got constraints like this it sounds like you need to force the device to be always running anyway. Glancing at the code we're only managing clocks in the bias level operations...
The general solution here is essentially don't do that; if the hardware is fragile on reconfiguration you will tend to end up hitting cases where trying to do a reconfiguration will glitch or fail so the sound server will generally fix the configuration and handle things in software. Otherwise pmdown_time is the general solution for modern devices with quick startup/shutdown times, older devices probably need some custom hacks.
It's not about "fragile", it's about managing codec power states. For some transistions, like clock changes, a codec will likely need to go to a lower
It certainly sounds a lot like it's fragile - there seem to be fairly tight constraints on reconfiguring, you're saying it's hard to implement something that bounces the power around reconfiguration, the device requires symmetric rates so it won't cope if there's capture activity too and who knows what happens with the analogue bypass paths.
Equally well you've not been specific about anything so it's possible that the restrictions and/or what needs doing are looser than you're making them sound; looking at the code I'm not seeing anything except clocks being managed as part of the bias level management and there's no effort to selectively manage the clocks.
state. The current core does not even attempt to mute the DAC for example.
Yes it does - you can only reconfigure the sample rate for the audio stream when it's not running and we mute (if the device supports it) whenever the audio stream is halted.