| wpwrak | DocScrutinizer: and with ionized, aka "normal" water ? ;-) | 04:48 |
|---|---|---|
| DocScrutinizer | depends | 10:00 |
| qi-bot | The build was successful: http://fidelio.qi-hardware.com/~xiangfu/build-nanonote/openwrt-xburst.minimal-20120414-0526 | 10:03 |
| kyak | whitequark: ha, thanks! :) | 10:57 |
| Ayla | larsc: hi | 16:15 |
| Ayla | larsc: there's a bug on the audio driver we're tring to remove | 16:16 |
| larsc | Ayla: what kind of bug | 16:16 |
| Ayla | from time to time, when the DAC is enabled, a very high, loud and cyclic noise appears | 16:17 |
| 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 | 16:18 |
| Ayla | if we set the software volume to 4% on alsamixer, we get a high probability to trigger the bug | 16:25 |
| 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 :) | 16:26 |
| 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 | 16:30 |
| Ayla | sure, one second | 16:31 |
| Ayla | larsc: no difference | 16:45 |
| larsc | ok | 16:46 |
| mth | larsc: I think the audio bug Ayla described is actually a hardware limitation that the driver should work around but currently does not | 18:47 |
| mth | the hw needs a certain order of powering things up and wait times between the steps | 18:48 |
| GNUtoo-desktop | pop and clicks in the kernel Documentation? | 18:48 |
| mth | it's not really a "pop" since the noise repeats periodically | 18:49 |
| mth | but I do think it's related to the power-up sequence | 18:49 |
| GNUtoo-desktop | ok | 18:50 |
| mth | it's somewhere between the digital output and the DAC switch, so it could be the DAC itself | 18:50 |
| mth | I hope the recommended power-up sequence from Ingenic will avoid this problem as well as power-up pops and clicks | 18:51 |
| 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 | 18:51 |
| mth | another reason to suspect the DAC is that the level of the samples being played matters for the chance of triggering this bug | 18:52 |
| mth | it happens maybe 1 in 10 times for low volumes, and I've never been able to trigger it for high volumes | 18:53 |
| mth | for a digital part, I don't think the value of the samples should matter | 18:53 |
| mth | so the problem would be somewhere in the analog part | 18:53 |
| mth | but it is before the hw volume step, since the artifact is modified by hw volume | 18:55 |
| mth | toggling the DAC output switch is what triggers it and also what makes it go away | 18:55 |
| 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 | 18:56 |
| mth | one time I had the artifact for only 1 cycle, but usually if it appears it goes on forever | 18:56 |
| mth | the cycle length varies between about 0.5 and 2 seconds | 18:56 |
| mth | meaning that every time the problem is triggered, one cycle length is "picked" and will be repeated until you toggle the switch again | 18:57 |
| mth | but the next time the problem occurs the cycle length can be different | 18:57 |
| mth | there could be a relation between the sample level and the cycle length, but I haven't found firm evidence of that | 18:57 |
| larsc | mth: so it also happens if there is no real playback? | 19:51 |
| qi-bot | [commit] Werner Almesberger: m1/patches/rtems/series: fix typo in date (xx0xx -> xx-xx) (master) http://qi-hw.com/p/wernermisc/08302e5 | 19:56 |
| qi-bot | [commit] Werner Almesberger: BUILD-CHEAT-SHEET: added pinning for rtems and rtems-yaffs2 (master) http://qi-hw.com/p/wernermisc/981374b | 20:28 |
| mth | larsc: I'm not sure if it happens for softvol exactly 0, but for almost-0 it does happen | 21:10 |
| mth | the amplitude of the artifact is unrelated to the softvol value | 21:11 |
| mth | which is part of why it is so problematic: it's extremely loud | 21:11 |
| mth | so if you have headphones on, it's a bad experience | 21:11 |
| mth | I can test with openMSX and nothing emulated running | 21:12 |
| mth | interesting: if the problem occurs with non-zero softvol and you then set softvol to 0, the problem doesn't go away when toggling the switch | 21:17 |
| kristianpaul | free software folks, sell usb-keys at events, what we qi call sell? | 21:19 |
| kristianpaul | of course there is nanonote | 21:19 |
| kristianpaul | but i was asked past week for selling 3 and i had no stock here :( | 21:19 |
| mth | and I can't reproduce it with softvol exactly 0, only with softvol just above 0 | 21:20 |
| kristianpaul | of course i took mails from people, lets see if it still sell some at the end.. | 21:20 |
| mth | so it seems a soft sound output is needed to trigger it: no sound or loud sound means it won't occur | 21:21 |
| mth | I've got the high-pitch part at a ~10 sec cycle now | 21:21 |
| mth | it's like a siren that starts at a medium-high pitch and then goes up into unhearable range | 21:22 |
| whitequark | kyak: no idea what you were talking about, but YW | 21:22 |
| mth | combined with a noisy garbled sound that is less loud | 21:22 |
| mth | this is what it sounds like: http://www.treewalker.org/temp/audio_problem.ogg | 21:49 |
| mth | this is with the very slow cycle, usually the high-pitch sound envelopes much faster and the cycle is 0.5-2 sec | 21:49 |
| mth | it's not so loud in this recording, but it was recorded from the speakers; from the headphones it's really loud | 21:50 |
| viric | kristianpaul: people want to give Qi money to fund the project, but wants some object for the money? | 21:57 |
| viric | s/wants/want | 21:57 |
| viric | kristianpaul: this is silly. | 21:58 |
| --- Mon Apr 16 2012 | 00:00 | |
Generated by irclog2html.py 2.9.2 by Marius Gedminas - find it at mg.pov.lt!