| 00:13 | dung | nice :) |
| 02:59 | dbsx | Hi folks, I have to give a CuBox demo (very brief). Any recommendations for software and sample video for the demo? |
| 03:15 | ptl | dbsx: ubuntu 10.04 with xbmc? |
| 08:08 | ralix | morning |
| 10:22 | ralix | I am looking for a pvr-backend, mythbackend or tvheadend? tvheadend can unfortunately no timeshift: Which uses a Cubox really as pvr? |
| 10:25 | cbxbiker61 | tvheadend works well for me, although i'm not running it on the cubox |
| 10:26 | ralix | Do you use timeshift? |
| 10:26 | cbxbiker61 | i've got two dual tuners handled by tvheadend, so you can see that recording 4 streams at a time could be quite bandwidth intensive |
| 10:27 | cbxbiker61 | recording and viewing later works good, although pausing a live stream is not implemented yet |
| 10:27 | ralix | Important to me that would be fast forward and back. |
| 10:27 | cbxbiker61 | fast forward and back is working well for me now |
| 10:28 | ralix | Too bad: ( |
| 10:28 | ralix | pausing pause is very important to me |
| 10:28 | cbxbiker61 | when i first started using tvheadend, fast forward and back didn't work well, but it's been working very well lately |
| 10:29 | cbxbiker61 | yeah, i think pausing live stream is quite high on their todo list, probably next version |
| 10:30 | ralix | Damn. I will then try mythbackend. Thank you for your inquiry. |
| 10:31 | ralix | I hope it runs smoothly on the Cubox |
| 10:40 | _rmk_ | shesselba: this is Mark Brown's response to your problem of devices for asoc: |
| 10:40 | _rmk_ | 06:18 < broonie> rmk: Just don't put it into the device tree and instantiet it from code. |
| 10:40 | _rmk_ | 06:20 < broonie> rmk: This affects essentially every platform, the trick is to not have a 1:1 mapping between DT devices and objects ASoC can see. |
| 10:43 | _rmk_ | I don't think Mark quite gets it with where we're trying to head in general with stuff like DT |
| 11:02 | N30N | ralix: I had tvheadend runing on my cubox, it used about 15% cpu to steam hd channels. |
| 11:04 | ralix | Super. Last time I had problems with HD channels. Very very stutters and somehow ne wrong resolution. |
| 11:04 | ralix | Do you use Archlinux? |
| 11:05 | ralix | Forget, you've got the build for xbmc in aur ;-) |
| 12:01 | ralix | What is the difference between the openssl and openssl-cryptodev. With openssl-cryptodev I get an error of yaourt. |
| 12:04 | N30N | ralix: see http://archlinuxarm.org/forum/viewtopic.php?f=30&t=2452 |
| 12:04 | ralix | ah ok, thx :) |
| 12:41 | ralix | N30N, Did you compile yourself from the aur (tvheadend)? |
| 12:47 | N30N | ralix: sure did. |
| 12:49 | ralix | Ok I thought so, I regret to make at home because "distcc server" is not on. |
| 14:29 | _rmk_ | shesselba: I think I'm going to convert sound/soc/kirkwood to a pure ALSA device; ASoC imposes this artificial split between DMA and non-DMA stuff which is absurd for hardware where the two are integrated together (like kirkwood) |
| 17:28 | shesselba | _rmk_: but isn't the plus of asoc to have "plugable" codecs, i.e. spdif-tx on cubox, alc5630 on d2plug, ...? |
| 17:39 | _rmk_ | shesselba: yes, but I'm not sure that its worth this amount of pain... |
| 17:39 | _rmk_ | what I'm hoping is that Mark will reply to that email, and then Linus will jump on him. |
| 17:40 | _rmk_ | and then Mark will have to fix ASoC to be sensible. |
| 17:40 | _rmk_ | I can't think of any other way to make Mark see sense. |
| 17:41 | shesselba | hehe, either way you always need a specific stub (asoc) or card (alsa) for each board you have.. I haven't looked into asoc details recently but IIRC that that was what I wondered about when I first touched kirkwood-i2s |
| 17:41 | jnettlet | ASoC is such the pain. We just went 10 rounds with it to get it from dealing with our codec and hardware in a semi sensible way. |
| 17:42 | _rmk_ | oh, asoc is pretty adamant that the dma part _will_ be an entirely separate driver from the rest of the interface. |
| 17:42 | _rmk_ | it was purposely designed like that to stop people writing all-in-one drivers because of the few platforms where the two are separate entities |
| 17:42 | jnettlet | most important thing to remember is don't go fiddling with registers outside the framework. If the cached state gets confused you are doomed |
| 17:44 | jnettlet | yep snd_dmaengine_pcm...hurrah |
| 17:45 | _rmk_ | yea, that's the real answer to the problem of dma-separate-from-interface hardware |
| 17:46 | _rmk_ | instead, we have a botched subsystem which enforces one model on everything, and it really doesn't work for DT |
| 17:46 | _rmk_ | I don't think asoc would need any stubs - you just need a way to specify the attached codec in DT - ASoC already provides the infrastructure to hook that up. |
| 17:47 | _rmk_ | ASoC does get some things right :) |
| 17:48 | jnettlet | _rmk_, we are specifying the codec in device-tree |
| 17:49 | jnettlet | We have setup codec-node, cpu-dai-node, and platform-node |
| 17:49 | _rmk_ | I have noticed; but it also pushes the enforced artificial split of DMA (aka platform) vs interface (aka CPU DAI) into DT as well, which is broken. |
| 17:50 | _rmk_ | you write DT for the hardware, not for the software implementation. |
| 17:52 | _rmk_ | but then... Mark doesn't get a lot of things in the kernel; he's been humiliated by GregKH over ASoCs struct device handing and refuses to fix it... (basically ASoC potentially frees in-use memory) |
| 17:52 | _rmk_ | I even sent him patches to fix it, he won't apply them though because "it might break" |
| 17:53 | jnettlet | ASoC just seems way to fragile |
| 17:53 | _rmk_ | and inflexible |
| 17:53 | jnettlet | but then the hardware it is trying to support is built every which way but the way they did it last time |
| 17:53 | _rmk_ | jnettlet: did you manage to understand the dapm stuff? |
| 17:54 | jnettlet | _rmk_, 80%...there are definitely still bits I am not sure why they work. |
| 17:54 | jnettlet | it is not my main focus so I only dabble when extra eyes are needed |
| 17:55 | _rmk_ | I looked at it from the uda1341 perspective... and gave up; codec implementations of that stuff are very hap-hazard |
| 17:56 | jnettlet | and from what I understand you are supposed to move machine specific implementations out into the init code, but that seems very redundant and confusing. |
| 17:57 | jnettlet | Our thing is we need to set mic-bias only when recording because we have a LED tied to it, vs most other users of the codecs just enable all the BIAS registers at once. |
| 17:58 | jnettlet | I am lucky enough(?) to own a second device that uses the rt5631 codec...my Transformer Prime. |
| 18:02 | _rmk_ | well, I have patches which move most of kirkwood-dma.c into kirkwood-i2s.c, and make it either use the 'platform' asoc hooks or the 'cpu-dai' asoc hooks |
| 18:02 | _rmk_ | I also have three patches which gets rid of that prdata thing |
| 18:03 | _rmk_ | sound/soc/kirkwood/kirkwood.h | 2 + |
| 18:03 | _rmk_ | 2 files changed, 24 insertions(+), 50 deletions(-) |
| 18:04 | jnettlet | nice...are you pushing those upstream, or waiting for the dust to settle? |
| 18:04 | _rmk_ | I think I'll wait and see what happens first :) |
| 18:04 | _rmk_ | I've not yet done anything but build-tested them so far either |
| 18:20 | _rmk_ | ah, of course, it's thanksgiving day in the US, so it might be a day or so before Linus replies |
| 18:21 | ptl | my second CuBox just arrived \o/ |
| 18:35 | _rmk_ | the 2GB version? |
| 20:00 | ptl | _rmk_: is there such a version??? |
| 20:10 | jnettlet | ptl, it is in the works. |
| 20:56 | ptl | jnettlet: is it on sale yet? |
| 21:04 | ptl | ok |
| 21:04 | ptl | now I want to buy it :( |
| 21:04 | ptl | please tell me how to do it |
| 21:30 | shesselba | _rmk_: feel free to send me patches for dma->i2s .. I ll add DT on top and can functionally test it |
| 22:11 | jnettlet | ptl, It is just in development |
| 23:16 | ptl | jnettlet: :( |
| 23:16 | ptl | want |
| 23:16 | ptl | want want want |
| 23:19 | _rmk_ | oi, you've already got two. |
| 23:19 | _rmk_ | leave some for the rest of us! |