| lekernel | morning | 11:18 |
|---|---|---|
| wolfspraul | morning | 11:18 |
| lekernel | so, on my board: the video chip was burned indeed, replacing it restored video in functionality | 11:20 |
| lekernel | the audio codec situation is more complex | 11:20 |
| rejon | morning | 11:32 |
| rejon | mm1 at firefox 4 launch in beijing | 11:47 |
| rejon | http://www.flickr.com/photos/gbraad/5555790648/in/photostream/ | 11:47 |
| rejon | getting the license fixed, right gbraad ? ;) | 11:47 |
| wolfspraul | rejon: ah, here they are :-) | 12:09 |
| kristianpaul | (the audio codec situation is more complex) ??.. | 13:09 |
| CIA-43 | milkymist: Sebastien Bourdeauducq master * ra091b76 / (3 files): Replace Impact with UrJTAG - http://bit.ly/e0F24y | 13:24 |
| wolfspraul | lekernel: ok great, thanks for confirming video-in, I guess we are on the right track there to make the board stronger | 14:34 |
| wolfspraul | very good | 14:34 |
| Fallenou | Hi ! | 14:35 |
| Fallenou | any intel about audio output noise ? | 14:35 |
| lekernel | for audio i think it's in fact a FPGA design bug that generates the noise (and other problems with the WM codec) | 14:35 |
| Fallenou | oh ok | 14:36 |
| Fallenou | is it easy to check the signals with a scope (fpga <-> codec link) ? | 14:36 |
| Fallenou | or with a logic analyzer ? | 14:36 |
| Fallenou | easy/doable | 14:36 |
| lekernel | yeah, there are even test points on it | 14:36 |
| Fallenou | ok :) | 14:36 |
| lekernel | but I have already in my mind a list of suspects areas i'll check first | 14:36 |
| Fallenou | maybe someone can check with the protocol (and data sent by the driver) | 14:37 |
| lekernel | sure | 14:37 |
| Fallenou | ok | 14:37 |
| Fallenou | it's obviously not a key feature, but it would be too bad to have bad feed backs from users about that | 14:38 |
| lekernel | ah, also, I have some ideas to crank up the video resolution | 14:38 |
| Fallenou | there is so much good working complex things in Milkymist, would be too bad to have something simple not working | 14:38 |
| Fallenou | what was the main problem to increase the video (out ?) resolution lekernel ? | 14:39 |
| Fallenou | the time processing per pixel ? | 14:39 |
| lekernel | memory bandwidth (and it's still a problem) | 14:39 |
| Fallenou | oh ok | 14:39 |
| lekernel | what I propose is use a high resolution for the GUI | 14:40 |
| Fallenou | reducing the fps ? :) | 14:41 |
| lekernel | at 1280*1024 60Hz 16bpp, that's about 1.3Gbps (we can neglect the software's use of bandwidth) - the current memory system can definitely handle that | 14:41 |
| Fallenou | oh yes it's not like the vj video out | 14:41 |
| lekernel | when we go into render mode, we can reduce the internal framebuffer back to 640x480 and make the VGA core scale up the picture to 1280*1024 on the fly | 14:42 |
| lekernel | so we have a fake 1280*1024 using the same bandwidth as 640*480 | 14:42 |
| Fallenou | hum ok | 14:42 |
| Fallenou | is it really the same to have a fake 1280*1024, taking a 640*480 picture scaled up | 14:43 |
| Fallenou | or having a 640*480 picture | 14:43 |
| Fallenou | with no scale change | 14:43 |
| lekernel | on modern LCD/DLP displays, the display's circuit will do the scaling anyway | 14:44 |
| lekernel | by doing it ourselves 1. we potentially reduce the latency 2. we can benefit from the extra resolutions in the GUI | 14:44 |
| Fallenou | yes, so you will have to make sure the fpga core does the same algorithm for interpolation than the one in screens | 14:44 |
| lekernel | it's bilinear interpolation usually | 14:44 |
| Fallenou | ok :) | 14:45 |
| lekernel | the TMU already implements a more complex case of it | 14:45 |
| lekernel | in fact, the 640x480 resolution in milkymist rendering is a scaled up 512x512 | 14:45 |
| lekernel | we could even use a 512x512 framebuffer everywhere for rendering and actually _increase_ the framerate a bit :) | 14:46 |
| Fallenou | hum hum don't know what is the best call :) | 14:47 |
| Fallenou | fps/quality | 14:47 |
| lekernel | and even benefit from greater vertical resolution (512->480 is scaling down) | 14:47 |
| lekernel | we'd have 512x512 -> 1280x1024 scaling up all the way | 14:47 |
| lekernel | with _reduced_ memory bandwidth compared to the current solution :) | 14:47 |
| lekernel | (but increased in the GUI, where it doesn't really matter) | 14:48 |
| Fallenou | yes but a loss in quality | 14:48 |
| lekernel | no, an increase in quality | 14:48 |
| Fallenou | I don't know if it would be really noticeable | 14:48 |
| lekernel | actually this change would improve everything | 14:48 |
| lekernel | better framerate | 14:48 |
| lekernel | better resolution in GUI | 14:49 |
| Fallenou | yes better resolution for GUI | 14:49 |
| Fallenou | but for the VJ performance | 14:49 |
| lekernel | sightly better picture quality (due to no 512->480 scaledown and then scaled up again by the display device) | 14:49 |
| Fallenou | the horizontal resolution :o | 14:49 |
| lekernel | less latency (since displays could be used in native resolution and as we take care of scaling ourselves) | 14:49 |
| lekernel | yuppies seeing 1280x1024 in their display's menu and saying "w00t! this is HD!" | 14:50 |
| lekernel | it's better for everything :) | 14:50 |
| Fallenou | ahah ok | 14:50 |
| lekernel | it just takes a bit of fpga design work | 14:50 |
| lekernel | why do you think this would decrease the picture quality in rendering? | 14:50 |
| Fallenou | well I suppose if it uses less bandwidth, and let morrons be happy about the resolution | 14:50 |
| Fallenou | that's great :) | 14:51 |
| Fallenou | well you say you have 640x480, and you want to put it to 512x512 | 14:51 |
| Fallenou | so you have a 640 -> 512 | 14:51 |
| lekernel | it's already 512x512 internally | 14:51 |
| Fallenou | oh ok | 14:51 |
| lekernel | (for the rendering) | 14:51 |
| Fallenou | ok I get it now :) | 14:52 |
| lekernel | we have to use an internal framebuffer whose dimensions are a power of two in order to support texture wrapping easily | 14:52 |
| Fallenou | ooh | 14:53 |
| Action: Fallenou have helicopters flying above his house | 14:53 | |
| Fallenou | Seine-Saint-Denis \o/ | 14:53 |
| mwalle | lekernel: where is the uart THRU control bit used? do you assume that its the only bit in this register or can i add some more control bits to it? | 16:40 |
| lekernel | it's used for MIDI | 16:42 |
| mwalle | mm1testing? rtems port? | 16:43 |
| lekernel | rtems | 17:05 |
| lekernel | audio bug: http://www.milkymist.org/IMG_0108.MOV | 17:54 |
| roh | i cant even play that file | 18:13 |
| roh | broken | 18:13 |
| roh | [aac @ 0x550b960]Audio object type 0 is not supported. | 18:13 |
| roh | same game in totem | 18:13 |
| kristianpaul | i still downloading it.. | 18:19 |
| lekernel | works for me... | 18:28 |
| roh | lekernel: well.. if it doesnt play for me, be sure that it doesnt play for most people of the planet (ususally stuff plays here which nobody else can use) | 18:33 |
| lekernel | it's an iPhone video, and like it or not, many people can play them | 18:33 |
| roh | ah. so its basically crippled mpeg4 chunks in a proprietary container ;) | 18:35 |
| lekernel | reencoding unimportant videos like that isn't worth my time | 18:35 |
| roh | sure. but in the end it showed me.. nothing | 18:36 |
| roh | my impression was that the new codec was a day and night difference to the other board | 18:37 |
| lekernel | well, in fact, not really | 18:37 |
| lekernel | we tested the other codec with flickernoise and the new with the test program | 18:38 |
| roh | eh.. the difference was clearly hearable | 18:38 |
| lekernel | I thought the level of noise was independent of what is running on the soc, but it's not | 18:38 |
| lekernel | sure. but we did the wrong test | 18:38 |
| roh | the 2 dead-noise tests we did.. it was like >2 times the noise of the wolfson | 18:38 |
| lekernel | yup | 18:39 |
| lekernel | but we are comparing: | 18:39 |
| roh | have you done tests with a scope to measure amplitudes? | 18:39 |
| lekernel | 1. LM4550 codec with flickernoise | 18:39 |
| lekernel | 2. WM9707 codec with test program | 18:39 |
| roh | the lm was noisy without doing anything. | 18:39 |
| lekernel | I don't know | 18:41 |
| lekernel | we should test both with the exact same external conditions | 18:41 |
| roh | sure. and sw conditions | 18:41 |
| lekernel | yes. that's counted in "external" conditions | 18:41 |
| roh | maybe we also get some more measuring tools in the new lab after moving | 18:42 |
| lekernel | as I said in the mail... I think this problem is just a FPGA bug | 18:42 |
| lekernel | I think we can bring the noise level to a reasonable value with LM4550 by fixing this bug | 18:43 |
| roh | i hope so. | 18:43 |
| roh | because currently its not really useable at all for audio | 18:44 |
| lekernel | it's not meant to, so this issue received very low priority | 18:44 |
| roh | "not meant to" is bullshit on hw with a fpga. any you know that | 18:45 |
| roh | thats a bad excuse for commerical people. which doesnt work for them either | 18:46 |
| lekernel | well, if you needed audio out as a FPGA hacker, you could also use the FPGA to directly drive a class D amplifier, couldn't you? :) | 18:49 |
| lekernel | I wouldn't say making a device with a purpose is bullshit | 18:50 |
| lekernel | and the main purpose here isn't to make a FPGA devkit | 18:50 |
| lekernel | plus, we have very limited resources, so we have to prioritize things. | 18:51 |
| roh | lekernel: defining a purpose on a multipurpose device is bullshit. | 18:51 |
| roh | thats short sighted and dequalifiers itself as argument | 18:51 |
| lekernel | as you can see i'm fixing it, am I not? | 18:51 |
| lekernel | it's just low priority | 18:52 |
| roh | sure. thats valid. my point is: if something is there. it should work properly. | 18:52 |
| roh | if you cant make it work properly. dont add it. | 18:52 |
| lekernel | sure. we'd remove the audio out jack if we can't get it to work right. | 18:52 |
| roh | anything else wouldnt be right from my pov. (and generate a shitload of angry customers in the end).. seen that at openmoko. | 18:53 |
| roh | dont place the jacks at all. | 18:53 |
| roh | audio in isnt much better i assume. out is actually less complicated to get right. thus. if the output is noisy, the input samples lots of noise as well. | 18:53 |
| lekernel | I don't know. it's perhaps a digital bug which wouldn't behave like the usual analog ones. | 18:54 |
| roh | nah. digital bugs never make white noise | 18:55 |
| lekernel | failed timings can | 18:55 |
| roh | would be quite impressive | 18:56 |
| lekernel | oh well... i've seen all sorts of crap in this project | 18:57 |
| roh | i know the effects of rising ber on different digital audio links quite well.. and they generate LOUD noises.. arbitrary waveforms and such.. but never sustained noise | 18:57 |
| lekernel | yup. the wm codec does that. | 18:57 |
| roh | the stuff you know from playing a data cdrom in a audio player not muting that | 18:57 |
| roh | so the wm codec clearly behaves different to the lm one? | 18:58 |
| lekernel | yes, definitely | 18:58 |
| lekernel | you get those digital-sounding noises when flickernoise is running | 18:58 |
| lekernel | and the noises depend on what you are doing in the app | 18:58 |
| roh | hm. could you make a file i can play somehow from that? | 18:59 |
| lekernel | there is definitely something wrong in the digital design | 18:59 |
| roh | is it like the background one can hear when connecting the notebook analog to the amp? | 18:59 |
| lekernel | no, it's a lot louder | 18:59 |
| lekernel | there are definitely wrong bits that get into the codec | 18:59 |
| roh | stuff like speedstepping makes a huge difference.. black to white screens... heavy cpu or io load makes noises | 18:59 |
| roh | i see. so it basically must be timing.. due to the signal strength on the link | 19:00 |
| roh | right? if it would be talkover we would see more stuff failing massively | 19:00 |
| lekernel | also, the LM4550 is a 18-bit codec | 19:01 |
| lekernel | and the samples in memory are 16-bit | 19:01 |
| lekernel | the noise might just come from the two LSB being 'random' | 19:01 |
| roh | yes.. just set the LSB to 0 | 19:01 |
| lekernel | iirc that's what it's supposed to do, but there might be a bug | 19:02 |
| roh | ah | 19:02 |
| lekernel | that's one of the things we need to check | 19:02 |
| roh | got a logic analyzer? | 19:03 |
| lekernel | nope | 19:03 |
| roh | we got one in the lab (with the fitting win32 notebook) | 19:03 |
| roh | should be ok to 100mhz or so | 19:03 |
| lekernel | ac97 is just 12MHz or so | 19:04 |
| roh | ah. easy | 19:04 |
| lekernel | maybe the FPGA is also not generating the SYNC signal correctly and this annoys the codec | 19:05 |
| lekernel | there could be lots of reasons | 19:05 |
| roh | sure. | 19:05 |
| lekernel | and again, the quintessential crappiness of opencores means we can't just throw in another AC97 controller into the FPGA and compare the result :( | 19:07 |
| roh | ;) | 19:10 |
| lekernel | hmm... even on scope I see weird things | 19:53 |
| kristianpaul | (video) he, | 19:54 |
| lekernel | not on signal integrity which looks OK, but on the position of bits | 19:54 |
| kristianpaul | new output for effects =) | 19:54 |
| kristianpaul | hm i wonder how noise will be running milkkydrops effects | 19:57 |
| kristianpaul | lekernel: why not to try what you helped adam other about grouding the vga out? | 20:13 |
| lekernel | hmm? | 20:13 |
| lekernel | sorry, I don't understand what you mean | 20:14 |
| kristianpaul | wait let me organize my mind better :-) | 20:14 |
| lekernel | actually what is synthesizing right now might fix it | 20:16 |
| kristianpaul | ML thead about "wrong connections on ADV7125 schematic ground pins" | 20:16 |
| lekernel | I found something weird with the loading of the register that samples the bus for audio data in the DMA engine | 20:17 |
| lekernel | kristianpaul: yeah, what with that thread? | 20:18 |
| kristianpaul | lekernel: you proposed to to modify video RGB output & control signals from fpga in verilog | 20:21 |
| kristianpaul | why not try that again with this new audio chip? | 20:21 |
| kristianpaul | _just saying_ | 20:21 |
| lekernel | frankly, I don't thing the video out has anything to do with that | 20:23 |
| lekernel | but Adam wanted to test, so I let him do | 20:23 |
| kristianpaul | but you talk here about a fpga bug, but i wonder it was present on virtex too now with spartan? | 20:25 |
| lekernel | it's the same code | 20:27 |
| kristianpaul | so is bug in the code? :-) | 20:27 |
| lekernel | yes | 20:27 |
| kristianpaul | ah ok | 20:28 |
| CIA-43 | milkymist: Sebastien Bourdeauducq master * r4bedf4a / software/demo/shell.c : Add AC97 read and write functions to shell - http://bit.ly/i4Ggp3 | 22:19 |
| Action: Fallenou received 100 milkymist stickers :) | 22:55 | |
| kristianpaul | :o | 22:59 |
| lekernel | audio problem fixed | 23:02 |
| lekernel | the lm codec is a little bit more noisy than the wm one, but the amount of noise decreased A LOT :) | 23:04 |
| roh | uh. nice. | 23:04 |
| lekernel | (measuring on scope) | 23:04 |
| lekernel | doing more tests atm, but it seems it works correctly with the lm codec and perfectly with the wm now | 23:04 |
| roh | what did you change? | 23:05 |
| roh | fpga timing of the bits on the wire? | 23:06 |
| lekernel | argh. no. the lm is still as noisy as before | 23:06 |
| lekernel | but the other wm problems are gone | 23:06 |
| roh | hm. weird. maybe its more sensitive? | 23:07 |
| roh | to the problem, not the analog audio ;) | 23:07 |
| lekernel | yeah, timing (not sure it's required, will check) and zeroing of the invalid AC97 channels | 23:09 |
| lekernel | the WM codec requires zeroing (according to the datasheet) but I saw no such thing in the LM datasheet | 23:10 |
| lekernel | and I didn't zero out unused channels before, so you sometimes got data from the system bus into the ac97 frames (which were marked as invalid) | 23:10 |
| lekernel | and the wm codec didn't like that, resulting in various noises depending on the soc activity | 23:11 |
| roh | ah | 23:12 |
| roh | so you are trying to find the other but with the lm now or will you switch to the wm for rc3? | 23:13 |
| roh | s/but/bug | 23:13 |
| lekernel | don't know yet | 23:13 |
| lekernel | will test the WM codec a bit more | 23:13 |
| lekernel | it has less noise than my laptop atm | 23:13 |
| lekernel | so it would seem pretty strange that there's a problem with the PCB | 23:14 |
| CIA-43 | milkymist: Sebastien Bourdeauducq master * r2b6a811 / (cores/ac97/test/Makefile cores/ac97/test/tb_ac97.v): update AC97 test bench - http://bit.ly/g8t3WK | 23:15 |
| CIA-43 | milkymist: Sebastien Bourdeauducq master * r9dfcb67 / software/demo/renderer.c : Support Flickernoise equation prefixes - http://bit.ly/fcVK5y | 23:39 |
| CIA-43 | milkymist: Sebastien Bourdeauducq master * r1ebbb92 / (cores/ac97/rtl/ac97_ctlif.v cores/ac97/rtl/ac97_dma.v): AC97: zero out invalid frames (needed for WM9707) and fix loading of downstream data register in full duplex operation - http://bit.ly/epQg5P | 23:39 |
| lekernel | http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.8.9912&rep=rep1&type=pdf | 23:48 |
| roh | nice results.. (better than the laptop) | 23:55 |
| roh | sounds like the wolfson now is 'working correctly' then while the lm doesnt yet? | 23:56 |
| roh | because i dont think that the lm can be that bad when it comes to noise. that must be a bug still | 23:56 |
| roh | found a nice 'dac' schematic | 23:58 |
| roh | http://sound.westhost.com/project85.htm | 23:58 |
| --- Mon Mar 28 2011 | 00:00 | |
Generated by irclog2html.py 2.9.2 by Marius Gedminas - find it at mg.pov.lt!