<wolfspraul>
lekernel: ok great, thanks for confirming video-in, I guess we are on the right track there to make the board stronger
<wolfspraul>
very good
<Fallenou>
Hi !
<Fallenou>
any intel about audio output noise ?
<lekernel>
for audio i think it's in fact a FPGA design bug that generates the noise (and other problems with the WM codec)
<Fallenou>
oh ok
<Fallenou>
is it easy to check the signals with a scope (fpga <-> codec link) ?
<Fallenou>
or with a logic analyzer ?
<Fallenou>
easy/doable
<lekernel>
yeah, there are even test points on it
<Fallenou>
ok :)
<lekernel>
but I have already in my mind a list of suspects areas i'll check first
<Fallenou>
maybe someone can check with the protocol (and data sent by the driver)
<lekernel>
sure
<Fallenou>
ok
<Fallenou>
it's obviously not a key feature, but it would be too bad to have bad feed backs from users about that
<lekernel>
ah, also, I have some ideas to crank up the video resolution
<Fallenou>
there is so much good working complex things in Milkymist, would be too bad to have something simple not working
<Fallenou>
what was the main problem to increase the video (out ?) resolution lekernel ?
<Fallenou>
the time processing per pixel ?
<lekernel>
memory bandwidth (and it's still a problem)
<Fallenou>
oh ok
<lekernel>
what I propose is use a high resolution for the GUI
<Fallenou>
reducing the fps ? :)
<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
<Fallenou>
oh yes it's not like the vj video out
<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
<lekernel>
so we have a fake 1280*1024 using the same bandwidth as 640*480
<Fallenou>
hum ok
<Fallenou>
is it really the same to have a fake 1280*1024, taking a 640*480 picture scaled up
<Fallenou>
or having a 640*480 picture
<Fallenou>
with no scale change
<lekernel>
on modern LCD/DLP displays, the display's circuit will do the scaling anyway
<lekernel>
by doing it ourselves 1. we potentially reduce the latency 2. we can benefit from the extra resolutions in the GUI
<Fallenou>
yes, so you will have to make sure the fpga core does the same algorithm for interpolation than the one in screens
<lekernel>
it's bilinear interpolation usually
<Fallenou>
ok :)
<lekernel>
the TMU already implements a more complex case of it
<lekernel>
in fact, the 640x480 resolution in milkymist rendering is a scaled up 512x512
<lekernel>
we could even use a 512x512 framebuffer everywhere for rendering and actually _increase_ the framerate a bit :)
<Fallenou>
hum hum don't know what is the best call :)
<Fallenou>
fps/quality
<lekernel>
and even benefit from greater vertical resolution (512->480 is scaling down)
<lekernel>
we'd have 512x512 -> 1280x1024 scaling up all the way
<lekernel>
with _reduced_ memory bandwidth compared to the current solution :)
<lekernel>
(but increased in the GUI, where it doesn't really matter)
<Fallenou>
yes but a loss in quality
<lekernel>
no, an increase in quality
<Fallenou>
I don't know if it would be really noticeable
<lekernel>
actually this change would improve everything
<lekernel>
better framerate
<lekernel>
better resolution in GUI
<Fallenou>
yes better resolution for GUI
<Fallenou>
but for the VJ performance
<lekernel>
sightly better picture quality (due to no 512->480 scaledown and then scaled up again by the display device)
<Fallenou>
the horizontal resolution :o
<lekernel>
less latency (since displays could be used in native resolution and as we take care of scaling ourselves)
<lekernel>
yuppies seeing 1280x1024 in their display's menu and saying "w00t! this is HD!"
<lekernel>
it's better for everything :)
<Fallenou>
ahah ok
<lekernel>
it just takes a bit of fpga design work
<lekernel>
why do you think this would decrease the picture quality in rendering?
<Fallenou>
well I suppose if it uses less bandwidth, and let morrons be happy about the resolution
<Fallenou>
that's great :)
<Fallenou>
well you say you have 640x480, and you want to put it to 512x512
<Fallenou>
so you have a 640 -> 512
<lekernel>
it's already 512x512 internally
<Fallenou>
oh ok
<lekernel>
(for the rendering)
<Fallenou>
ok I get it now :)
<lekernel>
we have to use an internal framebuffer whose dimensions are a power of two in order to support texture wrapping easily
<Fallenou>
ooh
<Fallenou>
have helicopters flying above his house
<Fallenou>
Seine-Saint-Denis \o/
<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?
<roh>
[aac @ 0x550b960]Audio object type 0 is not supported.
<roh>
same game in totem
<kristianpaul>
i still downloading it..
<lekernel>
works for me...
<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)
<lekernel>
it's an iPhone video, and like it or not, many people can play them
<roh>
ah. so its basically crippled mpeg4 chunks in a proprietary container ;)
<lekernel>
reencoding unimportant videos like that isn't worth my time
<roh>
sure. but in the end it showed me.. nothing
<roh>
my impression was that the new codec was a day and night difference to the other board
<lekernel>
well, in fact, not really
<lekernel>
we tested the other codec with flickernoise and the new with the test program
<roh>
eh.. the difference was clearly hearable
<lekernel>
I thought the level of noise was independent of what is running on the soc, but it's not
<lekernel>
sure. but we did the wrong test
<roh>
the 2 dead-noise tests we did.. it was like >2 times the noise of the wolfson
<lekernel>
yup
<lekernel>
but we are comparing:
<roh>
have you done tests with a scope to measure amplitudes?
<lekernel>
1. LM4550 codec with flickernoise
<lekernel>
2. WM9707 codec with test program
<roh>
the lm was noisy without doing anything.
<lekernel>
I don't know
<lekernel>
we should test both with the exact same external conditions
<roh>
sure. and sw conditions
<lekernel>
yes. that's counted in "external" conditions
<roh>
maybe we also get some more measuring tools in the new lab after moving
<lekernel>
as I said in the mail... I think this problem is just a FPGA bug
<lekernel>
I think we can bring the noise level to a reasonable value with LM4550 by fixing this bug
<roh>
i hope so.
<roh>
because currently its not really useable at all for audio
<lekernel>
it's not meant to, so this issue received very low priority
<roh>
"not meant to" is bullshit on hw with a fpga. any you know that
<roh>
thats a bad excuse for commerical people. which doesnt work for them either
<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? :)
<lekernel>
I wouldn't say making a device with a purpose is bullshit
<lekernel>
and the main purpose here isn't to make a FPGA devkit
<lekernel>
plus, we have very limited resources, so we have to prioritize things.
<roh>
lekernel: defining a purpose on a multipurpose device is bullshit.
<roh>
thats short sighted and dequalifiers itself as argument
<lekernel>
as you can see i'm fixing it, am I not?
<lekernel>
it's just low priority
<roh>
sure. thats valid. my point is: if something is there. it should work properly.
<roh>
if you cant make it work properly. dont add it.
<lekernel>
sure. we'd remove the audio out jack if we can't get it to work right.
<roh>
anything else wouldnt be right from my pov. (and generate a shitload of angry customers in the end).. seen that at openmoko.
<roh>
dont place the jacks at all.
<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.
<lekernel>
I don't know. it's perhaps a digital bug which wouldn't behave like the usual analog ones.
<roh>
nah. digital bugs never make white noise
<lekernel>
failed timings can
<roh>
would be quite impressive
<lekernel>
oh well... i've seen all sorts of crap in this project
<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
<lekernel>
yup. the wm codec does that.
<roh>
the stuff you know from playing a data cdrom in a audio player not muting that
<roh>
so the wm codec clearly behaves different to the lm one?
<lekernel>
yes, definitely
<lekernel>
you get those digital-sounding noises when flickernoise is running
<lekernel>
and the noises depend on what you are doing in the app
<roh>
hm. could you make a file i can play somehow from that?
<lekernel>
there is definitely something wrong in the digital design
<roh>
is it like the background one can hear when connecting the notebook analog to the amp?
<lekernel>
no, it's a lot louder
<lekernel>
there are definitely wrong bits that get into the codec
<roh>
stuff like speedstepping makes a huge difference.. black to white screens... heavy cpu or io load makes noises
<roh>
i see. so it basically must be timing.. due to the signal strength on the link
<roh>
right? if it would be talkover we would see more stuff failing massively
<lekernel>
also, the LM4550 is a 18-bit codec
<lekernel>
and the samples in memory are 16-bit
<lekernel>
the noise might just come from the two LSB being 'random'
<roh>
yes.. just set the LSB to 0
<lekernel>
iirc that's what it's supposed to do, but there might be a bug
<roh>
ah
<lekernel>
that's one of the things we need to check
<roh>
got a logic analyzer?
<lekernel>
nope
<roh>
we got one in the lab (with the fitting win32 notebook)
<roh>
should be ok to 100mhz or so
<lekernel>
ac97 is just 12MHz or so
<roh>
ah. easy
<lekernel>
maybe the FPGA is also not generating the SYNC signal correctly and this annoys the codec
<lekernel>
there could be lots of reasons
<roh>
sure.
<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 :(
<roh>
;)
<lekernel>
hmm... even on scope I see weird things
<kristianpaul>
(video) he,
<lekernel>
not on signal integrity which looks OK, but on the position of bits
<kristianpaul>
new output for effects =)
<kristianpaul>
hm i wonder how noise will be running milkkydrops effects
<kristianpaul>
lekernel: why not to try what you helped adam other about grouding the vga out?
<lekernel>
hmm?
<lekernel>
sorry, I don't understand what you mean
<kristianpaul>
wait let me organize my mind better :-)
<lekernel>
actually what is synthesizing right now might fix it
<kristianpaul>
ML thead about "wrong connections on ADV7125 schematic ground pins"
<lekernel>
I found something weird with the loading of the register that samples the bus for audio data in the DMA engine
<lekernel>
kristianpaul: yeah, what with that thread?
<kristianpaul>
lekernel: you proposed to to modify video RGB output & control signals from fpga in verilog
<kristianpaul>
why not try that again with this new audio chip?
<kristianpaul>
_just saying_
<lekernel>
frankly, I don't thing the video out has anything to do with that
<lekernel>
but Adam wanted to test, so I let him do
<kristianpaul>
but you talk here about a fpga bug, but i wonder it was present on virtex too now with spartan?
<lekernel>
it's the same code
<kristianpaul>
so is bug in the code? :-)
<lekernel>
yes
<kristianpaul>
ah ok
<CIA-43>
milkymist: Sebastien Bourdeauducq master * r4bedf4a / software/demo/shell.c : Add AC97 read and write functions to shell - http://bit.ly/i4Ggp3
<Fallenou>
received 100 milkymist stickers :)
<kristianpaul>
:o
<lekernel>
audio problem fixed
<lekernel>
the lm codec is a little bit more noisy than the wm one, but the amount of noise decreased A LOT :)
<roh>
uh. nice.
<lekernel>
(measuring on scope)
<lekernel>
doing more tests atm, but it seems it works correctly with the lm codec and perfectly with the wm now
<roh>
what did you change?
<roh>
fpga timing of the bits on the wire?
<lekernel>
argh. no. the lm is still as noisy as before
<lekernel>
but the other wm problems are gone
<roh>
hm. weird. maybe its more sensitive?
<roh>
to the problem, not the analog audio ;)
<lekernel>
yeah, timing (not sure it's required, will check) and zeroing of the invalid AC97 channels
<lekernel>
the WM codec requires zeroing (according to the datasheet) but I saw no such thing in the LM datasheet
<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)
<lekernel>
and the wm codec didn't like that, resulting in various noises depending on the soc activity
<roh>
ah
<roh>
so you are trying to find the other but with the lm now or will you switch to the wm for rc3?
<roh>
s/but/bug
<lekernel>
don't know yet
<lekernel>
will test the WM codec a bit more
<lekernel>
it has less noise than my laptop atm
<lekernel>
so it would seem pretty strange that there's a problem with the PCB
<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