#milkymist IRC log for Sunday, 2011-03-27

lekernelso, on my board: the video chip was burned indeed, replacing it restored video in functionality11:20
lekernelthe audio codec situation is more complex11:20
rejonmm1 at firefox 4 launch in beijing11:47
rejongetting the license fixed, right gbraad ? ;)11:47
wolfspraulrejon: ah, here they are :-)12:09
kristianpaul(the audio codec situation is more complex) ??..13:09
CIA-43milkymist: Sebastien Bourdeauducq master * ra091b76 / (3 files): Replace Impact with UrJTAG - http://bit.ly/e0F24y13:24
wolfspraullekernel: ok great, thanks for confirming video-in, I guess we are on the right track there to make the board stronger14:34
wolfspraulvery good14:34
FallenouHi !14:35
Fallenouany intel about audio output noise ?14:35
lekernelfor audio i think it's in fact a FPGA design bug that generates the noise (and other problems with the WM codec)14:35
Fallenouoh ok14:36
Fallenouis it easy to check the signals with a scope (fpga <-> codec link) ?14:36
Fallenouor with a logic analyzer ?14:36
lekernelyeah, there are even test points on it14:36
Fallenouok :)14:36
lekernelbut I have already in my mind a list of suspects areas i'll check first14:36
Fallenoumaybe someone can check with the protocol (and data sent by the driver)14:37
Fallenouit's obviously not a key feature, but it would be too bad to have bad feed backs from users about that14:38
lekernelah, also, I have some ideas to crank up the video resolution14:38
Fallenouthere is so much good working complex things in Milkymist, would be too bad to have something simple not working14:38
Fallenouwhat was the main problem to increase the video (out ?) resolution lekernel ?14:39
Fallenouthe time processing per pixel ?14:39
lekernelmemory bandwidth (and it's still a problem)14:39
Fallenouoh ok14:39
lekernelwhat I propose is use a high resolution for the GUI14:40
Fallenoureducing the fps ? :)14:41
lekernelat 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 that14:41
Fallenouoh yes it's not like the vj video out14:41
lekernelwhen 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 fly14:42
lekernelso we have a fake 1280*1024 using the same bandwidth as 640*48014:42
Fallenouhum ok14:42
Fallenouis it really the same to have a fake 1280*1024, taking a 640*480 picture scaled up14:43
Fallenouor having a 640*480 picture14:43
Fallenouwith no scale change14:43
lekernelon modern LCD/DLP displays, the display's circuit will do the scaling anyway14:44
lekernelby doing it ourselves 1. we potentially reduce the latency 2. we can benefit from the extra resolutions in the GUI14:44
Fallenouyes, so you will have to make sure the fpga core does the same algorithm for interpolation than the one in screens14:44
lekernelit's bilinear interpolation usually14:44
Fallenouok :)14:45
lekernelthe TMU already implements a more complex case of it14:45
lekernelin fact, the 640x480 resolution in milkymist rendering is a scaled up 512x51214:45
lekernelwe could even use a 512x512 framebuffer everywhere for rendering and actually _increase_ the framerate a bit :)14:46
Fallenouhum hum don't know what is the best call :)14:47
lekerneland even benefit from greater vertical resolution (512->480 is scaling down)14:47
lekernelwe'd have 512x512 -> 1280x1024 scaling up all the way14:47
lekernelwith _reduced_ memory bandwidth compared to the current solution :)14:47
lekernel(but increased in the GUI, where it doesn't really matter)14:48
Fallenouyes but a loss in quality14:48
lekernelno, an increase in quality14:48
FallenouI don't know if it would be really noticeable14:48
lekernelactually this change would improve everything14:48
lekernelbetter framerate14:48
lekernelbetter resolution in GUI14:49
Fallenouyes better resolution for GUI14:49
Fallenoubut for the VJ performance14:49
lekernelsightly better picture quality (due to no 512->480 scaledown and then scaled up again by the display device)14:49
Fallenouthe horizontal resolution :o14:49
lekernelless latency (since displays could be used in native resolution and as we take care of scaling ourselves)14:49
lekernelyuppies seeing 1280x1024 in their display's menu and saying "w00t! this is HD!"14:50
lekernelit's better for everything :)14:50
Fallenouahah ok14:50
lekernelit just takes a bit of fpga design work14:50
lekernelwhy do you think this would decrease the picture quality in rendering?14:50
Fallenouwell I suppose if it uses less bandwidth, and let morrons be happy about the resolution14:50
Fallenouthat's great :)14:51
Fallenouwell you say you have 640x480, and you want to put it to 512x51214:51
Fallenouso you have a 640 -> 51214:51
lekernelit's already 512x512 internally14:51
Fallenouoh ok14:51
lekernel(for the rendering)14:51
Fallenouok I get it now :)14:52
lekernelwe have to use an internal framebuffer whose dimensions are a power of two in order to support texture wrapping easily14:52
Action: Fallenou have helicopters flying above his house14:53
FallenouSeine-Saint-Denis \o/14:53
mwallelekernel: 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
lekernelit's used for MIDI16:42
mwallemm1testing? rtems port?16:43
lekernelaudio bug: http://www.milkymist.org/IMG_0108.MOV17:54
rohi cant even play that file18:13
roh[aac @ 0x550b960]Audio object type 0 is not supported.18:13
rohsame game in totem18:13
kristianpauli still downloading it..18:19
lekernelworks for me...18:28
rohlekernel: 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
lekernelit's an iPhone video, and like it or not, many people can play them18:33
rohah. so its basically crippled mpeg4 chunks in a proprietary container ;)18:35
lekernelreencoding unimportant videos like that isn't worth my time18:35
rohsure. but in the end it showed me.. nothing18:36
rohmy impression was that the new codec was a day and night difference to the other board18:37
lekernelwell, in fact, not really18:37
lekernelwe tested the other codec with flickernoise and the new with the test program18:38
roheh.. the difference was clearly hearable18:38
lekernelI thought the level of noise was independent of what is running on the soc, but it's not18:38
lekernelsure. but we did the wrong test18:38
rohthe 2 dead-noise tests we did.. it was like >2 times the noise of the wolfson18:38
lekernelbut we are comparing:18:39
rohhave you done tests with a scope to measure amplitudes?18:39
lekernel1. LM4550 codec with flickernoise18:39
lekernel2. WM9707 codec with test program18:39
rohthe lm was noisy without doing anything.18:39
lekernelI don't know18:41
lekernelwe should test both with the exact same external conditions18:41
rohsure. and sw conditions18:41
lekernelyes. that's counted in "external" conditions18:41
rohmaybe we also get some more measuring tools in the new lab after moving18:42
lekernelas I said in the mail... I think this problem is just a FPGA bug18:42
lekernelI think we can bring the noise level to a reasonable value with LM4550 by fixing this bug18:43
rohi hope so.18:43
rohbecause currently its not really useable at all for audio18:44
lekernelit's not meant to, so this issue received very low priority18:44
roh"not meant to" is bullshit on hw with a fpga. any you know that18:45
rohthats a bad excuse for commerical people. which doesnt work for them either18:46
lekernelwell, 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
lekernelI wouldn't say making a device with a purpose is bullshit18:50
lekerneland the main purpose here isn't to make a FPGA devkit18:50
lekernelplus, we have very limited resources, so we have to prioritize things.18:51
rohlekernel: defining a purpose on a multipurpose device is bullshit.18:51
rohthats short sighted and dequalifiers itself as argument18:51
lekernelas you can see i'm fixing it, am I not?18:51
lekernelit's just low priority18:52
rohsure. thats valid. my point is: if something is there. it should work properly.18:52
rohif you cant make it work properly. dont add it.18:52
lekernelsure. we'd remove the audio out jack if we can't get it to work right.18:52
rohanything else wouldnt be right from my pov. (and generate a shitload of angry customers in the end).. seen that at openmoko.18:53
rohdont place the jacks at all.18:53
rohaudio 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
lekernelI don't know. it's perhaps a digital bug which wouldn't behave like the usual analog ones.18:54
rohnah. digital bugs never make white noise18:55
lekernelfailed timings can18:55
rohwould be quite impressive18:56
lekerneloh well... i've seen all sorts of crap in this project18:57
rohi 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 noise18:57
lekernelyup. the wm codec does that.18:57
rohthe stuff you know from playing a data cdrom in a audio player not muting that18:57
rohso the wm codec clearly behaves different to the lm one?18:58
lekernelyes, definitely18:58
lekernelyou get those digital-sounding noises when flickernoise is running18:58
lekerneland the noises depend on what you are doing in the app18:58
rohhm. could you make a file i can play somehow from that?18:59
lekernelthere is definitely something wrong in the digital design18:59
rohis it like the background one can hear when connecting the notebook analog to the amp?18:59
lekernelno, it's a lot louder18:59
lekernelthere are definitely wrong bits that get into the codec18:59
rohstuff like speedstepping makes a huge difference.. black to white screens... heavy cpu or io load makes noises18:59
rohi see. so it basically must be timing.. due to the signal strength on the link19:00
rohright? if it would be talkover we would see more stuff failing massively19:00
lekernelalso, the LM4550 is a 18-bit codec19:01
lekerneland the samples in memory are 16-bit19:01
lekernelthe noise might just come from the two LSB being 'random'19:01
rohyes.. just set the LSB to 019:01
lekerneliirc that's what it's supposed to do, but there might be a bug19:02
lekernelthat's one of the things we need to check19:02
rohgot a logic analyzer?19:03
rohwe got one in the lab (with the fitting win32 notebook)19:03
rohshould be ok to 100mhz or so19:03
lekernelac97 is just 12MHz or so19:04
rohah. easy19:04
lekernelmaybe the FPGA is also not generating the SYNC signal correctly and this annoys the codec19:05
lekernelthere could be lots of reasons19:05
lekerneland 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
lekernelhmm... even on scope I see weird things19:53
kristianpaul(video) he,19:54
lekernelnot on signal integrity which looks OK, but on the position of bits19:54
kristianpaulnew output for effects =)19:54
kristianpaulhm i wonder how noise will be running milkkydrops effects19:57
kristianpaullekernel: why not to try what you helped adam other about grouding the vga out?20:13
lekernelsorry, I don't understand what you mean20:14
kristianpaulwait let me organize my mind better :-)20:14
lekernelactually what is synthesizing right now might fix it20:16
kristianpaulML thead about "wrong connections on ADV7125 schematic ground pins"20:16
lekernelI found something weird with the loading of the register that samples the bus for audio data in the DMA engine20:17
lekernelkristianpaul: yeah, what with that thread?20:18
kristianpaullekernel: you proposed to to modify video RGB output & control signals from fpga in verilog20:21
kristianpaulwhy not try that again with this new audio chip?20:21
kristianpaul_just saying_20:21
lekernelfrankly, I don't thing the video out has anything to do with that20:23
lekernelbut Adam wanted to test, so I let him do20:23
kristianpaulbut you talk here about a fpga bug, but i wonder it was present on virtex too now with spartan?20:25
lekernelit's the same code20:27
kristianpaulso is bug in the code? :-)20:27
kristianpaulah ok20:28
CIA-43milkymist: Sebastien Bourdeauducq master * r4bedf4a / software/demo/shell.c : Add AC97 read and write functions to shell - http://bit.ly/i4Ggp322:19
Action: Fallenou received 100 milkymist stickers :)22:55
lekernelaudio problem fixed23:02
lekernelthe lm codec is a little bit more noisy than the wm one, but the amount of noise decreased A LOT :)23:04
rohuh. nice.23:04
lekernel(measuring on scope)23:04
lekerneldoing more tests atm, but it seems it works correctly with the lm codec and perfectly with the wm now23:04
rohwhat did you change?23:05
rohfpga timing of the bits on the wire?23:06
lekernelargh. no. the lm is still as noisy as before23:06
lekernelbut the other wm problems are gone23:06
rohhm. weird. maybe its more sensitive?23:07
rohto the problem, not the analog audio ;)23:07
lekernelyeah, timing (not sure it's required, will check) and zeroing of the invalid AC97 channels23:09
lekernelthe WM codec requires zeroing (according to the datasheet) but I saw no such thing in the LM datasheet23:10
lekerneland 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
lekerneland the wm codec didn't like that, resulting in various noises depending on the soc activity23:11
rohso you are trying to find the other but with the lm now or will you switch to the wm for rc3?23:13
lekerneldon't know yet23:13
lekernelwill test the WM codec a bit more23:13
lekernelit has less noise than my laptop atm23:13
lekernelso it would seem pretty strange that there's a problem with the PCB23:14
CIA-43milkymist: Sebastien Bourdeauducq master * r2b6a811 / (cores/ac97/test/Makefile cores/ac97/test/tb_ac97.v): update AC97 test bench - http://bit.ly/g8t3WK23:15
CIA-43milkymist: Sebastien Bourdeauducq master * r9dfcb67 / software/demo/renderer.c : Support Flickernoise equation prefixes - http://bit.ly/fcVK5y23:39
CIA-43milkymist: 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/epQg5P23:39
rohnice results.. (better than the laptop)23:55
rohsounds like the wolfson now is 'working correctly' then while the lm doesnt yet?23:56
rohbecause i dont think that the lm can be that bad when it comes to noise. that must be a bug still23:56
rohfound a nice 'dac' schematic23:58
--- Mon Mar 28 201100:00

Generated by irclog2html.py 2.9.2 by Marius Gedminas - find it at mg.pov.lt!