| 00:10 | dv_ | yay |
| 00:12 | rmk | 00:12 * rmk_ wonders how other people find the stability of their cuboxes :) |
| 00:14 | dv_ | havent had these issues so far |
| 00:14 | dv_ | although I havent played much audio yet |
| 00:15 | dv_ | I have encountered problems with some vmeta gstreamer plugins and with mesa, however. "Illegal instruction" |
| 00:15 | rmk_ | I'm surprised; I've been hitting bugs all over the place |
| 00:15 | dv_ | what distro do you use? |
| 00:16 | rmk_ | ubuntu precise 12.10 armhf, but... many of these are kernel bugs |
| 00:16 | dv_ | ah. I use arch linux arm |
| 00:16 | dv_ | most likely these two use different kernels |
| 00:17 | rmk_ | I doubt they use a different gpu driver |
| 00:17 | rmk_ | I checked the gpu driver in the olpc stuff (they've got the same IP) and the same bugs exist there too |
| 00:17 | dv_ | that is true though |
| 00:18 | dv_ | but tbh, I avoided ubuntu, because I wanted something lean, and because ubuntu is so I/O heavy, the poor sd card cant keep up |
| 00:18 | rmk_ | if you do something heavy with the gpu, it's semaphores fail, and it then starts overwriting its command queue, which then causes the gpu to start scribbling throughout physical memory |
| 00:18 | dv_ | does not sound good :/ |
| 00:20 | rmk_ | another bug: the marvell i2c driver which gets used for talking to the hdmi chip... uses interruptible waits from locations where being interrupted by a signal can't be handled, and that causes the hdmi driver to error out |
| 00:21 | dv_ | hey, do you have these bugs summarized somewhere? I'd be interested |
| 00:21 | rmk_ | unfortunately not; I've been attacking this in my spare time |
| 00:22 | dv_ | if you can, write them down, and put them online somewhere. the wiki, or some pastebin/pastie service (give me a link then) |
| 00:22 | dv_ | unfortunately I dont have the time for in-depth cubox hacking for the next few weeks |
| 00:23 | rmk_ | my motivation behind this is to have a decent ARM based media player; I did try stuff like geexbox but I found that extremely buggy, unable to play the video streams I have, and seemed to be more about flash looks than anything else |
| 00:23 | rmk_ | oh, and rather slow |
| 00:24 | dv_ | my interest is GLES- and gstreamer-related |
| 00:24 | rmk_ | ah. gstreamer with vmeta is another can'o'worms :) |
| 00:24 | dv_ | i'm planning on gathering & writing plugins for various hw decoder engines, such as marvell vmeta, TI codecengine, and whatever freescale uses |
| 00:25 | dv_ | since I am really sick and tired of using half-broken plugins that have been abandoned years ago and didnt get the overhaul and modernization they needed |
| 00:25 | rmk_ | with mpeg transport streams, the demuxers either don't parse the stream, or don't frame the stream in a way that the vmeta decoder likes (I don't think the demuxers are supposed to frame them... I think the vmeta decoder should cope itself) |
| 00:26 | dv_ | yes, this is a good example |
| 00:26 | dv_ | these days, gstreamer has dedicated parser and decoder base classes, which separate concerns cleanly |
| 00:26 | dv_ | but many of these plugins are written in the old style, that is, they do everything themselves |
| 00:26 | dv_ | (badly) |
| 00:27 | rmk_ | you can test that rather simply - use gstreamer to demux the video to a file. then use filesrc to pipe that into vmeta... and the vmeta plugin explodes because it tries to stuff everything it gets into its buffers before doing anything else |
| 00:28 | dv_ | I think I have seen something like that already |
| 00:28 | dv_ | when it didnt crash, it caused me headaches because the pipeline didnt stop prerolling |
| 00:29 | rmk_ | yea, I keep seeing that with gstreamer, and I don't need vmeta to do it :( |
| 00:29 | dv_ | well often, a queue is missing |
| 00:29 | dv_ | the pipeline deadlocks |
| 00:29 | dv_ | solution: add a queue element |
| 00:30 | rmk_ | sometimes, sometimes with plentiful queues it still doesn't fix it |
| 00:30 | dv_ | with some encoders, the default settings give you extremely slow encoding, vp8enc in particular is guilty of this |
| 00:30 | dv_ | however, these things have improved at least for me a lot with 1.0 |
| 00:31 | dv_ | but well, now -> sleep. later |
| 00:31 | rmk_ | btw, if you're going to do anything with the vmeta plugin... on armhf, you don't need libmiscgem.so |
| 00:32 | dv_ | okay |
| 00:32 | rmk_ | or armel for that matter |
| 00:32 | dv_ | thanks :) |
| 00:32 | rmk_ | you just need to provide the appropriate functions in the callback table for memory management... just like the examples in the marvel-ipp package do |
| 00:38 | dun | 00:38 * dung wonders |
| 00:39 | dung | a bridge between vmeta and open decoders |
| 00:40 | rmk_ | what do you mean? |
| 00:42 | dung | no need for marvell-ipp. i thought of a gestreamer-plugin, with e.g ffmpeg. but i've no insight |
| 00:43 | rmk_ | ah, no, I don't think that's possible... all the details about driving the vmeta hardware are in the closed source libraries... ffmpeg itself isn't fast enough on arm to do decoding at 'desirable' resolutions |
| 00:46 | dung | as far as i can see i thought libav is a collection of decoders. why not vmeta? would solve all distros at once |
| 00:46 | rmk_ | libav does have a plugin mechanism for hardware decoders... it's the libva stuff (I've been working on that) |
| 00:47 | rmk_ | I've managed to bolt vmeta into that, but only for mpeg4 and mpeg2 streams, and only by doing a fair amount of reconstruction... and it's not exactly stable at the moment |
| 00:48 | rmk_ | vmeta keeps throwing a fit if, for example, you rewind to the start of a stream |
| 00:48 | rmk_ | haven't figured that one out yet :( |
| 00:49 | rmk_ | and as for h264... that's completely failing for me at the moment - vmeta for whatever reason seems to take 3 seconds over the first frame (!) of the 60 second test stream I have. |
| 00:50 | dung | i don't do much testing here. all i can plug into cubox is ethernet :p |
| 00:52 | dung | i heard h264 is important for mkv |
| 00:53 | rmk_ | heh. my cubox test setup is... a logitech usb wireless keyboard/mouse, 8GB SD card for the rootfs, ether for nfs for the video streams, a toslink to rca converter box, hdmi switch and hdmi tv. |
| 00:53 | rmk_ | yes, and for HD TV (such as freesat) |
| 00:53 | rmk_ | and the uk HD terrestrial freeview services too |
| 00:54 | rmk_ | but at the moment I haven't found the magic solution to make it work (and much of this is guesswork) |
| 00:55 | rmk_ | well, educated guesswork, but still guesswork |
| 00:56 | dung | what about the gstreamer leak? |
| 00:57 | rmk_ | well, gstreamer doesn't want to even demux my h264 stream (it's another mpeg transport stream) |
| 00:58 | dung | s/leak/lag/ |
| 00:59 | rmk_ | which way does it lag? video behind the audio? |
| 01:01 | rmk_ | well, having encountered the problems with vmeta into libva, that's what I'd expect it to do. :( |
| 01:04 | dung | ffmpeg does it on i386, GL - another story. i still hope for gstreamer, libav, and vmeta. |
| 01:05 | rmk_ | i386 has a bit more umpf than a single-core 800MHz ARMv7 cubox. |
| 01:06 | dung | g* |
| 01:14 | dung | i meen i hope for a bridge from vmeta to whatever app. they did it with 600 lines for xbmc |
| 01:15 | dung | less is better than more ;) |
| 01:16 | rmk_ | at that line count its not libva based then |
| 08:26 | rabee | 08:26 * rabeeh seems to have missed some fun |
| 08:27 | cbxbiker61 | is rabeeh home? |
| 08:27 | rabee | 08:27 * rabeeh @ work |
| 08:28 | rabeeh | cbxbiker61: saw your firewall post; how did you manage the second ethernet port? |
| 08:28 | cbxbiker61 | a usb based eth 10/100 |
| 08:30 | cbxbiker61 | my i686 firewall had two eth ports to start with, then one of them died so i bought the usb eth, and when my power brick dies on the i686 machine i decided to swap over to cubox |
| 08:30 | cbxbiker61 | the usb eth probably adds about 1ms to the ping time, but i can live with that |
| 08:32 | rabeeh | is it stable enough ? (the usb-ethernet) |
| 08:32 | rabeeh | how long has it been living? |
| 08:35 | rabeeh | rmk_: can you please point out what are the issues with Kirowkkd audio driver? |
| 08:36 | rabeeh | s/Kirowkkd/Kirkwood |
| 08:36 | jnettlet | rabeeh, I do most my dev work with XO's connected to usb ethernet adapters. Mostly Zoltan zu-80's |
| 08:36 | cbxbiker61 | i've been using the usb-ethernet for a year or so without problem, i've only had it on the cubox for 3 days |
| 08:37 | rabeeh | the driver by itself works great; but once you plug it in with xbmc passthrough doesn't play and all sort of stuff |
| 08:37 | rabeeh | i'v tried numerous asound.conf posted on the forums but neither helpd out |
| 08:37 | cbxbiker61 | it does take a patch to fix the 3.5.x kernel's for cubox though, they munged some of the optimizations that the cubox driver uses |
| 08:38 | cbxbiker61 | uses/used, i saw you did some of the work on the eth driver |
| 08:39 | rabeeh | yes. one of the initial work |
| 08:39 | jnettlet | rabeeh, what driver does the cubox use for hardware rng? |
| 08:40 | rabeeh | hardware rng? |
| 08:40 | jnettlet | random number generation for encryption |
| 08:41 | rabeeh | it doesn't have one |
| 08:41 | rabeeh | its an acceleration security engine that you give it IV, key and message and you get the encrypted |
| 08:42 | rabeeh | you can use physical sensors though to create random number generation engine |
| 08:43 | rabeeh | physical sensors inside the chip like process, voltage, temperature |
| 08:43 | rabeeh | but i'm not sure if that can't be hacked since it's not an engine the is true rng |
| 08:43 | cbxbiker61 | it seems that i saw someone had come up with an rng that gathers entropy from ethernet |
| 08:44 | rabeeh | every drive can register itself to add up to entropy |
| 08:44 | rabeeh | but those are no true rng; since everything can be controller by an external hacker to reproduce exact numbers |
| 08:45 | rabeeh | (for instance disconnect ethernet and you won't get interrupts that adds up to the entropy) |
| 08:47 | cbxbiker61 | my i686 firewall had rng that was gathered from rf generated in the chip, i think that was a via chip |
| 08:50 | jnettlet | cbxbiker61, if it is a via chip then there is a dedicated hardware rng built into it. |
| 08:51 | cbxbiker61 | yeah, it works by picking up the rf generated in the chip |
| 08:52 | cbxbiker61 | quite ingenious if you ask me, seems simple and effective |
| 08:54 | jnettlet | yeah I did a lot of the early hacking on the VIA stuff. I was a core dev for the openchrome graphics driver for a long time. |
| 08:57 | jnettlet | rabeeh, the Armada 610 has hardware entropy generation (digital and analog) It is part of the trusted boot portion of the SOC |
| 08:59 | jnettlet | I guess we get that since we don't have the full crypto engine |
| 10:11 | rmk_ | rabeeh: its all on lakml :) |
| 10:29 | ralix | morning |
| 10:44 | rabeeh | ralix: morning |
| 10:45 | ralix | morning rabeeh , How are you? |
| 10:45 | rabeeh | great. |
| 10:46 | rabeeh | we have some minor spammers attack on the forums |
| 10:49 | rmk_ | rabeeh: if the audio problem I found occurs, you'll know about it because the kernel silently locks up |
| 10:49 | ralix | I had previously wondered even with a thread,i think it's just not |
| 10:49 | rabeeh | rmk_ i haven't seen any lockups |
| 10:50 | rabeeh | the main issues i'm seeing today is how to make the passthrough work back again |
| 10:51 | rabeeh | the original kernel 2.6.32.9 uses an audio driver that is not the mainlined kirkwood audio driver (but it works and passthrough works without issues) |
| 10:51 | rabeeh | i'm trying to figure out is this an asound.conf issue or the kernel driver is missing something. |
| 10:52 | rmk_ | hmm, don't know about that; all I know is that vlc and pulseaudio work fine with what we have. |
| 10:53 | rmk_ | on the hwmon driver in your kernel, where did the vcpu and vcore stuff come from? that's undocumented, and reading those sysfs files triggers the over temp interrupt |
| 10:53 | rmk_ | and I'm not entirely convinced of the accuracy of those values |
| 10:54 | rabeeh | there is an ADC inside the chip that can get input from temp sensor, cpu voltage and peripherals voltage (called core) |
| 10:54 | rabeeh | which? the voltage or the temperature? |
| 10:55 | rmk_ | voltage |
| 10:55 | rabeeh | the voltage is measured on the die, which is the voltage on the DC-DC rail minus the IR drop until it reaches the die |
| 10:55 | rabeeh | the temperature is also on the die; |
| 10:56 | rmk_ | both PMU_TDC0_SEL_IP_MODE_MASK and PMU_TDC0_SEL_VSEN_MASK in my 2011 functional spec are marked as "reserved" |
| 10:56 | rabeeh | oh |
| 10:56 | rabeeh | that's from the spec on the web? |
| 10:56 | rmk_ | yup |
| 10:57 | rmk_ | Doc. No. MV-S105142-U0, Rev. D |
| 10:57 | rmk_ | August 3, 2011, Preliminary |
| 10:57 | rabeeh | ok. i'll ask Marvell to update then |
| 10:58 | rmk_ | unfortunately, as I don't have a current contract with Marvell, I can't get specs directly from them anymore. |
| 10:58 | rabeeh | rmk_ those are the specs as-is |
| 10:58 | rabeeh | i mean the ones that are sent to customers under NDA and the public are identical |
| 10:59 | rmk_ | so rev.D is still the latest? |
| 10:59 | rabeeh | yes |
| 11:00 | rabeeh | i'm checking now again |
| 11:01 | rmk_ | It would also be good to find out whether we're supposed to be using those two bits too :) |
| 11:01 | rabeeh | those two bits are from Marvell based code |
| 11:01 | rabeeh | so either way we can use them :) |
| 11:01 | rmk_ | only if they don't cause problems... and they do if you use the IRQs |
| 11:02 | rabeeh | :) |
| 11:02 | rabeeh | come on; the logic is simple |
| 11:02 | rmk_ | so I'm thinking there's a reason they're marked as reserved in the manual |
| 11:02 | rabeeh | single ADC that gets three feeds; the threshold is set for temp sensing; but once you switch to voltage you hit IRQ |
| 11:03 | rmk_ | yes, I understand that |
| 11:03 | rabeeh | rmk_ - i was worried for a second :) |
| 11:03 | rmk_ | but... this chip is soo crapped up its unbelievable... and we can't really work around that |
| 11:03 | rmk_ | you really don't want to be clearing those interrupts unnecessarily |
| 11:04 | rmk_ | because the PMU IRQ cause register is read-write - not write-N-to-clear. |
| 11:04 | rabeeh | what do you mean crapped up? |
| 11:04 | rmk_ | just like the LCD IRQ cause register |
| 11:04 | rmk_ | I mean: broken and badly designed |
| 11:04 | rabeeh | why? |
| 11:04 | rmk_ | because you can't clear interrupts in a race free manner |
| 11:05 | rabeeh | which one exactly? |
| 11:05 | rmk_ | any of the PMU or LCD interrupts |
| 11:05 | rmk_ | if you write ~0 to the PMU IRQ cause register, you set all the IRQ bits. |
| 11:05 | rmk_ | if you write 0, you clear all the bits |
| 11:06 | rmk_ | if you do a read-modify-write, any IRQ which occurs _after_ you've read the register gets cleared |
| 11:06 | rmk_ | and, therefore, you lose the IRQ |
| 11:08 | rmk_ | I've actually tried this, because I first thought that the manual was wrong about these bits being RW and not RW0C or RW1C, but they really are RW. |
| 11:09 | rmk_ | I made the clearing in show_alarm() write ~val back to the register... and lo and behold, 12 bits get set, and the RTC receives an IRQ. |
| 11:09 | rabeeh | you are right |
| 11:09 | rabeeh | just checked PMU IRQ; and it really gets set on writing ~0 |
| 11:10 | rabeeh | but if you read it back again it gets zeroed |
| 11:10 | rabeeh | i wonder if Marvell has an errata on this |
| 11:10 | rmk_ | the PMU IRQ cause register never zeros for me unless its explicitly written with zero |
| 11:10 | rabeeh | http://pastebin.com/W9itFVtP |
| 11:12 | rabeeh | i think it's setting on different clock domain, and takes some time to get updated |
| 11:12 | rmk_ | that readback of ~0 is suspicious too, there's only 12 writable bits there |
| 11:13 | rmk_ | err. |
| 11:13 | rmk_ | Value at address 0xB6F260D8 (0xf10d0050): 0x0 |
| 11:13 | rmk_ | why aren't the LSB 11 bits of the virtual address the same as the phys address? |
| 11:13 | rmk_ | that's rather a requirement due to the way the MMU works |
| 11:13 | rmk_ | so I don't think you're hitting the register you think you are |
| 11:15 | rmk_ | any more bugs you'd like me to find :) |
| 11:21 | rmk_ | what you _should_ get (this is a known working devmem2): |
| 11:21 | rmk_ | Value at address 0xF10D0050 (0xb6fd3050): 0x408 |
| 11:22 | rmk_ | which is correct for me, because I have the thermal thresholds set to 65 and 80C, and its running at 55C |
| 11:25 | rmk_ | devmem2 _should_ be doing this: |
| 11:25 | rmk_ | map_base = mmap(0, MAP_SIZE, PROT_READ | PROT_WRITE, MAP_SHARED, fd, target |
| 11:25 | rmk_ | & ~MAP_MASK); |
| 11:25 | rmk_ | if(map_base == (void *) -1) FATAL; |
| 11:25 | rmk_ | printf("Memory mapped at address %p.\n", map_base); |
| 11:25 | rmk_ | fflush(stdout); |
| 11:25 | rmk_ | virt_addr = map_base + (target & MAP_MASK); |
| 11:26 | rmk_ | I suspect you've picked up a version which someone else has modified :( |
| 11:33 | rabeeh | 80c is way too low |
| 11:33 | rabeeh | 80c on the die means something like 40c ambient, given the size of CuBox |
| 11:34 | rabeeh | 55c when it's working? what's the room temperature you are working at? :) |
| 11:34 | rabeeh | rmk_ : on #cubox there are two video and graphics devs |
| 11:35 | rabeeh | first is janne - he previously ported crystalhd (and I think panda board video engine) to libav |
| 11:35 | rabeeh | Zoxc - he is a dev on Wayland |
| 11:36 | rabeeh | cut and paste from previous discussion with Zoxc - |
| 11:37 | rabeeh | to get Wayland on CuBox you need part of EGL opened to get support for sharing buffers between processes and windows system |
| 11:39 | rabeeh | there is also shesselba (Sebastian Hasselbrath) that ported u-boot to head and added DT / generic clock driver to CuBox / Dove |
| 11:40 | rabeeh | rmk_ : i'm also on discussions with NXP with regards their weird licensing driver (that will never hit mainline because of licensing and HAL based coding style) |
| 11:41 | rabeeh | they have suggested providing minimal register access for the HDMI tx, but that will be good only in DVI mode (while removing CEC, Audio) |
| 11:48 | rmk_ | rabeeh: about 18C... oh and the on-die temperature drops by 5C if I take the cubox out of the black box so the metalwork can benefit from convection |
| 11:52 | rmk_ | yes, I've seen the crystalhd libva stuff while poking about the libva site |
| 12:02 | rmk_ | as for getting vmeta working with libva... the _only_ way I've found which works for mpeg4 and mpeg2 is to reconstruct the stream headers from the libva data, pass that and the supplied slices to vmeta, and then top it off with the vmeta specific end-of-unit and 64K worth of end-of-stream padding to force vmeta to produce one frame with no pipelining... and repeat the process (minus some of the initial data) for the next frame |
| 12:03 | Punkley_Chillin | you had me at mpeg4 :) |
| 12:04 | rabeeh | rmk_ how is h.264 doing on the other hand? |
| 12:04 | rmk_ | Punkley: oh, don't worry, over the last 4 months I've learnt more about mpeg than I ever wanted to... including decoding bitstreams by hand |
| 12:04 | rabeeh | you had issues about high cpu utilization? |
| 12:04 | Punkley_Chillin | rmk_ im almost done building packages for 12.10 so it would be good to get something included :) |
| 12:04 | rabee | 12:04 * rabeeh smiles |
| 12:04 | rmk_ | I can't get H264 working at all, and given the state of gstreamer, I can't even feed my H264 data to vmetadec. |
| 12:05 | rmk_ | because gstreamer is not able to demux my h264 transport streams |
| 12:05 | rmk_ | vlc can. |
| 12:05 | Punkley_Chillin | rmk_ I build content delivery networks, today I discovered someone who is in the "streaming video Industry for years" doesn't know the difference between rtmp rtp rtsp and HLS |
| 12:05 | rmk_ | this is why I much prefer vlc |
| 12:05 | jnettlet | rmk_, what version of gstreamer? |
| 12:06 | rmk_ | the version in ubuntu 12.10 (which seems to be 0.10) |
| 12:06 | jnettlet | rmk_, I have vmeta gstreamer decoding h264 on the XO 1.75 |
| 12:06 | rmk_ | oh, I don't doubt it can do it |
| 12:06 | Punkley_Chillin | it will decode h264 |
| 12:06 | Punkley_Chillin | you need to parse it first |
| 12:06 | Punkley_Chillin | let me look if I still have the line |
| 12:07 | rmk_ | what I'm saying is that gstreamer won't touch my transport streams, the demuxers error out despite allegedly supporting mpeg transport streams |
| 12:07 | rabeeh | rmk_ - jnettlet are rewriting the marvell gstreamer stuff |
| 12:07 | jnettlet | rmk_, I am working on switching it to dmabuf |
| 12:07 | Punkley_Chillin | ! qtdemux ! vmetadec ! ffmpegcolorspace ! bmmxvideosink |
| 12:08 | rmk_ | jnettlet: that being part of drm? |
| 12:08 | jnettlet | rmk_, yep |
| 12:08 | jnettlet | and UMM |
| 12:08 | rmk_ | because... I have a full suite of accelerated X driver, kernel side drm, etc which works wonderfully... but no one's paying me for it so I'm not releasing it. |
| 12:08 | Punkley_Chillin | I just want the marvell gstreamer stuff to support multiple threads |
| 12:09 | Punkley_Chillin | drm u say, with gstreamer? |
| 12:10 | rmk_ | it even supports the current bmmxvideosink, and my bmmxvideosink uses an xvmc-like passthrough of buffers to the X server. |
| 12:10 | rmk_ | (that's a stage in eliminating the X server from the majority of the video path) |
| 12:11 | Punkley_Chillin | nice |
| 12:11 | rmk_ | but, as I say, I've not had funding for this, and I've put in many months of work into it, so I'm in no mood to just publish it for nawt... especially as its been taking time away from "proper work" |
| 12:12 | Punkley_Chillin | what is this proper work you speak off? |
| 12:12 | Punkley_Chillin | is it like what I should be doing atm. |
| 12:12 | rmk_ | probably :) |
| 12:12 | rabeeh | hahaha |
| 12:12 | rabeeh | same here :) |
| 12:13 | jnettlet | rmk_, well I can mention it to the Marvell qseven team. They are working on yet another driver implementation |
| 12:13 | jnettlet | I have been trying to organize something, but it is a bit like herding cats. |
| 12:13 | rabee | 12:13 * rabeeh knows what jnettlet is talking about |
| 12:13 | rmk_ | but my own, private, motivation in this is to have a decent ARM based media platform... which platforms like OMAP have totally failed for me with so far. |
| 12:14 | rabeeh | rmk_ - the hardware is there |
| 12:14 | rabeeh | vmeta today plays blu ray h.264 advanced main profile, audio support with external clock that has -+30 ppm jitter for hi-fidelity |
| 12:14 | rabeeh | what we are missing is more and more devs around CuBox |
| 12:15 | rmk_ | I've been wishing for an ARM board which I can throw in the living room to play back the video streams I have access to... and the cubox is finally that platform if all the quirks and bugs can be sorted. |
| 12:17 | rmk_ | rabeeh: if I were to go and buy one of the DVB-T2 USB sticks, put it in the cubox, I would not be able to play back UK HD content on the cubox, because gstreamer can't demux the transport stream. |
| 12:18 | rmk_ | gstreamer can't even demux the SD transport streams either. |
| 12:18 | rmk_ | its all rather... sad really. |
| 12:22 | rabeeh | rmk_ : how is demux related to vmeta? |
| 12:23 | rabeeh | rmk_ : it's a crappy driver that defaults ships from Marvell; but i think it can be replaced (with gstreamer pipeline creation) with other demuxers - right? |
| 12:23 | jnettlet | rmk_, do you mean demux in hardware? mpegtsdemux should work just fine |
| 12:23 | rabeeh | there isn't demux in hardware in CuBox |
| 12:23 | rmk_ | mpegtsdemux does _not_ work |
| 12:23 | rmk_ | well, not on all ts streams |
| 12:25 | rmk_ | $ gst-launch filesrc location=/srv/Videos/Unwatched/20120930_200000_bbconehd_andrew_marrs_history_of_the_world.ts \! mpegtsdemux \! fakesink |
| 12:25 | rmk_ | Setting pipeline to PAUSED ... |
| 12:25 | rmk_ | and that's all it does |
| 12:25 | rmk_ | Pipeline is PREROLLING ... |
| 12:25 | rmk_ | sometimes it spits this out: |
| 12:25 | rmk_ | ERROR: from element /GstPipeline:pipeline0/GstMpegTSDemux:mpegtsdemux0: Could not determine type of stream. |
| 12:25 | jnettlet | and ffdemux_mpegts reacts the same? |
| 12:25 | rmk_ | Additional debug info: |
| 12:25 | rmk_ | gstmpegtsdemux.c(2931): gst_mpegts_demux_sink_event (): /GstPipeline:pipeline0/GstMpegTSDemux:mpegtsdemux0: |
| 12:26 | rmk_ | No valid streams found at EOS |
| 12:26 | rmk_ | well, vlc can play it. |
| 12:26 | rmk_ | that's a HD stream, this is a SD stream of the same programme: |
| 12:27 | rmk_ | Setting pipeline to PAUSED ... |
| 12:27 | rmk_ | Pipeline is PREROLLING ... |
| 12:27 | rmk_ | ... waits ... it's reading gobs of data over the network... |
| 12:27 | rmk_ | for some reason, I don't have ffdemux_mpegts in the ubuntu 12.10 gstreamer offerings |
| 12:28 | ralix | I have exactly the problem USB Stick DVB-S2 and HD content from all of TVHeadend is stutteringI have exactly the problem USB Stick DVB-S2 and HD content from all of TVHeadend is stuttering |
| 12:29 | ralix | ups sorry for cut and paste (2lines) ;-) |
| 12:29 | rmk_ | however... on x86, ffdemux_mpegts seems to work but mpegtsdemux fails with these |
| 12:31 | rmk_ | note that flutsdemux behaves in the same way as tsdemux on these. |
| 12:32 | rmk_ | and I have other ts streams where flutsdemux into vmeta just produces half a picture with the bottom half corrupted |
| 12:34 | rmk_ | (and that's because vmeta makes assumptions of the demuxer behaviour) |
| 12:37 | mooglemoogle | #cubox |
| 12:37 | mooglemoogle | Hi rabeeh |
| 12:37 | mooglemoogle | Just go a PM from you to come to this room |
| 12:38 | mooglemoogle | I posted on the Cubox forum to explain why I was disappointed with Cubox |
| 12:38 | rmk_ | do you have a url to that post? |
| 12:39 | mooglemoogle | http://www.solid-run.com/phpbb/viewtopic.php?f=2&t=714&start=40 |
| 12:40 | mooglemoogle | "Total disappointment - WHY?!?" |
| 12:41 | mooglemoogle | I am at work at the moment and so cannot chat for long |
| 12:43 | rmk_ | what format are your 1080p files? |
| 12:44 | mooglemoogle | To be honest, 1080P is not main priority |
| 12:44 | mooglemoogle | Just getting FLAC (5.1 DTS) to play properly would be a good start |
| 12:44 | mooglemoogle | (via SPDIF) |
| 12:46 | mooglemoogle | I think the 1080P problem I have is related to the fact that Passthru is broken in the latest builds of Geexbox |
| 12:46 | mooglemoogle | And so software is having to work hard to re-encode to stereo |
| 12:46 | mooglemoogle | Earlier builds an I just get distorted sound |
| 12:47 | mooglemoogle | Someone on the forum has suggested I try Archlinux method which I will give a go tonight |
| 12:47 | mooglemoogle | Geexbox seems a bit broken for the moment |
| 12:47 | mooglemoogle | Unless you are using analogue sound |
| 12:47 | rmk_ | hmm. don't know about that; from what I remember from back in 2000 when I was working on an AES-based audio system, SPDIF is just consumer AES and AES only supports two channels in the data stream... but things might have moved on. |
| 12:47 | mooglemoogle | No SPDIF certainly supports 5.1 |
| 12:48 | mooglemoogle | I already use my PS3 using custom firmware to play back 5.1 DTS flac |
| 12:48 | rmk_ | wonder how they squash that into the frames then |
| 12:48 | rmk_ | must be a compressed stream |
| 12:48 | mooglemoogle | not sure to be honest |
| 12:48 | rmk_ | I know rabeeh said earlier today that he's looking at the spdif passthrough and trying to work out what's going on there |
| 12:49 | mooglemoogle | sounds great if he can get it working properly |
| 12:49 | mooglemoogle | Is he the only developer working on the project? |
| 12:50 | rmk_ | 09:50 < rabeeh> the main issues i'm seeing today is how to make the passthrough work back again |
| 12:50 | rmk_ | 09:51 < rabeeh> the original kernel 2.6.32.9 uses an audio driver that is not the mainlined kirkwood audio driver (but it works and passthrough works without issues) |
| 12:50 | rmk_ | 09:51 < rabeeh> i'm trying to figure out is this an asound.conf issue or the kernel driver is missing something. |
| 12:50 | mooglemoogle | cool - thx |
| 12:50 | rmk_ | moogle: I don't know, I've only been on this channel since yesterday |
| 12:51 | rmk_ | I have my own pile of 'issues' with the cubox but they're not really cubox specific (more a case of gstreamer not liking my video streams) |
| 12:51 | mooglemoogle | I am glad that rabeeh pointed me in the direction of this IRC room |
| 12:51 | rmk_ | since the same version of gstreamer on x86 suffers too |
| 12:52 | mooglemoogle | Sounds tough! |
| 12:52 | jnettlet | rmk_, can you post a sampling of one of your misbehaving videos. I would like to throw it at my config |
| 12:52 | mooglemoogle | In some ways an more straightforward problem though! |
| 12:53 | mooglemoogle | I can try tonight |
| 12:53 | mooglemoogle | I am at work currently |
| 12:53 | mooglemoogle | (UK timezone) |
| 12:53 | jnettlet | or one on the internet some where, I can download that has a similar problem |
| 12:53 | rmk_ | moogle: yours could be too :) |
| 12:53 | rmk_ | moogle: I'm a uk-ian too :) |
| 12:53 | mooglemoogle | excellent |
| 12:53 | mooglemoogle | (and sorry for crossing conversations!) |
| 12:54 | rmk_ | jnettlet: I'll see what I can do... |
| 12:54 | dotarra | 12:54 * dotarray waves at mooglemoogle |
| 12:54 | Punkley_Chillin | he mooglemoogle just wondering with your post, have you used the installer? |
| 12:54 | dotarray | i was just replying to you in the forums :) |
| 12:54 | mooglemoogle | Yes - used installer first |
| 12:54 | Punkley_Chillin | geexbox? |
| 12:55 | mooglemoogle | And then tried using some of the development builds |
| 12:55 | mooglemoogle | geexbox yes |
| 12:55 | Punkley_Chillin | wow |
| 12:55 | Punkley_Chillin | that just worked for us |
| 12:55 | mooglemoogle | wounder |
| 12:55 | mooglemoogle | are you using SPDIF for the sound? |
| 12:55 | Punkley_Chillin | using hdmi |
| 12:55 | mooglemoogle | aha |
| 12:55 | mooglemoogle | could be the difference |
| 12:56 | Punkley_Chillin | I actually changed a asound option |
| 12:56 | mooglemoogle | SPDIF is my main reason for getting the Cubox |
| 12:56 | Punkley_Chillin | to make it play nicer, it was all poppy |
| 12:56 | mooglemoogle | Since want to stream 2496 flac to my Cyrus AV box |
| 12:56 | mooglemoogle | And it does not support HDMI |
| 12:57 | Punkley_Chillin | I have to admit I haven't tried spidf |
| 12:57 | Punkley_Chillin | spdif even |
| 12:57 | mooglemoogle | Did you edit the config files? |
| 12:57 | Punkley_Chillin | but it should work pretty much the same as hdmi, did u get any audio at all? |
| 12:57 | mooglemoogle | to get your sound working via HDMI |
| 12:58 | Punkley_Chillin | not on geexbox |
| 12:58 | rmk | 12:58 * rmk_ has one of those chinese toslink to rca converters of variable quality. |
| 12:58 | Punkley_Chillin | :) |
| 12:58 | rmk_ | where "variable quality" really does mean that... I've been through three of them so far all with different problems. |
| 12:59 | mooglemoogle | On 3.0 stable, I get distorted sound |
| 12:59 | Punkley_Chillin | like scratchy? |
| 12:59 | mooglemoogle | 20121115 onwards, no passthru |
| 12:59 | mooglemoogle | but stereo files play |
| 12:59 | mooglemoogle | not sure about scratchy |
| 13:00 | mooglemoogle | sounds like the gain is up way too high |
| 13:00 | mooglemoogle | I can record the audio using a mic tonight (on the older build) |
| 13:00 | mooglemoogle | so you can hear what I mean |
| 13:01 | Punkley_Chillin | i sent you a pm |
| 13:01 | mooglemoogle | I wish I had realised about the IRC over the weekend! |
| 13:01 | Punkley_Chillin | :) |
| 13:01 | mooglemoogle | You guys are really helpful and friendly :-) |
| 13:01 | Punkley_Chillin | you bastard..... |
| 13:01 | Punkley_Chillin | im not helping you at all :P |
| 13:01 | Punkley_Chillin | that better |
| 13:01 | mooglemoogle | LOL |
| 13:02 | mooglemoogle | thx for the PM |
| 13:02 | mooglemoogle | will try tonight! |
| 13:02 | dotarray | good luck mooglemoogle! |
| 13:03 | mooglemoogle | Cheers! |
| 13:04 | Punkley_Chillin | u might need to change you xbmc sound card output also. |
| 13:12 | rmk_ | moogle: well, it was quiet here all Sunday |
| 13:31 | dotarray | which post, ralix? |
| 13:32 | ralix | Total disappointment - WHY?!? |
| 13:32 | dotarray | it's an old thread :( |
| 13:33 | Coolgeek | before the amazing dotarray came here |
| 13:33 | ralix | hehe |
| 13:33 | dotarray | ahah! |
| 13:33 | dotarra | 13:33 * dotarray blushes |
| 13:35 | Coolgeek | they were disappointed only because there were no news from solid run |
| 13:35 | Coolgeek | now, it's not the same |
| 13:36 | dotarray | we try :) |
| 13:37 | dotarra | 13:37 * dotarray is in the middle of a new Meet the Team blog post :) |
| 13:40 | rmk_ | dotarray: should I get the management bingo card and start crossing off phrases like "meet the team" :) |
| 13:41 | dotarray | there's only six of us, it'd be a tiny card :) |
| 13:41 | Coolgeek | who is the winner ? |
| 13:41 | Punkley_Chillin | i broke my linux install |
| 13:41 | Punkley_Chillin | boooo |
| 13:41 | Punkley_Chillin | who needs booting anyway |
| 13:42 | Punkley_Chillin | 37/100 degrees tomorrow perfect time for a re-install |
| 14:08 | moogmoogle | Has anyone got geexbox working using SPDIF for 5.1 and 5.1 DTS audio? |
| 14:08 | moogmoogle | If so, pls could you post the build you used? |
| 14:09 | moogmoogle | Will save me some time if I can at least narrow down to a single distro and build number |
| 14:09 | moogmoogle | (with getting xbmc working properly) |
| 14:10 | rabeeh | moogmoogle: i'm back |
| 14:10 | rabeeh | spdif 5.1 or whatever version worked fine on older driver which is not mainlined |
| 14:10 | moogmoogle | OK |
| 14:10 | rabeeh | once we moved to the mainlined (called kirkwood i2s) we broke the pass through support |
| 14:10 | moogmoogle | Is there a previous version I can go back to? |
| 14:11 | moogmoogle | While this is resolved |
| 14:11 | rabeeh | (but we gained highly accurate clock source that is -+30 ppm max distrotion for hi fidelity) |
| 14:12 | rabeeh | there is the really old one which is ubuntu based but it's not really stable. |
| 14:13 | rabeeh | i'm looking for it. |
| 14:15 | rabeeh | http://www.solid-run.com/mw/index.php/XBMC_April-9_Installer |
| 14:15 | dotarray | someone didn't like that response, hm. |
| 14:16 | Kiranos | rabeeh: you know of a known issue of audio going out of sync when you fast forward 720p mkv with geekbox, audio is over hdmi |
| 14:17 | rabeeh | Kiranos: nop. if you can click the 'o' button and you will get A/V time - what are the numbers? |
| 14:17 | Kiranos | I'm at work now, I can check when I get home later |
| 14:17 | rabeeh | Kiranos: Geexbox? |
| 14:17 | rabeeh | or other? |
| 14:17 | Kiranos | yes |
| 14:17 | Kiranos | latest snapshot |
| 14:17 | Kiranos | drag the bar to half the movie and start play |
| 14:18 | Kiranos | latest geekbox |
| 14:22 | moogmoogle | Sorry PC issues - back now |
| 14:26 | moogmoogle | switched to mIRC |
| 14:26 | moogmoogle | web client was being a bit flakey |
| 14:27 | moogmoogle | rabeeh - did you get my earlier question? |
| 14:27 | moogmoogle | is there an earlier version of geexbox I can go back to which does not have the SPDIF problem? |
| 14:38 | Kiranos | [14:12:00] there is the really old one which is ubuntu based but it's not really stable. |
| 14:38 | Kiranos | [14:13:04] i'm looking for it. |
| 14:38 | Kiranos | [14:15:03] http://www.solid-run.com/mw/index.php/XBMC_April-9_Installer |
| 14:38 | rabeeh | yes. |
| 14:38 | rabeeh | really old one |
| 14:39 | moogmoogle | OK - so I should not use geexbox? |
| 14:40 | moogmoogle | (meanwhile) |
| 14:40 | Punkley_Chillin | man just realised today is only Monday :( |
| 14:41 | rabeeh | moogmoogle: you can try it; SPDIF 5.1 worked for that version; but it's not really a stable one |
| 14:42 | moogmoogle | yes - I tried it over the weekend |
| 14:42 | moogmoogle | I will give it another go based on your recommendation |
| 14:46 | moogmoogle | Will it be possible to resolve the SPDIF problem going forwards? |
| 14:46 | moogmoogle | (for xbmc) |
| 14:46 | rabeeh | yes |
| 14:46 | rabeeh | that's one of the most important |
| 14:46 | moogmoogle | good news |
| 14:46 | rabeeh | today we've got bluray playback on CuBox |
| 14:47 | moogmoogle | great! |
| 14:47 | rabeeh | with that we should be able to get 5.1 and higher bitrates in passthrough |
| 14:50 | moogmoogle | excellent news - good luck rabeeh :) |
| 14:53 | moogmoogle | any guess on when there will be some shiny new binaries to try? |
| 15:11 | rabeeh | moogmoogle: i think no one has yet figured out what the issue is with passthrough |
| 15:12 | rabeeh | i'm working on it; and hopefully someone that is really good in audio is looking at it too |
| 15:18 | rmk_ | rabeeh: the vmeta uio driver, it has a couple of comments from you in there concerning the clock/power stuff - what's the story behind that change? |
| 15:30 | moogmoogle | Forgive my ignorance but is there an issue tracking database for any of this stuff? |
| 15:30 | moogmoogle | e.g. trac, redmine, jira etc.? |
| 15:30 | Kiranos | I dont think there is a public one |
| 15:31 | Kiranos | would be good and also maybe mailinglist |
| 15:31 | moogmoogle | public but readonly would have a huge help |
| 15:31 | moogmoogle | tbh might even be better to have a wholly public interface to it |
| 15:32 | moogmoogle | so people can post their test results with different builds etc. |
| 15:33 | moogmoogle | would be helpful to see what bugs are being worked upon and by whom and what the progress is |
| 15:33 | moogmoogle | also what bugs exist |
| 15:34 | moogmoogle | and also mean we can report stuff which is not working in nightly builds |
| 15:34 | moogmoogle | i'd be glad to help set this stuff up if there is interest... |
| 16:15 | rmk_ | hmm. |
| 16:16 | rmk_ | just looking back at my audio dma underrun bug... |
| 16:16 | rmk_ | looks like vlc isn't decoding the ac3 audio fast enough |
| 16:16 | rmk_ | alsa keeps going into xrun |
| 16:17 | rmk | 16:17 * rmk_ wonders if this is another problem with stuff not liking being built for T2 (as with libmad) |
| 16:18 | jnettlet | rmk_, I found the ac3 decoding performance to be pretty poor on our platform. |
| 16:21 | jnettlet | I assume you are using liba52 |
| 16:22 | dv_ | rabeeh: are you aware of the "illegal instruction" problem? |
| 16:23 | rmk_ | jnettlet: looks like it does, yes. |
| 16:23 | rmk_ | dv: what illegal instruction problem? |
| 16:24 | rmk_ | there's been a bug in the T2 vfp instruction exception handling which Rabeeh merged a patch into his kernel which is different from the patch I merged into mainline... and if both are used together it will cause the problem to re-appear |
| 16:24 | dv_ | rmk_: run glxgears |
| 16:24 | dv_ | it exits with "Illegal instruction" |
| 16:24 | dv_ | the same happens with all gstreamer plugins except vmetadec |
| 16:25 | dv_ | N30N also had this problem |
| 16:25 | rmk_ | can you get a core dump, and then run gdb on it? |
| 16:26 | jnettlet | glxgears is trying to use Mesa's software rasterizer...if it is a newer version it will try to run LLVM code that causes an Illegal Instruction |
| 16:26 | dv_ | and the plugins |
| 16:26 | jnettlet | OpenGL != EGL/GLESv2 |
| 16:26 | dv_ | ? |
| 16:27 | jnettlet | dv_, without knowing the versions and environment can't tell you. |
| 16:27 | dv_ | the ones from the marvell package. I'll look for the arch AUR version |
| 16:27 | jnettlet | mix matching softfp/hardfp libraries can cause illegal instructions |
| 16:30 | dv_ | agh, where the hell is marvell-ipp |
| 16:32 | dv_ | ah yes. here: http://www.solid-run.com/mw/index.php/Downloads |
| 16:32 | dv_ | the plugins are inside the big package |
| 16:33 | jnettlet | dv_, I will look again, but I am quite sure those are all softfp libraries |
| 16:34 | dv_ | hmm. i though softfp is fully compatible with hardfp |
| 16:34 | dv_ | that could explain things |
| 16:34 | jnettlet | dv_, let me double check that is a different big package than was there before |
| 16:35 | dv_ | when I get home I'll generate sha hashes out of the plugin binaries |
| 16:37 | jnettlet | dv_, just check the libraries with readelf -A /path/to/library.so |
| 16:37 | jnettlet | if you see Tag_ABI_HardFP_use: SP and DP then they are good |
| 16:38 | dv_ | ok |
| 16:42 | rmk_ | jnettlet: do you know of any solution (yet) for the liba52 problem? |
| 16:45 | rmk_ | what I don't understand is, if liba52 isn't able to decode fast enough, why isn't it eating all avilable CPU time |
| 16:48 | jnettlet | rmk_, you aren't seeing high CPU usage? I didn't see 100% cpu but ac3 decoding was taking 70% when a similar bitrate file with mp3 audio was taking 30% cpu to decode |
| 16:48 | rmk_ | top says 25% idle |
| 16:48 | rmk_ | 6275 cubox 20 0 160m 55m 37m S 48.0 7.7 7:09.81 vlc |
| 16:49 | rmk_ | 48% CPU being used by vlc |
| 16:49 | rmk_ | just about to start stracing individual vlc threads to find out which is doing the audio |
| 16:49 | jnettlet | is that 1080p or 720p? |
| 16:50 | rmk_ | 720p |
| 16:50 | jnettlet | then your stats are pretty close to what I saw |
| 16:51 | rmk_ | right, 14890 is doing the video, 14893 is doing the audio |
| 16:52 | rmk_ | 14893 cubox 20 0 160m 55m 37m S 0.9 7.7 0:04.25 vlc |
| 16:52 | rmk_ | don't think its even trying |
| 16:59 | jnettlet | what if you pause the video and then play it. Do you see the cpu usage go up, and then back down? |
| 17:00 | rmk_ | now you ask just after I quit vlc :) |
| 17:00 | jnettlet | haha |
| 17:00 | jnettlet | always |
| 17:00 | rmk_ | your timing is perfect. |
| 17:01 | rmk_ | doesn't seem to |
| 17:02 | jnettlet | oh then it is just plain not trying. I don't know if VLC uses the audio or video to sync the output |
| 17:02 | rmk_ | I might dig into this one a little deeper at some point |
| 17:03 | rmk_ | in the mean time, now that I know that its underrunning in software, it gives some clues about what might be happening with the kirkwood audio stuff |
| 17:04 | jnettlet | rmk_, to fix the problem I was going to fix the new svn builds that have MMX support and extend that to support iWMMXt on our platforms |
| 17:59 | rmk_ | ok, I think I'm getting closer to nailing that lockup by kirkwood-dma.c |
| 18:00 | rmk_ | because liba52 can't provide the audio data fast enough, the playback is being stopped/restarted frequently... |
| 18:00 | rmk_ | an instance where this occurs, the following timing happens: |
| 18:00 | rmk_ | 61739.809516913 (+0us) - play stop |
| 18:01 | rmk_ | 61739.810064707 (+548us) - play start |
| 18:01 | rmk_ | 61739.810178773 (+662us) - underrun error occurs |
| 18:01 | rmk_ | now, the DMA prefetches 128 bytes at a time, so that's 32 16-bit samples prefetched. |
| 18:02 | rmk_ | at 48kHz, each sample is 20.8us... 32 samples = 667us. |
| 18:02 | rmk_ | 667us vs 662us... that can't be a coincidence. |
| 18:08 | rmk_ | oh dear. |
| 18:08 | rmk_ | "NOTE: After either I2S or SPDIF playback is disabled, this bit must be read |
| 18:08 | rmk_ | twice as "idle" before any "Audio Playback" register can be changed. |
| 18:08 | rmk_ | and... we don't do that. |
| 18:20 | rmk | 18:20 * rmk_ sets about fixing this driver |
| 18:21 | jnettlet | rmk_, good luck. We have deduced a lot of our audio driver problems have come down to hardware. I think we finally have the full round of work-a-rounds needed to get everything working |
| 18:21 | jnettlet | except stereo MIC recording...that seems to be a lost cause |
| 18:22 | rmk_ | jnettlet: well, doing the basics like following the documented restrictions would be a very good starting point, rather than just blatently ignoring them |
| 18:22 | rmk_ | all bets are off with the hardware if you ignore the hardware restrictions |
| 18:25 | jnettlet | rmk_, I am shocked that was noted in the docs |
| 18:25 | rmk_ | I'm getting soo unimpressed with much of this kernel code |
| 18:26 | rmk_ | maybe some of this wasn't documented when this code was written... shrug. |
| 18:28 | jnettlet | we have ported our driver to the snd-soc-dmaengine code. I assume the kirkwood driver needs the same overhaul. |
| 18:42 | rmk | 18:42 * rmk_ spots another bug in the driver |
| 18:58 | rmk | 18:58 * rmk_ sticks his modified driver on test.... |
| 19:00 | rmk_ | well, that's 2m30 of playback with no underrun error being triggered |
| 19:01 | rmk_ | also need to prove it with something that does playback correctly |
| 19:01 | rmk_ | but I shall leave this stuttering playback going for a while longer |
| 19:06 | rmk_ | now at 9 minutes, still no error message |
| 19:08 | jnettlet | sounds good. congrats. |
| 19:08 | rmk_ | hang on, don't congratulate me yet... only after I've proven it can still play back correctly :) |
| 19:10 | rmk_ | hmm |
| 19:10 | rmk_ | that's a negative. |
| 19:10 | jnettlet | did I jinx things? |
| 19:10 | rmk_ | I think you might have :) |
| 19:13 | jnettlet | damn...I do that to myself all the time |
| 19:19 | rmk_ | oops |
| 19:20 | rmk_ | the watchdog just barked |
| 19:22 | rmk_ | I think there may be a case where the busy bit doesn't clear |
| 19:24 | rmk_ | found my bug :) |
| 19:28 | jnettlet | is that why they had to check for idle twice? |
| 19:38 | rmk_ | playing properly now :) |
| 19:38 | rmk_ | and stopping and starting works :) |
| 19:40 | jnettlet | nice work |
| 19:40 | shesselba | rmk_: great you debug i2s! |
| 19:41 | shesselba | I once added extclk support but didn't touch the core driver itself at all |
| 19:41 | shesselba | maybe with DT support extclk support should also go into mainline linux? |
| 19:41 | rmk_ | I believe cubox uses extclk for the i2s stuff |
| 19:42 | shesselba | well, the extclk patch in rabeeh's tree is based on my patches IIRC |
| 19:42 | rmk_ | I don't see what DT has anything to do with whether this can go into mainline |
| 19:43 | shesselba | DT makes it _even more_ usable, especially on other kirkwood/dove boards |
| 19:44 | shesselba | I have a si5351 clk driver somewhere in my repos, that is used on Cubox to generate audio1_extclk |
| 19:44 | shesselba | but the current (mainline) kirkwood-i2s doesn't care about extclk |
| 19:45 | rmk_ | this patch is against v3.6, and reflects what I'm running right this instant: |
| 19:45 | rmk_ | http://www.home.arm.linux.org.uk/~rmk/misc/kirkwood.diff |
| 19:46 | rmk_ | its got my debugging in for this too, so its not "production" |
| 19:47 | rmk_ | one of the changes I have in my tree is... |
| 19:47 | rmk_ | ASoC: kirkwood-i2s: fix extclk handling |
| 19:47 | rmk_ | If we don't want to use extclk, we have to set it to an invalid value, |
| 19:47 | rmk_ | not NULL. |
| 19:49 | rmk_ | but that's a relatively small patch |
| 19:50 | rmk_ | its still playing back :) |
| 19:51 | shesselba | I see, great that you debug the code! hope you ll prepare that for mainline integration.. dove patches for mainline are still rare |
| 19:52 | rmk_ | we'll see :) |
| 19:53 | rmk_ | http://www.home.arm.linux.org.uk/~rmk/misc/cubox-0.jpg (sorry for it being a jpeg) |
| 19:54 | shesselba | is it playing on dco clk or extclk? have you tried other frequencies than the dco supported ones? |
| 19:54 | rmk_ | extclk |
| 19:55 | rmk_ | actually no, it'll be using dco for this |
| 19:55 | rmk_ | kirkwood-i2s kirkwood-i2s.1: kirkwood_set_rate: dco set rate = 44100 |
| 19:55 | rmk_ | since rhythmbox plays through pulseaudio which insists on everything being one sample rate |
| 19:55 | shesselba | yeah, when I added extclk, I guessed that tuning dco to one of the supported frequencies will be faster that poking si5351 over i2c |
| 19:56 | rmk_ | yea, it will be |
| 19:57 | shesselba | but I talked with rabeeh back then, and he wanted to test frequencies not supported by dco.. but I guess we all got stuck in some other stuff ;) |
| 19:58 | rmk_ | well, this evening I'll see about committing some of this stuff to my cubox git tree, and then preparing some patches for mainline, and seeing whether the asoc/alsa people will take them |
| 19:59 | shesselba | regarding the jpeg, it's running on your video driver, isn't it? :) |
| 19:59 | rmk_ | yep |
| 19:59 | rmk_ | I can wiggle that window around the screen and it keeps up :) |
| 19:59 | shesselba | great one too! |
| 20:00 | shesselba | any other driver projects for dove pending? |
| 20:00 | rmk_ | but you might start asking question about the background image |
| 20:01 | shesselba | what's that on you bg image? |
| 20:01 | rmk_ | it's related to the music which rhythmbox is playing |
| 20:02 | rmk_ | an older grab from when I was working on the X stuff: http://www.home.arm.linux.org.uk/~rmk/x/scr.0.png |
| 20:02 | rmk_ | less obscured :) |
| 20:02 | shesselba | avatar |
| 20:02 | shesselba | ? |
| 20:02 | rmk_ | yup |
| 20:03 | shesselba | well, guessed that after googling for "james horner" ;) |
| 20:03 | rmk_ | the full text reads: Tse'a ngal ke'ut a krr fra'uti kame. Which means: You see nothing when you See everything. |
| 20:03 | rmk_ | err. |
| 20:03 | rmk_ | the full text reads: Tse'a ngal ke'ut a krr fra'uti kame. Which means: You See everything when you see nothing. :) |
| 20:04 | rmk_ | bbiab. |
| 20:04 | Kiranos | I have a video sample here I dont understand why my geekbox cant play without stutter and pixelation, anyone here who would like to have a look at the sample? |
| 20:05 | rabeeh | Kiranos: please send me a link |
| 20:07 | shesselba | rmk_: about spdif and the 2 channel restriction.. compressed audio is encapsulated and squeezed in spdif pcm frames |
| 20:08 | shesselba | so 2ch restriction is only for pcm |
| 20:23 | rabeeh | shesselba: how then 5.1 flac would work? |
| 20:24 | shesselba | decode to 2ch pcm or have a receiver that understands flac and use pass through |
| 20:25 | shesselba | (I doubt you ll find one ;)) |
| 20:25 | rabeeh | hehe. semi joke :) |
| 20:26 | rabeeh | big buck bunny has 5.1 flac audio tracks |
| 20:26 | rabeeh | is that for something like AC97 multi channel codec? |
| 20:26 | shesselba | no |
| 20:27 | shesselba | ac97 and i2s (and spdif also) are interface protocols between soc and audio codec |
| 20:28 | rabeeh | ok. so a multi channel i2s? |
| 20:28 | rmk_ | i2s can only be 2 channel |
| 20:28 | shesselba | yes and no.. |
| 20:29 | shesselba | there is multi-channel i2s or over-clocked i2s and you can also overclock spdif .. but there is no receiver that will accept flac |
| 20:29 | rabeeh | there is an NXP transmitter that supports 4xi2s busses |
| 20:30 | rabeeh | each i2s is 2 channels; so total 8 channels |
| 20:30 | rabeeh | but as you said, can HDMI do encapsulation of raw 8 channels? |
| 20:30 | shesselba | sure, but there is no AID for flac |
| 20:30 | shesselba | i.e. there is no _standard_ way of transmitting (passthough) flac |
| 20:31 | jnettlet | shesselba, I believe Denon makes a line of receivers that can decode flac |
| 20:31 | shesselba | ok, then there must be an AID for flac.. |
| 20:32 | shesselba | I ll check CIA/EIA 861 spec, there are all HDMI supported AIDs are listed.. and HDMI is basically what spdif allows to transmit also |
| 20:32 | RandomPixels | hello |
| 20:34 | rabeeh | hi RandomPixels |
| 20:34 | RandomPixels | did anyone used successfully some developer tools with the cubox on a mac? |
| 20:34 | RandomPixels | i have trouble into creating new SD cards (XBMC installations for example) |
| 20:35 | rmk_ | shesselba: do you know anything about these boxes: http://www.dinodirect.com/audio-rush-converter-dts-optical-fiber-hd.html?cur=GBP&vn=RGlub2RpcmVjdEZ1Y2s&cur=GBP&ref=AFFID-138&siteID=febwRJxqGzU-8JtH4IV81Q7aDH9dE40FAg (sorry for the link) |
| 20:36 | rmk_ | shesselba: will they take non-pcm streams? |
| 20:37 | rmk_ | its suggested that they support "many kinds of audio format" but that's soooooo vague |
| 20:37 | rmk_ | if they can, then I could look at rabeeh's passthrough problem, because I have one of 'em. |
| 20:38 | shesselba | rmk_: hard to tell from the link but usually they should at least support ac 5.1 |
| 20:38 | shesselba | but I cannot tell for sure |
| 20:39 | rmk_ | do you know of any simple way of testing this kind of stuff with ALSA? |
| 20:39 | shesselba | best option for pass through testing is always hdmi, as the tv will tell what formats are supported |
| 20:40 | shesselba | I ll have to look in my emails with rabeeh from month ago but I used alsa to test spdif with ac3 |
| 20:41 | shesselba | rmk_: http://www.nlucky.com/products/Playvision-HD51R-DTS-Optical-Fiber-HD-Audio-Rush-Converter-p58879.html |
| 20:41 | shesselba | I am not a audio logo guy, but IIRC dts logo is only allowed if you support dts compressed audio |
| 20:43 | rmk_ | yea, but then again it is chinese stuff :) |
| 20:43 | rmk_ | and they scrubbed the chip numbers off |
| 20:43 | shesselba | but it should support ac3, why have spdif input and 5.1 analog output if you only support 2.0 ? |
| 20:44 | rmk | 20:44 * rmk_ wonders... can vlc do ac3 output |
| 20:44 | shesselba | yes |
| 20:44 | shesselba | but don't ask me how ;) |
| 20:44 | rmk_ | looking in the options :) |
| 20:45 | shesselba | look for pass-through |
| 20:46 | shesselba | for everybody interested in audio format encoding in HDMI: http://blogimg.chinaunix.net/blog/upfile2/090903185624.pdf (copyright-protected!) |
| 20:46 | shesselba | pp49 |
| 20:46 | rmk_ | it has "Use S/PDIF when available" enabled... |
| 20:46 | shesselba | that can be anything |
| 20:48 | shesselba | as cea861e matches HDMI 1.4, there is no FLAC Audio Coding Type |
| 20:50 | shesselba | but I checked for FLAC and Denon as jnettlet suggested, and can guess that it doesn't support FLAC over spdif passthrough but usb or ethernet, i.e. as audio file |
| 20:51 | shesselba | rabeeh: what is exactly what you are trying to achieve? play a multichannel FLAC on Cubox and send it "as-is" to a receiver that uncompresses it? |
| 20:51 | shesselba | or play a multi-channel FLAC on Cubox, decompress it and send 5.1 pcm? |
| 20:51 | rmk_ | need to find out how vlc decides whether it can stream ac3 to alsa |
| 20:53 | shesselba | rmk_: with vlc, pulse and alsa, you ll have to check every party involved to allow passthough |
| 20:53 | rmk_ | oh, pulse ain't part of my vlc setup :) |
| 20:53 | rmk_ | vlc talks direct to alsa |
| 20:54 | shesselba | ok, then it is only two remaining ;) you have an alsa.conf for spdif passthough? |
| 20:54 | rmk_ | otherwise pulse decides to down-convert 48k to 44.1k slowly |
| 20:55 | rmk_ | I have whatever's in ubuntu 12.10 |
| 20:56 | shesselba | I ll never understand why alsa requires a config file to tell the software that there is iec958 pass through available, but last time I looked into alsa and iec958 there was |
| 20:57 | shesselba | I found the email from march this year with Kirkwood_S_PDIF.conf, maybe I ll find another one with how to use aplay and passthrough |
| 20:58 | rabeeh | shesselba: all those questions are for knowledge; what i really care about now is getting passthrough working back again on the kirkwood audio driver (with ext clock) |
| 20:58 | rmk_ | rabeeh: but knowledge is key to working out what's wrong |
| 20:59 | rabeeh | s/knowledge/general knowledge :) |
| 20:59 | shesselba | +#if 0 |
| 20:59 | shesselba | + reg = readl(priv->io+KIRKWOOD_SPDIF_PLAYCTL); |
| 20:59 | shesselba | + ucontrol->value.iec958.status[0] &= |
| 20:59 | shesselba | + ~(IEC958_AES0_PROFESSIONAL | IEC958_AES0_NONAUDIO); |
| 20:59 | shesselba | + if (reg & KIRKWOOD_SPDIF_NON_PCM) |
| 20:59 | shesselba | + ucontrol->value.iec958.status[0] |= IEC958_AES0_NONAUDIO; |
| 20:59 | shesselba | +#endif |
| 21:00 | rmk_ | yea, that may not help but without vlc seemingly even trying to send ac3 out |
| 21:02 | shesselba | that is from the patch you posted above, I don't recall every detail of the driver but IEC958 (aka passthrough) is never set because of the #if 0.. |
| 21:03 | shesselba | no, wrong. |
| 21:03 | rmk_ | yea; my point is that if userspace does end up sending ac3 data into alsa, I should get noise out instead, because it'll just put the ac3 stream direct to the dacs |
| 21:03 | shesselba | yes |
| 21:04 | rmk_ | but it's not even trying yet, and I'm not sure why. I'll run vlc in debugging mode (which is always fun) |
| 21:04 | shesselba | (if your spdif-to-analog converter respects the non-pcm bit inside spdif frames) |
| 21:05 | shesselba | the Kirkwood_S_PDIF.conf I talked about announces iec958 to software using alsa |
| 21:08 | shesselba | rmk_: what does aplay -l print? |
| 21:08 | rmk_ | just the one device: |
| 21:08 | rmk_ | card 0: SPDIF [Kirkwood SPDIF], device 0: IEC958 Playback dit-hifi-0 [] |
| 21:09 | rmk_ | Subdevices: 1/1 |
| 21:09 | rmk_ | Subdevice #0: subdevice #0 |
| 21:09 | rmk_ | aplay -L also doesn't list any iec958 stuff |
| 21:09 | shesselba | is there a /usr/share/alsa/cards/Kirkwood_SPDIF.conf (or Kirkwood_S_PDIF.conf)? |
| 21:10 | rmk_ | not here |
| 21:11 | rmk_ | and google isn't turning the file up either |
| 21:11 | shesselba | I can send you one, but first let me check on my cubox |
| 21:14 | shesselba | I only have 3.7-rc6 without kirkwood-i2s, but I recall that that alsa.conf was required to get pass through working.. |
| 21:14 | shesselba | you can get it here https://dl.dropbox.com/u/59928252/Kirkwood_S_PDIF.conf |
| 21:22 | dv_ | jnettlet: I just checked. it is "SP and DP". yet I see "illegal instruction" |
| 21:25 | dv_ | jnettlet: http://pastie.org/5402929 |
| 22:01 | jnettlet | dv_, interesting. You are running a standard Cubox kernel and config |
| 22:01 | dv_ | hm? |
| 22:02 | dv_ | kernel 3.5.7 |
| 22:02 | jnettlet | did you compile it yourself? |
| 22:02 | dv_ | no. Linux-3.5.7-3-ARCH+ |
| 22:03 | jnettlet | could you post the output of dmesg for me to peruse? |
| 22:06 | dv_ | http://pastie.org/5403129 |
| 22:06 | dv_ | after a fresh boot |
| 22:10 | jnettlet | that is missing the info at the top I am looking for. Specifically can you tell if iWMMXt is loaded? |
| 22:17 | dv_ | ok, next try |
| 22:18 | rmk_ | well. |
| 22:18 | dv_ | hmm no dmesg always starts with the same |
| 22:18 | dv_ | *line |
| 22:18 | dv_ | ah, perhaps I can edit something in the uboot line |
| 22:19 | rmk_ | vlc using ac3 passthrough :) |
| 22:19 | rmk_ | no driver mods required |
| 22:20 | jnettlet | rmk_, yeah it is an option in the configs |
| 22:20 | jnettlet | it defaults to on |
| 22:20 | rmk_ | you just need the right alsa configuration |
| 22:22 | nlon | lo |
| 22:22 | dv_ | setenv bootargs 'console=ttyS0,115200n8 vmalloc=384M root=/dev/mmcblk0p1 video=dovefb:lcd0:1920x1080-32@60-edid clcd.lcd0_enable=1 clcd.lcd1_enable=0' this is inside boot.scr |
| 22:22 | dv_ | hmm no "quiet" arg |
| 22:23 | nlon | i'm looking to utilize the cubox for a nas solution. connecting to a Mediasonic ProBox drive enclosure |
| 22:23 | nlon | is this a good solution |
| 22:23 | nlon | cheap :) |
| 22:24 | nlon | the advantage of using the cubox is that it can act as a full pc if needed |
| 22:24 | nlon | dunoo |
| 22:24 | dv_ | yeah |
| 22:28 | dv_ | jnettlet: it seems the config for the kernel can be found here: https://github.com/archlinuxarm/PKGBUILDs/blob/master/core/linux-cubox/config |
| 22:28 | dv_ | also see http://archlinuxarm.org/developers/building-kernels |
| 22:29 | jnettlet | dv_, and there in lies your problem. CONFIG_CPU_PJ4 and so IWMMXT are not enabled. You are getting illegal instructions because those gstreamer modules are optimized for iwmmxt |
| 22:29 | dv_ | ah |
| 22:30 | jnettlet | your kernel doesn't support those instructions, so they are in fact illegal :-) |
| 22:30 | dv_ | so I should build the kernel myself and enable these |
| 22:30 | jnettlet | dv_, really you should get ARCH to fix their configs |
| 22:30 | jnettlet | but compiling your own kernel, or using the default Cubox kernel should also fix your problem |
| 22:33 | Punkley_Chillin | nlon how many disks? |
| 22:40 | nlon | Pukley_Chillin: 4 |
| 22:43 | dv_ | jnettlet: raised a github issue, lets see what happens |
| 23:17 | Punkley_Chillin | argh he left. |