Topic for #qi-hardware is now Copyleft hardware - http://qi-hardware.com | hardware hackers join here to discuss Ben NanoNote, atben / atusb 802.15.4 wireless, and other community driven hw projects | public logging at http://en.qi-hardware.com/irclogs
rejon has joined #qi-hardware
wej has joined #qi-hardware
rejon has joined #qi-hardware
xwalk has joined #qi-hardware
xwalk has joined #qi-hardware
Ayla has joined #qi-hardware
<wpwrak>
DocScrutinizer: and with ionized, aka "normal" water ? ;-)
<Ayla>
larsc: there's a bug on the audio driver we're tring to remove
B_Lizzard has joined #qi-hardware
<larsc>
Ayla: what kind of bug
<Ayla>
from time to time, when the DAC is enabled, a very high, loud and cyclic noise appears
<Ayla>
it is very easy to make it appear on OpenDingux, as it seems to occur more easily when the sound submitted by the ALSA userspace library is very low
jekhor__ has joined #qi-hardware
<Ayla>
if we set the software volume to 4% on alsamixer, we get a high probability to trigger the bug
<Ayla>
the jz4740_pm.pdf has some info about how to reduce the noise, but I don't know at all how the driver works :)
B_Lizzard has joined #qi-hardware
<larsc>
Ayla: can you try to swap the cpu_dai and platform section in soc_pcm_open in soc-pcm.c and see if it makes any difference
<Ayla>
sure, one second
Ayla has joined #qi-hardware
<Ayla>
larsc: no difference
<larsc>
ok
GeorgeH has joined #qi-hardware
wej has joined #qi-hardware
Ayla has joined #qi-hardware
uwe_ has joined #qi-hardware
jurting has joined #qi-hardware
Ayla has joined #qi-hardware
<mth>
larsc: I think the audio bug Ayla described is actually a hardware limitation that the driver should work around but currently does not
<mth>
the hw needs a certain order of powering things up and wait times between the steps
<GNUtoo-desktop>
pop and clicks in the kernel Documentation?
<mth>
it's not really a "pop" since the noise repeats periodically
<mth>
but I do think it's related to the power-up sequence
<GNUtoo-desktop>
ok
<mth>
it's somewhere between the digital output and the DAC switch, so it could be the DAC itself
<mth>
I hope the recommended power-up sequence from Ingenic will avoid this problem as well as power-up pops and clicks
<mth>
in any case, I don't think this issue was ever reported with the Ingenic kernel and that audio driver has a very elaborate power-up sequence
Ayla has joined #qi-hardware
<mth>
another reason to suspect the DAC is that the level of the samples being played matters for the chance of triggering this bug
<mth>
it happens maybe 1 in 10 times for low volumes, and I've never been able to trigger it for high volumes
<mth>
for a digital part, I don't think the value of the samples should matter
<mth>
so the problem would be somewhere in the analog part
wej has joined #qi-hardware
<mth>
but it is before the hw volume step, since the artifact is modified by hw volume
<mth>
toggling the DAC output switch is what triggers it and also what makes it go away
<mth>
but that toggle action also causes the driver to power down a lot of the pipeline, so it might not be the hw switch
<mth>
one time I had the artifact for only 1 cycle, but usually if it appears it goes on forever
<mth>
the cycle length varies between about 0.5 and 2 seconds
<mth>
meaning that every time the problem is triggered, one cycle length is "picked" and will be repeated until you toggle the switch again
<mth>
but the next time the problem occurs the cycle length can be different
<mth>
there could be a relation between the sample level and the cycle length, but I haven't found firm evidence of that
GNUtoo-desktop has joined #qi-hardware
Ayla has joined #qi-hardware
B_Lizzard has joined #qi-hardware
<larsc>
mth: so it also happens if there is no real playback?