| 04:40 | boris317 | Running a cubox-i4pro. Has anyone else noticed that xbmc uses LESS cpu when playing a movie than when displaying the GUI? Like a substantial amount less. |
| 04:45 | boris317 | like ~6-16% cpu when playing a movie as compared to ~20-25% when on the home screen |
| 04:45 | boris317 | 6-12% rather* |
| 04:54 | mk01 | i have 2% at gui |
| 04:55 | boris317 | hmmm |
| 04:55 | mk01 | from top: 2.0 3.6 1:25.62 xbmc.bin |
| 04:55 | boris317 | I wonder wtf xbmc is doing then |
| 04:55 | mk01 | (first num is cpu% , second mem%) |
| 04:55 | mk01 | in depends many times on skin. |
| 04:55 | mk01 | addons |
| 04:55 | mk01 | (running threads) |
| 04:58 | boris317 | no addons. Skin is default I think. I am running geexbox |
| 04:59 | mk01 | just copy custom addons out of addon dir and restart xbmc. you will see whether it is Addon or something else |
| 04:59 | mk01 | boris317: hm |
| 05:00 | mk01 | you can maybe check with strace |
| 05:00 | mk01 | where the process is spending so much time |
| 05:00 | mk01 | strace -c -p $(pgrep xbmc.bin) |
| 05:01 | boris317 | installing strace I will give it a shot |
| 05:01 | mk01 | -c will show cumulated stats (and no output until you ctrl+c) so start it, wait 1min, ctrl+c |
| 05:02 | cbxbiker61 | did you check advanced settings xml for dirty region settings? |
| 05:03 | cbxbiker61 | algorithdirtyregions |
| 08:50 | cbxbiker61 | i'm playing high-def blade runner, it works great |
| 08:51 | cbxbiker61 | main thing, though, when using built-in wifi is to turn wifi power savings off, otherwise it can't keep up |
| 08:52 | cbxbiker61 | even ssh is painful to use with wifi power savings on, all sorts of delays and stalls |
| 09:01 | mk01 | cbxbiker61: yes, it is ... really powersavings make difference for you ??? |
| 09:02 | cbxbiker61 | yes all the difference in the world, that power savings mode really behaves as if it's for a very low power device where response time in non-critical |
| 09:03 | cbxbiker61 | i'm pretty well convinced that the wifi power savings should only be used if running on battery |
| 09:07 | mk01 | I use to turn powersaving off by default with. But had no significant difference in this case. Going to try again. |
| 09:09 | cbxbiker61 | it's also possible that the beacon interval on the wifi router may affect how often it sinks into low power mode, so it may behave differently on other networks |
| 09:09 | mk01 | so iwconfig wlan0 power off |
| 09:09 | mk01 | right ? |
| 09:09 | cbxbiker61 | in my case both ath9k devices and the cuboxi do poorly with wifi power savings on |
| 09:10 | cbxbiker61 | that's right |
| 09:10 | cbxbiker61 | do iwconfig wlan0 to verify |
| 09:10 | mk01 | [ 3] 0.0-10.1 sec 8.75 MBytes 7.24 Mbits/sec |
| 09:11 | mk01 | same "s**t" as before |
| 09:12 | cbxbiker61 | my wifi indicates about 65Mbit...i thought these devices were 150Mbit devices |
| 09:12 | mk01 | nope |
| 09:12 | mk01 | it is 65mbit |
| 09:12 | cbxbiker61 | damn, we need a rev 2, 150Mbit should be min |
| 09:13 | mk01 | btw I forgot I have currently CBi sitting almost directly on my AP |
| 09:14 | cbxbiker61 | me too |
| 09:14 | mk01 | that doesn't work for it ... to get 65mb bitrate I have to move it at least 50cm away |
| 09:15 | mk01 | (in my case) |
| 09:15 | cbxbiker61 | 150Mbit should be min, 300Mbit would be sweet, i guess we'll have to use external if we need the bandwidth |
| 09:15 | cbxbiker61 | i'll look at the xbmc code, i think if i tweek up the caching code a bit 65Mbit would work fine |
| 09:16 | cbxbiker61 | there are some real nice usb 300Mbit adapters now, so i guess all is not lost |
| 09:17 | mk01 | my highest throughput for it was ~15-16mbps, ... this is not enough. on top of the speed , the current driver is sucking live out of the system, it's over-saturated with IRQs etc |
| 09:18 | cbxbiker61 | yeah, usb is probably a better bet, i'll probably recommend the single core cubox with an external 300Mbit adapter for xbmc |
| 09:19 | mk01 | cbxbiker61: yes. it's a way. although for me is wifi on such devices not a real need as they are always sitting at places with cable infrastructure |
| 09:19 | mk01 | cbxbiker61: but is a bit shame that my old ATV2 is doing full 150mbps on WiFi ;) |
| 09:20 | cbxbiker61 | yeah, i need both wired and wireless |
| 09:21 | mk01 | cbxbiker61: btw: if you have high transfers on wifi, do you see something like that in dmesg "net_ratelimit: 14 callbacks suppressed" ? |
| 09:22 | mk01 | cbxbiker61: i will try the brcmfmac driver from 3.14 |
| 09:22 | mk01 | if it is better |
| 09:24 | cbxbiker61 | yeah, i do see a net_ratelimit message |
| 12:17 | dob1 | Hi, I would like to buy a cubox-i, I live in UE, have i to pay duty taxes too? other than vat |
| 12:27 | diget | dob1: don't know about your country but for me in Austria I had to pay toll taxes on delivery. |
| 12:27 | dob1 | diget, can I ask how much? |
| 12:28 | dob1 | I leave near Austria, Italy |
| 12:28 | dob1 | live |
| 12:29 | diget | dob1: I don't remember the exact amount but it was around 20-30 Euros |
| 12:30 | cbxbiker61 | i'm guessing, but [email protected] should work |
| 12:31 | cbxbiker61 | in the US, we have new-egg selling cubox-i directly |
| 12:31 | mal- | buy it via klingler |
| 18:50 | mk01 | jnettlet: online ? |
| 18:54 | jnettlet | mk01, briefly. whats up? |
| 18:57 | jnettle | 18:57 * jnettlet will be back in 30 minutes |
| 18:58 | mk01 | stupid question. |
| 18:58 | mk01 | free() should be indicated on process mem consumption immediately or not ? |
| 18:58 | mk01 | no idea how heap returns work |
| 18:59 | mk01 | but was coding something, freeing ~50mb but process RSS and VM the same as before |
| 19:01 | mk01 | so i traced with gdb, pointers were no NULL before, free finished with no error. and still I see no mem usage decrease |
| 19:13 | ToFi | hi together |
| 19:33 | jnettlet | mk01, the memory may not be shown up as freed immediately. You application just can't use it any longer. |
| 19:34 | mk01 | the aim was to provide mem back to the system. so it is back in heap ? |
| 19:35 | deniska | system will reclaim it later if needed |
| 19:35 | jnettlet | this is userspace memory? |
| 19:35 | mk01 | yes |
| 19:36 | jnettlet | yeah, the linux vm will reclaim it in the background |
| 19:36 | mk01 | ok, thanks. |
| 19:39 | mk01 | jnettlet: second question, ... libGL & DRM. have following error "libGL error: open DRM failed (Operation not permitted) ". strace shows permission error on /dev/dri/card0, but permission is ok |
| 19:40 | mk01 | is it because it is not DRI2 capable ? |
| 19:53 | davorin | under what circuimstances does the cbi display white noise on the hdmi output? |
| 19:54 | davorin | some strange xbmc feature? |
| 20:11 | hste | mk01: what is permissions on /dev/galcore ? |
| 20:11 | mk01 | 666 |
| 20:41 | jnettlet | mk01, sorry was eating dinner. DRI vs DRI2 compatibility won't happen until the device is opened |
| 20:41 | jnettlet | can you check dmesg, the kernel may be spitting out an error there |
| 20:41 | mk01 | no |
| 20:42 | mk01 | but don't have debugging on |
| 20:42 | jnettlet | are you running the application as root? |
| 20:43 | mk01 | yes |
| 20:43 | jnettlet | that is always one way to test permission problems |
| 20:43 | jnettlet | do you have anything like apparmour or selinux enabled? |
| 20:43 | mk01 | no :) |
| 20:44 | mk01 | apparmor removed and selinux=0 as command line |
| 20:44 | jnettlet | this is libGL or libGLES? |
| 20:44 | mk01 | libGL |
| 20:45 | jnettlet | run LIBGL_DEBUG=verbose your_program and see what it spits out |
| 20:45 | mk01 | ok |
| 20:46 | mk01 | actually glxinfo was asking the same, but didn't provide any other info when rerun with verbose |
| 20:47 | jnettlet | can you open the device by hand. od /dev/dri/card0 |
| 20:47 | mk01 | root@cubox:/usr/share/X11/xorg.conf.d# od /dev/dri/card0 |
| 20:47 | mk01 | od: /dev/dri/card0: read error: Invalid argument |
| 20:47 | mk01 | 0000000 |
| 20:47 | jnettlet | okay so there is problem with the dri driver |
| 20:48 | jnettlet | time to reboot with debug enabled |
| 20:48 | mk01 | ok |
| 20:53 | mk01 | [ 86.581634] [drm] Initialized vivante 1.0.0 20120216 on minor 0 |
| 20:53 | mk01 | [ 86.582052] init: Handling module-device-added event |
| 20:53 | mk01 | [ 86.588428] init: Handling platform-device-added event |
| 20:53 | mk01 | [ 86.589471] init: Handling drm-device-added event |
| 20:54 | mk01 | tried od again |
| 20:54 | mk01 | but no other logs |
| 20:55 | jnettlet | and glxinfo also fails? |
| 20:58 | jnettle | 20:58 * jnettlet & |
| 20:58 | mk01 | me of display: :0 |
| 20:58 | mk01 | display: :0 screen: 0 |
| 20:58 | mk01 | direct rendering: No (If you want to find out why, try setting LIBGL_DEBUG=verbose) |
| 20:58 | mk01 | server glx vendor string: SGI |
| 20:58 | mk01 | server glx version string: 1.4 |
| 20:58 | mk01 | server glx extensions: |
| 20:58 | mk01 | GLX_ARB_multisample, GLX_EXT_import_context, GLX_EXT_texture_from_pixmap, |
| 20:58 | mk01 | GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_copy_sub_buffer, |
| 20:58 | mk01 | GLX_OML_swap_method, GLX_SGIS_multisample, GLX_SGIX_fbconfig, |
| 20:58 | mk01 | GLX_SGIX_pbuffer, GLX_SGI_make_current_read |
| 20:58 | mk01 | client glx vendor string: Vivante Corp |
| 20:58 | deniska | oh noes~ |
| 20:58 | mk01 | client glx version string: 1.4 |
| 20:58 | mk01 | client glx extensions: |
| 21:01 | mk01 | jnettlet: but Xorg.log reports DRI2 not supported on display 0 and GLX loading DRISWRAST instead |
| 21:03 | mk01 | [ 327.505] drmOpenDevice: node name is /dev/dri/card0 |
| 21:03 | mk01 | [ 327.506] drmOpenDevice: open result is 10, (OK) |
| 21:03 | mk01 | and also strange Xorg reports Open ok on card0 : |
| 21:19 | mk01 | jnettlet: and last question - how to activate video output through DRM - HDMI ? all the DRM drivers report device busy (I suppose because the Framebuffer drivers have been loaded), but if I disable FB imx, video is no initialised at all. I'm somewhere missing a point there ... :-/ |
| 21:24 | mk01 | jnettlet: and did you test my patch to your DVI patch? HDMI events are running without issues ever since. the question stays whether it didn't break the DVI stuff again. |
| 21:44 | rabeeh | welcome Anssi |
| 21:44 | cbxbiker61 | hi Anssi |
| 21:44 | mk01 | rabeeh: long time no see ! |
| 21:44 | rabeeh | mk01: hey |
| 21:44 | Anssi | hi! |
| 21:44 | rabeeh | mk01: i'm always here; but sometimes hide in the shadows |
| 21:44 | rabeeh | :) |
| 21:45 | rabeeh | mk01: Anssi is alsa master and interested in getting HD audio on CBi |
| 21:45 | mk01 | rabeeh: ninja style |
| 21:45 | rabeeh | mk01: yeah; well... sometime i hate doing that but i just need to push things faster |
| 21:45 | rabeeh | and i'v been busy lately on getting Android 4.4 on CBi |
| 21:46 | mk01 | rabeeh: you mean sometimes you just need to do what you have to do. work :) |
| 21:46 | mk01 | rabeeh: yeah, just went through the post on forum |
| 21:47 | rabeeh | Anssi: let me just get you a brief; the nice citizens of #cubox are variety of devs, users, testers etc... |
| 21:47 | rabeeh | specifically for xbmc there are mk01 whom is mr. Xbian, sraue whom is mr. OpenElec and tomlohave whom is mr. GeexBox |
| 21:48 | rabeeh | i'v previously tried getting wolfgar on #cubox but he doesn't irc |
| 21:49 | rabeeh | gim, cbxbiker61 and others did lots of work on xbmc older generation CuBox and now have the new platforms |
| 21:49 | rabeeh | well.. gimli has C1 but will be getting his CBi4pro soon |
| 21:49 | rabeeh | for any Q please go ahead and flood the channel. |
| 21:50 | Anssi | ok |
| 21:50 | cbxbiker61 | Anssi, where are you located? |
| 21:51 | Anssi | cbxbiker61: in Finland |
| 21:51 | cbxbiker61 | ah, and rabeeh's getting you hardware? |
| 21:51 | Anssi | apparently, yes :) |
| 21:52 | cbxbiker61 | great, i have a good test setup for hd audio |
| 21:52 | mk01 | Anssi: rabeeh is santa now and then :) |
| 21:52 | rabeeh | yes; Anssi just send me shipping address and day contact phone for courier |
| 21:52 | Anssi | just checked first that the hw actually supports hd audio :p - seems it does |
| 21:52 | rabeeh | Anssi: for spdif support; there is optical out on CBi that the photo diode supports up to 15Mbps |
| 21:52 | cbxbiker61 | yeah, fritsch recommended you |
| 21:53 | rabeeh | there is another board called HummingBoard that has coax spdif out |
| 21:54 | cbxbiker61 | rabeeh, did you give him the preferred repo to look at? |
| 21:54 | rabeeh | imx6-xbmc? |
| 21:54 | cbxbiker61 | that's what i'm using |
| 21:54 | Anssi | rabeeh: right, hd audio requires generally more than that, so I'd expect hd audio to work with hdmi only |
| 21:54 | cbxbiker61 | yeah, the kernel tree |
| 21:55 | rabeeh | https://github.com/SolidRun/u-boot-imx6 |
| 21:55 | rabeeh | https://github.com/SolidRun/linux-linaro-stable-mx6 |
| 21:55 | rabeeh | and this one for overview - |
| 21:55 | rabeeh | http://imx.solid-run.com/wiki/index.php?title=Building_the_kernel_and_u-boot_for_the_CuBox-i_and_the_HummingBoard |
| 21:55 | rabeeh | if you want to discuss things; we have very active forums too - |
| 21:56 | rabeeh | http://imx.solid-run.com/forums/index.php |
| 21:56 | rabeeh | Anssi: what does it take to get hd audio on coax/optical spdif? |
| 21:57 | rabeeh | they interfaces do support passthrough |
| 21:57 | cbxbiker61 | yeah, but didn't we decide that optical had a bandwidth cap, that wouldn't allow that |
| 21:57 | cbxbiker61 | hdmi, yes |
| 21:58 | Anssi | rabeeh: TrueHD and DTS-HD MA normally require a 768kHz IEC-60958 link, so one needs to be able to drive the S/PDIF at that frequency, i.e. 24.5 Mbps |
| 21:59 | rabeeh | cbxbiker61: there is coax on HB |
| 21:59 | Anssi | however, I'd be surprised if receivers actually supported that |
| 21:59 | jnettlet | mk01, I am currently working through the DVI issues. it is really an annoying mess. |
| 21:59 | rabeeh | besides that, we can change the optical out to higher end |
| 22:00 | rabeeh | Anssi: oh; ok then. |
| 22:00 | cbxbiker61 | yep, wouldn't think the receiver would expect something outside the spec |
| 22:01 | Anssi | rabeeh: DTS-HD HRA and E-AC-3 only require a 192kHz link, but I'm not sure at the receiver support for that either (but certainly a higher probability than 768kHz) |
| 22:02 | mk01 | jnettlet: I would gladly help, but have only DVI connector on HDMI-TV. and the driver checks EDID info first which the TV provides the same as for HDMI :( otherwise the rest IS DVI compliant ... but this won't really help you, right ? |
| 22:03 | mk01 | Anssi: Yamaha AVRs since 2012 support that for sure |
| 22:04 | mk01 | (DTSHD EAC3 with 192k) |
| 22:04 | jnettlet | mk01, right now it is just how to handle the DVI blanking problems. I have a very hackish workaround and am trying to think of a more elegant solution. Nothing has come to mind yet, except perhaps polling for hpd when in DVI mode. |
| 22:04 | Anssi | mk01: ok then :) |
| 22:05 | jnettlet | I have already implemented a timer instead of a delayed work to help hide some of the interrupts that happen if you don't plug the cable in cleanly. |
| 22:11 | mk01 | jnettlet: I have seen some of the "floods" even on HDMI mostly between plugout until plugin. where are they comming from? from the "new" bits unmasked ? |
| 22:13 | jnettlet | mk01, they are just generated because circuit isn't completely cleanly. Normally on my HDMI drivers I use a jitter timer of 1sec to let things settled down before processing the interrupt |
| 22:13 | jnettlet | I have added that to the mxc driver now |
| 22:14 | rabeeh | jnettlet: internally in CBi/HB; hpd pin is connected to a 3.3v level converter and then connected to imx6 hpd pin |
| 22:14 | rabeeh | (older devices were not 5v tolerant) |
| 22:15 | jnettlet | too bad that hpd pin can't be mapped as a gpio |
| 22:17 | rabeeh | is it monitor specific? |
| 22:18 | rabeeh | i mean you it be that both jnettlet and mk01 are using same monitor? |
| 22:19 | jnettlet | rabeeh, I only see it happen when using DVI, and not monitor specific. |
| 22:19 | jnettlet | I have had multiple reports of this since enabling DVI support in the driver |
| 22:20 | rabeeh | https://groups.google.com/forum/#!topic/wandboard/KgFACCiAEPk |
| 22:20 | rabeeh | ? |
| 22:21 | rabeeh | Boundary used a resistor to perform the voltage translation |
| 22:21 | jnettlet | I think Novena did as well |
| 22:22 | rabeeh | well.. i need to talk to bunnie about that then |
| 22:22 | rabeeh | they should be using a level converter for older devices; and the newer one has the pad tolerant |
| 22:23 | jnettlet | did the Carrier-1 have the older level converter? |
| 22:23 | jnettlet | I wonder if I should test that. |
| 22:23 | mk01 | rabeeh: it is because all the others signals being added as trigger when driver works in DVI mode. |
| 22:24 | rabeeh | jnettlet: yes; same voltage level shifter |
| 22:26 | jnettlet | mk01, I actually am not certain that we actually need the DVI hpd detection now. the hpd bit seems to be accurate, it just needs some of the other handling. |
| 22:27 | jnettlet | especially with the jitter timer it has cleaned up the hpd detection quite nicely. |
| 22:28 | mk01 | jnettlet: heh |
| 22:28 | jnettlet | except for blanked DVI screens. I have that so it behaves better, but it needs more bubblegum and duct tape to detect actual removals when the screen is blanked. |
| 22:29 | jnettlet | these are weird corner cases, but I still want them fixed. |
| 22:34 | mk01 | jnettlet: why is Blank so different ? in HDMI there wasn't much diff. only that clocks were recalculated on unblank. but in-between. If I remember even the overflow interrupts have not been disabled, or ? |
| 22:35 | jnettlet | mk01, it isn't different. It seems to be tickling some sort of hardware oddity |
| 22:36 | jnettlet | I originally thought that the 3.3v of dvi wasn't enough to hold the hpd pad solid, but rabeeh has shot that theory up. |
| 22:37 | mk01 | ok. then. if all this is true, send me last version - I will force DVI in code and run my cubox few days like this attached to DVI tv port, |
| 22:39 | jnettlet | mk01, I need to finish up handling the interrupt loops. will try and get that done tomorrow and will send it to you. |
| 22:39 | jnettlet | I didn't sleep much last night so am heading to bed early tonight |
| 22:39 | mk01 | np. |
| 22:42 | mk01 | it just looks like I could be a (help) even without DVI screen. and family is going out for weekend ... so no stress |
| 22:45 | malte | rabeeh |
| 22:48 | mk01 | this reminds me to one corner case on CEC still. during Standby -> On transition (8s on my TV) in 1 of 20-30 cases Cec message "activate source" gets timed-out. And i'm currently unable to trace it down, ... maybe just really again one "oddity" of my Samsung. last part I have not checked line by line is the code where HDMI disables IRQ during transitions ... so maybe. |