| 12:44 | rabeeh_ | _rmk_: ping |
| 12:58 | _rmk_ | hmm? |
| 12:59 | rabeeh | hi _rmk_ |
| 12:59 | rabeeh | i'm looking back at the log and see the messages about the vsync and hsync questions? |
| 12:59 | rabeeh | i just got back from vacation and trying to catchup. |
| 13:01 | _rmk_ | yea, and I've probably forgotten what they were too :) |
| 13:02 | rabeeh | i'm looking into few threads about this; it's probably a right panned default 1080p output after boot due to a newer HDMI NXP driver? |
| 13:04 | _rmk_ | rabeeh: I think what I was trying to find out was several things: (a) what polarity the NXP chip requires on its inputs, (b) what polarity output the dove chip gives for various settings of its invert sync bits |
| 13:04 | _rmk_ | the cubox being small doesn't make it easy to get a scope on to answer (b) |
| 13:05 | shesselba | _rmk_: for hsync/hvsync polarity, it is not about what nxp wants but what the modeline from edid tells you |
| 13:05 | rabeeh | there is no way you can get the traces on the pcb; those are mostly burried in internal layers and surfaces on via near the chip |
| 13:05 | rabeeh | shesselba: exactly |
| 13:06 | rabeeh | it's using whatever the standard requires. |
| 13:06 | _rmk_ | shesselba: no, that's wrong, because the NXP internally deals with the invert as required |
| 13:06 | _rmk_ | the problem is this: if you invert at the dove LCD controller and then at the NXP, then guess what happens... |
| 13:07 | rabeeh | panned screen? |
| 13:07 | _rmk_ | now, add on top of that that it's completely undocumented what the normal sync output polarity of the dove chip is... |
| 13:07 | _rmk_ | not sure where panned screen gets into this |
| 13:07 | shesselba | well, of course you should have the whole chain to display act as requested by edid |
| 13:08 | _rmk_ | (it doesn't really have anything to do with sync polarity) |
| 13:08 | _rmk | 13:08 * _rmk_ sighs |
| 13:08 | _rmk_ | you know, I do know what I'm talking about on this subject |
| 13:08 | _rmk_ | shesselba: wrong again. what matters is what the display receives. |
| 13:10 | shesselba | _rmk_: 2 things, the whole chain meant cubox -> nxp. you need to make sure that both behave correctly so that the display receives sync as requested |
| 13:10 | _rmk_ | _that_ is what the EDID information specifies - it specifies what the _display_ requires. |
| 13:10 | _rmk_ | no, you're plainly not understanding |
| 13:10 | shesselba | 2nd, 99% of display will just work well if hs/vs polarity is inverted to what is in the edid |
| 13:11 | _rmk_ | The dove chip provides syncs to the NXP chip, which then encodes them into the HDMI data stream |
| 13:11 | shesselba | I know how HDMI works internally |
| 13:11 | _rmk_ | The dove chip sync outputs can be +ve or -ve pulse, depending on the invert state. |
| 13:11 | _rmk_ | The NXP chip can invert these signals as well. |
| 13:11 | _rmk_ | If you program both the dove and the nxp for invert, you end up with _no_ invert. |
| 13:12 | _rmk_ | If you program one, then you get the right thing. |
| 13:12 | shesselba | right, that is why I said "the whole chain" |
| 13:12 | _rmk_ | it's not "you program the while chain" because if you do that you end up with _no_ inversion what so ever |
| 13:12 | _rmk_ | so you _are_ totally wrong on that |
| 13:14 | shesselba | just make nxp _not_ to touch sync polarity and do the correct polarity in cubox |
| 13:14 | _rmk_ | shesselba: which breaks the generic TDA driver in the kernel and makes it cubox specific, so no, not going to do that |
| 13:15 | _rmk_ | rabeeh: I believe the NXP chip you used wasn't a BGA, so if I could run the cubox without the heatsink, I could get a scope on there |
| 13:15 | rabeeh | yes. |
| 13:15 | _rmk_ | from what I remember its buried beneath the daughter board |
| 13:15 | _rmk_ | which is also a problem... |
| 13:16 | shesselba | _rmk_: anyway, if you have an old dvi monitor you can open it and put your scope on the dvi receiver |
| 13:16 | rabeeh | it's on the upper side of the bigger board; just near the HDMI connector |
| 13:16 | shesselba | I have a modified dvi monitor to give you pclk, hs, vs, blank |
| 13:17 | _rmk_ | is it possible to power up the cubox without the daughter board connected? Presumably the pin header is used to supply power rather than the high density connector? |
| 13:17 | rabeeh | yes. |
| 13:17 | rabeeh | the 2 pin headers provides filtered +5V and GND |
| 13:18 | rabeeh | the board to board connector provides RGMII, 1.8v and ground shield |
| 13:18 | rabeeh | so you can run CuBox with those 2 pin header without issues |
| 13:19 | rabeeh | but you will loose ethernet (and ground shield - which is not important for the expierment) |
| 13:19 | _rmk_ | great, just have to make sure the heatsink is on (don't want the dove chip overcooking) |
| 13:20 | rabeeh | _rmk_: if you will be idling then it can live without the heat spreader |
| 13:21 | rabeeh | _rmk_: here is the code that sets the sync polarity - |
| 13:21 | rabeeh | https://github.com/rabeeh/linux/blob/master/drivers/video/dovefb/dovefb_gfx.c#L281 |
| 13:21 | _rmk_ | ubuntu 12.04.2 startup is probably heavy enough, especially with the gpu going. |
| 13:21 | rabeeh | vertical sync - |
| 13:21 | rabeeh | https://github.com/rabeeh/linux/blob/master/drivers/video/dovefb/dovefb_gfx.c#L315 |
| 13:22 | _rmk_ | rabeeh: on the CEC thing, I suggest you just use mdelay(10) - but note, delays in the kernel are not that accurate. |
| 13:22 | rabeeh | and the following #if 1 / #endif is a workaround for the default built-in edid that specified wrongly the polarity of the hsync |
| 13:22 | _rmk_ | they come out slightly shorter than is asked for because of the interrupts |
| 13:23 | _rmk_ | the calibration runs with the timer interrupt running, which steals some CPU cycles from the calculated loops_per_jiffy variable, which if you then run the delay with IRQs disabled results in shorter delays |
| 13:25 | _rmk_ | at the moment you're delaying 20ms because you have a 10 iteration for() loop of 1ms delays followed by a mdelay(10) |
| 13:26 | rabeeh | _rmk_: which code is this? |
| 13:26 | _rmk_ | note that mdelay(10) is just a loop of 10 udelay(1000)'s |
| 13:26 | rabeeh | can this explain why i get 796 bogomips? |
| 13:26 | _rmk_ | this is one of your recent commits for the CEC code |
| 13:27 | _rmk_ | "LK 3.6.8 doesn't like __udelay" |
| 13:27 | _rmk_ | c6e3049add6414dbc1b6cd4a472c01b02f73f3fa |
| 13:27 | _rmk_ | - __udelay(10000); |
| 13:27 | _rmk_ | + for (err = 0; err < 10; err++) |
| 13:27 | _rmk_ | + udelay(1000); |
| 13:27 | _rmk_ | + mdelay(10); |
| 13:30 | _rmk_ | and yes, __udelay() of that value (presumably to work around our 2ms limit on udelay()) probably results in math overflow and a shorter delay |
| 13:31 | _rmk_ | mdelay(10) is what it should've always been there |
| 13:32 | rabeeh | good catch |
| 13:35 | _rmk_ | one of your commits refers to audio stutter - could you explain what that problem was referring to? |
| 13:35 | _rmk_ | and I noticed you changed to always using the external clock |
| 13:38 | rabeeh | those are rudi's fixes - |
| 13:38 | rabeeh | http://www.solid-run.com/phpbb/viewtopic.php?f=11&t=1201&p=6967&hilit=stutter#p6967 |
| 13:39 | rabeeh | it don't know how it's related to the A/V sync on mpeg2 pulldown |
| 13:41 | _rmk_ | hmm, I'll have to try that and see whether it sorts out the playback at 44.1k glitches I'm seeing with the cheap chinese spdif->rca converter |
| 13:50 | rabeeh | _rmk_: glitches because of underrun? |
| 13:51 | rabeeh | there is this post - http://www.solid-run.com/phpbb/viewtopic.php?f=11&t=740&p=7246&hilit=audio+44.1#p7246 |
| 14:17 | _rmk_ | rabeeh: it doesn't hiccup, but the chinese spdif converter seems to pitch-bend every so often with 44.1k but only 44.1k |
| 14:18 | _rmk_ | its very noticable with anything with a tone or held note in it |
| 14:21 | _rmk | 14:21 * _rmk_ lols at "bitrate of 44100"... so a 16-bit stereo pcm file at that bitrate would be a sample rate of 1.378kHz :) |
| 15:52 | _rmk_ | I think it has fixed it |
| 15:52 | _rmk_ | maybe the dove's internal clock rate doesn't result in something close enough to 44.1kHz |
| 16:16 | dbsx | My problem is 48kHz videos, the lag in sound is significant |
| 16:17 | _rmk_ | oh, my problem was with just using a music player for my mp3s on the cubox with this spdif to rca converter |
| 16:18 | _rmk_ | video playback was fine (most of my video stuff is 48kHz) |
| 16:19 | _rmk_ | I'd started not using the cubox for audio playback because of it |
| 16:21 | _rmk_ | its entirely possible that the spdif converter is just cheap'n'nasty and can't cope with a spdif signal slightly off what its supposed to be |
| 16:23 | _rmk_ | being one of these (but I didn't pay that price for it!) http://www.amazon.co.uk/Playvision-2-1Channel-Digital-Surround-Decoder/dp/B009FX9IN8 |
| 16:34 | dbsx | I should re-phrase what I said to -> I have 3 x 48kHz videos that the sound lags. It may be something else in the encoding that is the problem. |
| 16:47 | _rmk_ | ha, I can pick off the sync signals on the hdmi chip in my tv |
| 17:49 | _rmk | 17:49 * _rmk_ wonders why freenode can't run stable irc servers like I can... |
| 17:50 | _rmk_ | wolfe is always having some problem or other |
| 17:50 | _rmk_ | anyway... as I said earlier and you probably didn't see... |
| 17:50 | _rmk_ | heh. this tv outputs the received video as Y+sync, Cr, Cb analog signals to the scaler chip |
| 17:50 | _rmk_ | consequently the syncs are as you would expect on a Y (just like on analog TV) - negative going pulses irrespective of whatever settings at the HDMI encoder/dove LCD controller |
| 17:50 | _rmk_ | tv fail :) |
| 17:50 | _rmk_ | tv fail for content protection too :) |
| 17:50 | _rmk_ | and the tv disables the digital outputs from the hdmi chip |
| 17:53 | _rmk_ | and no, audio extclk doesn't entirely fix my occasional pitch-bending |
| 18:39 | jnettlet | _rmk_, I love that the TV takes the digital hdmi signal and converts it to analog. It wouldn't happen to be a Sharp tv would it? |
| 18:46 | _rmk_ | jnettlet: no, but it's an el-cheapo from many years ago |
| 21:14 | _rmk_ | ok, well, this spdif box really is stupid - it doesn't lock its processing to the incoming spdif at all |
| 21:14 | _rmk_ | but runs of an approximate local clock instead and hopes that its fifos keep up |
| 21:14 | _rmk_ | and don't underrun/overflow... which they keep doing |
| 21:16 | _rmk_ | it has an aux analog input which it passes into an ADC, whose LRCK of course runs at the sample rate... which is 44101Hz if I give it anything between 44kHz and 44.2kHz |
| 21:17 | _rmk_ | and it mixes this input with the spdif |
| 21:17 | rabeeh | :) |
| 21:17 | rabeeh | so; it doesn't do clock recovery from the spdif |
| 21:17 | _rmk_ | that all rather explains the regular pitch-bends when it tries to compensate for the differing data rates |
| 21:17 | _rmk_ | apparantly not |
| 21:18 | _rmk_ | I think they're just using a DSP, feeding the SPDIF straight in and decoding it via the DSP programming itself |
| 21:18 | rabeeh | hmm... i wonder why they did it that way |
| 21:19 | rabeeh | it doesn't support pass through; so all that they need to do is sync on the start of frame of spdif; and feed the data to a dac |
| 21:19 | rabeeh | the clock recovery on spdif should be trivial |
| 21:20 | _rmk_ | yea, annoyingly I don't know what the DSP is, they ground the top of the chip to remove all markings |
| 21:20 | _rmk_ | likewise on an I2C EEPROM, but they didn't do it on the SPI flash chip (which is an EN25F80-75HCP) |
| 21:21 | _rmk_ | nor the ADC which is a ZG7002 (aka CE2632) |
| 21:24 | _rmk_ | I wonder... if I could do clock recovery on the SPDIF myself, compare with the ADC clocks, and use that to slew the 27MHz source (currently a crystal) for the DSP... |
| 21:35 | rabeeh | how would you slew a crystal? |
| 21:35 | rabeeh | changing that to a clk-in from an external clock generator doesn't always work |
| 21:36 | rabeeh | s/changing/replacing |
| 21:36 | rabeeh | i suggest throw that spdif converter and buy a 2$ USB audio dongle |