khelair has quit [Remote host closed the connection]
lekernel has quit [Ping timeout: 240 seconds]
khelair has joined #qi-hardware
lekernel has joined #qi-hardware
arossdotme has quit [Quit: arossdotme]
rz2k has joined #qi-hardware
khelair has quit [Remote host closed the connection]
unclouded has quit [Ping timeout: 264 seconds]
porchao has joined #qi-hardware
kuribas has joined #qi-hardware
xiangfu has quit [Ping timeout: 264 seconds]
xiangfu has joined #qi-hardware
ffio has joined #qi-hardware
_ffio_ has quit [Ping timeout: 258 seconds]
xiangfu has quit [Quit: leaving]
lekernel has quit [Quit: Leaving]
<mth>
larsc: on the JZ4770, if I power down the DAC, user space gets blocked when playing samples
<mth>
as in, the application is stuck in place until I enable one of the outputs that thereby indirectly enable the DAC
<larsc>
so the whole DMA is disabled?
<mth>
my guess is that the fifos don't get read anymore and therefore don't issue interrupts anymore either
<larsc>
If the codec is the clock master
<larsc>
and the clocks are disabled
<larsc>
as well
<larsc>
the i2s core won't request any new samples anymore
<mth>
I was wondering if this is a bug in the pcm or i2s driver or whether I simply shouldn't power down the DAC
<mth>
originally the codec driver didn't power down the DAC, but I've been cleaning it up and then this problem suddenly appeared
<mth>
the codec driver enables the clock at codec probe and never disables it
<larsc>
it probably shuts down more than just the DAC
<mth>
not ALSA, in any case: if I add a single line that only resets the DAC standby bit, the problem disappears
<mth>
maybe in the hardware there is also some kind of dependency graph?
<mth>
although the docs say they leave all that to software
<larsc>
yea, I'd assume that the codec shutsdown it's I2S clock if the DAC is powered down
<larsc>
or well the bit controls more than just the DAC
<mth>
so the I2S clock is sent by the codec to the AIC?
<larsc>
That's what I'd suspect
<larsc>
It's not unheard of that a codec tries to be smart and shutsdown the clocks if there is no active path over which audio could be played
viric has quit [Ping timeout: 240 seconds]
<mth>
the AIC is configurd to output SYSCLK, is that the same clock used for I2S or a different clock?
<larsc>
a different one, most likely
<larsc>
sysclk is usually the master clock
<larsc>
used by the codec to generate all other clocks
<mth>
"When use with the internal CODEC, the BIT_CLK and SYNC signals also with O_BIT_CLK and O_SYNC signals are provided by the internal CODEC from the SYSCLK, which is enabled by I2SCR.ESCLK and configured to 12MHz clock using CPM."
<mth>
so it seems there is a kind of loopback that derives the I2S clock from SYSCLK
<mth>
and perhaps powering down the DAC shuts down that loopback
viric has joined #qi-hardware
<larsc>
I wouldn't call it a loopback, but yes that's what is most likely happening
<mth>
yeah, it's more complex than just a wire, but the signal eventually gets sent back to the component where it came from
<larsc>
well it's comming from the cpm
<mth>
the AIC has a bit that controls whether it exports the SYSCLK or not
<mth>
so it's not coming directly from the CPM, but via the AIC
<mth>
anyway, do you have an idea on how to fix this?
<mth>
there doesn't seem to be a way to implicitly control the I2S clock
<larsc>
keep the DAC powered
<mth>
so one option would be to have the DAC enabled while playing with no outputs
<mth>
but it would waste some power
<larsc>
how often do you think somebody plays audio with all outputs disabled?
<larsc>
I mean it's not really a valid usecsae
<mth>
I do it quite often, if I'm playing games in the train
<mth>
I don't want to bother other people with the sound effects
<mth>
and often I'd rather disable sound than plug in headphones
<larsc>
But it would be better if the application would allow you disable sound altogether
<mth>
some do, but not every application has that option
<larsc>
Maybe you can somehow redirect audio to the null plugin
<larsc>
You do have a centeral deamon that handles stuff like volume right?
<mth>
I guess it's not trivial to have the samples consumed at the right rate if the dma is not running
<mth>
we have pwswd, which handles global hotkeys
<mth>
but it's not guaranteed that all volume changes go through that
<larsc>
but if you change the alsa config to use the null plugin is audio is off you'd save even more power
<larsc>
if audio is off
<larsc>
although I'm not sure how well that would work with already active streams
<mth>
maybe I'm over-optimizing and should just leave the DAC powered
<larsc>
leave it powered :)
<mth>
it took me several days to get the microphone support correct...
<mth>
although that was mostly because I'm not very good with ALSA yet
<mth>
and there is very little documentation on ALSA
<mth>
I am quite happy with how it turned out in the end though
<mth>
the platform data can now specify whether you have 0, 1 or 2 mono mics, or two mic inptus combined into one stereo mic
<mth>
and the right controls are instantiated for every case
<mth>
while previously you'd see all controls, even for inputs that don't exist on your board
<larsc>
sounds about right
Ornotermes has joined #qi-hardware
kuribas has quit [Quit: ERC Version 5.3 (IRC client for Emacs)]