00:13 | shesselba | rmk_: did the alsa config help or did you find your own way? |
00:14 | rmk_ | yes thanks - it helped to model my own - partly because the card name is slightly different. |
00:14 | rmk_ | its called 'Kirkwood_SPDIF' rather than 'Kirkwood_S_PDIF' |
00:17 | shesselba | yeah, that is a better name |
08:04 | ralix | morning |
08:06 | dotarray | hello ralix! |
08:07 | dotarray | any news on where your cubox is, today? |
08:10 | ralix | Hello dotarray! Oh yes! Yesterday I had a note in my mailbox that my package can not be delivered. So just called, it was to land here at the office until 12:00 clock. I hope so. There were many developments lately. I finally want to play around again. |
08:12 | ralix | I'm about to start to load the installer and grab a usb stick prepared inlet. I will lose no time;-) |
08:14 | ralix | The latest version is dated (Cubox 0_1.zip-installer-20-Sep-2012 09:06) That this right? |
08:50 | rabeeh | jnettlet: still have the Xorg 13 patch for dovefb around? i'm looking for it and can't find it |
08:50 | jnettlet | rabeeh, yeah just uploaded it for someone yesterday. |
08:51 | jnettlet | http://dev.laptop.org/~jnettlet/0001-dovefb-port-to-compat-api-for-new-server.patch |
08:51 | rabeeh | great - thanks |
08:51 | jnettlet | I am fixing some rendering bugs I have found in the 1.13 compositing code right now. |
08:54 | rabeeh | iwmmxt related? |
08:55 | jnettlet | rabeeh, nope they changed a couple of the fallback pathways so now the drivers need to be smarter about how they do compositing |
08:57 | jnettlet | and something is very slow with the 1.13 Xorg server. |
08:58 | jnettlet | I am hoping it has to do with these composite paths...less copying to and from "video ram" |
09:10 | rabeeh | rmk_: have asound.conf? |
10:30 | rmk_ | rabeeh: yes. http://www.home.arm.linux.org.uk/~rmk/misc/Kirkwood_SPDIF.conf |
11:36 | ralix | Finally my Cubox is there :) |
11:57 | jnettlet | excellent. Now don't break it this time :-) |
11:57 | N30N | lol |
11:58 | moogmoogle | Have diagnosed my issue with XBMC |
11:59 | moogmoogle | As per rabeeh's suggestion, installed XBMC April-9 Installer since does not have SPDIF issue |
11:59 | moogmoogle | Audio "distortion" issue I am experiencing only seems to happen with 24 bit FLAC files |
11:59 | moogmoogle | Anyone else experienced this? |
12:00 | ralix | ;-) |
12:00 | moogmoogle | Unfortunately 24 bit FLAC is my main reason for wanting the Cubox (doh!) |
12:00 | moogmoogle | But happy to see it finally playing 1080P MKV properly :-) |
12:01 | moogmoogle | with 5.1 sound |
12:03 | moogmoogle | 1080P playback is better than my PS3! |
12:03 | moogmoogle | Astonishingly good |
12:17 | rabeeh | great moogmoogle |
12:17 | rabeeh | in what means better than your PS3? |
12:17 | rabeeh | notice the GeexBox now has overclocking feature for vmeta |
12:21 | rmk_ | unless I'm mistaken, ac3 passthrough still only uses two channels? |
12:22 | rmk_ | so why are the kirkwood sound drivers patched to 8 channels max? |
12:24 | rmk_ | hmm, ok, it needs that for the iec stream... |
12:24 | rmk_ | but... what's done there will allow up to 8 PCM channels too |
12:24 | rmk_ | which you definitely don't want. |
12:43 | rmk_ | right, I now have a patch series of 10 patches for the audio stuff which fixes the bugs I found, some that you've found, lifts the restrictions on sample rates/formats on the DMA driver, and adds the external clock support |
12:44 | rmk_ | what I haven't moved across is the spdif stuff |
12:47 | rabeeh | rmk_ do you have an audio receiver that can receive passthrough? |
12:47 | rabeeh | i mean multi channel passthrough (and not stereo) |
12:49 | rmk_ | the hd audio rush box appears to... but I'm unconvinced of vlc's ability to do so effectively |
12:49 | rmk_ | there's bugs raised against vlc 2.0 about this which I seem to be hitting |
12:50 | rmk_ | so I'm still in search of a real effective way to test that |
13:27 | rmk_ | rabeeh: if you want your sign-off to appear on those patches I've split out from your git tree, or provide the authorship information for them, I'll update those patches with that info. |
13:27 | rmk_ | your tree didn't have the sign-offs so I can't add them without you explicitly saying so |
13:28 | rmk_ | (and remember... sign-offs are about the patch delivery path) |
13:28 | rmk_ | it'd also be a good idea to get sign-offs from the original patch author too |
13:35 | rabeeh | rmk_ shesselba is the man behind those patches |
13:39 | rabeeh | that's why originally i didn't add the signed-off |
13:56 | rmk_ | ok, hopefully shesselba will see the emails and comments here |
13:58 | rmk_ | there's something else I want to try with that driver, and that's moving the clock enablement deeper into the driver, so that we can shut off the clocks when they're not actually needed |
13:58 | rmk_ | maybe by moving it over to runtime pm |
13:59 | rmk_ | but lets first get mainline closer to what you guys have :) |
14:13 | rmk | 14:13 * rmk_ is wondering... how does SNDRV_PCM_FMTBIT_IEC958_SUBFRAME_LE get selected through alsa... vlc seems to to configure alsalib with one of the IEC formats. |
14:14 | rmk | 14:14 * rmk_ curses alsa people for creating their voodoo library ;) |
14:38 | ptl | hi... |
14:38 | ptl | anyone got a cubox kernel for 12.10 with device mapper? |
14:38 | ptl | I need to use LVM... :-/ |
19:23 | shesselba | rmk_: I ve already seen your patches, I am fine with you being sign-off .. I ll test the patches ASAP - hopefully tonight |
19:27 | shesselba | and about the "audio channel counting" of spdif: it is capable of transferring 2ch pcm (up to 20b IIRC) _or_ anything else that will fit into this frame structure |
19:27 | shesselba | i.e. for compressed audio passthrough there is _no_ channel at all |
19:27 | shesselba | channels come back as soon as it is decompressed |
19:29 | shesselba | so finally, spdif is _not_ capable of transferring multi-channel audio except you send you compressed audio file _as is_ plus some header bits to the receiver |
19:30 | shesselba | moogmoogle will be also interested in this explanation |
19:31 | shesselba | if you play 24b flac on cubox, it is most likely decompressed and stuffed into 16b 2ch pcm |
19:32 | shesselba | (it is not limited to cubox of course but spdif itself) |
19:39 | rmk_ | interesting, I wonder why vlc still tries to set N channels when using spdif... maybe I haven't dug deep enough |
19:40 | rmk_ | what I'm wondering is whether that change from 2->8 is really necessary... at the moment my understanding from the vlc code is that it is |
19:40 | rmk_ | it seems to me that if it's providing a compressed 5.1 stream, it tries to set alsa for 6 channels |
19:50 | rmk_ | in any case, as far as sign-offs, having _your_ sign-off and authorship on them too would be better |
19:53 | shesselba | I am fine with adding my sign-off |
19:55 | shesselba | I didn't get the whole alsa concept at all but every library on top of alsa has to implement pass-through conversion, i.e. add a stream header and pad to spdif frames |
19:55 | shesselba | And I don't know why it is telling the hw driver the channels _inside_ the compressed stream.. |
19:56 | shesselba | IMHO alsa is broken and I remember rabeeh thinking the same ;) |
19:56 | rmk_ | sign-off to patches 1 (virt_to_phys), 3 (dco lock flag), 8 (lifting restriction on sample rates), 9 (external clock) and 10 (lifting channel restrictions)? |
19:57 | shesselba | ack |
19:57 | rmk_ | just making sure I'm adding it to the right ones :) |
19:58 | rmk_ | thanks |
19:59 | shesselba | about vlc setting 6ch on spdif: maybe vlc wants to decompress and play it as pcm |
20:00 | shesselba | then 6ch would be correct, but spdif cannot handle this |
20:01 | shesselba | what about with pass-though enabled, is it still announcing 6ch audio to the driver? |
20:02 | rmk_ | I haven't tried a 6-channel stream yet |
20:02 | rmk_ | and I'm unconvinced that vlc did work with passthrough lastnight now - my vlc seems to suffer from this: http://forum.videolan.org/viewtopic.php?f=13&t=100608&p=342854&hilit=buffer+way+too+early#p342854 |
20:03 | rmk_ | I think it worked once but I couldn't get it to do it again |
20:03 | rmk_ | it just ended up constantly going into xrun while vlc kept complaining the audio buffers were arriving too early |
20:04 | rmk_ | vlc people who apparantly can't test this just claim alsa is broken, that's hard to see if the buffers aren't making their way to alsa in the first place |
20:05 | rmk_ | so I don't know, it's just yet another thing to be debugged |
20:06 | shesselba | annoying! I see through my records tonight when reviewing kirkwood-i2s.. I did get ac3 passthough working. but as I am more used to mplayer I used this |
20:06 | shesselba | but mplayer is limited to ac3 and dts passthrough |
20:07 | shesselba | you have to select hwac3/hwdts as codec (-ac?) |
20:07 | rmk_ | I could have read something wrong, but what I know is there's no IEC958 format selection in the vlc alsa driver |
20:08 | shesselba | hmm, isn't it based on ffmpeg? |
20:08 | rmk_ | yup, ffmpeg does the backend decoding, but then there's a set of modules which do more stuff including the output |
20:09 | rmk_ | in this case, vlc-2.0.3/modules/audio_output/alsa.c |
20:09 | rmk_ | and if its using spdif, it sets the format to... SND_PCM_FORMAT_S16 |
20:10 | shesselba | Yeah, but actually with audio interfaces being misused for years, that _could_ also lead to passthrough ;) |
20:11 | rmk_ | I did spend a while trying to see if I could find in the gitweb alsa-lib anything that configured the hardware for IEC958 but haven't found anything (yet) |
20:11 | shesselba | there are only 16b per channel used for passthrough and the receiver _can_ ignore the non-pcm bit |
20:35 | jnettlet | rmk_, do you want to control the hardware, or are you trying to figure out how the hardware is controlled? |
20:36 | rmk_ | I was trying to work out whether what vlc seemed to be doing is correct or not |
20:38 | rmk_ | at some point I'll throw in some of my own debugging into vlc and see what's going on,. and see whether I can fix this problem that folk on the vlc forum are complaining about in 2.0 with passthrough |
20:41 | jnettlet | rmk_, just reading the backlog quick. As best as I can remember from my days working on embedded home theater systems, there shouldn't be format selection from the spdif output...unless you want vlc to re-encode the stream. |
20:42 | jnettlet | you have two options, audio mode which is just PCM, or non-audio which is used to send AC3 or DTS |
20:42 | jnettlet | so if VLC is setting the format to SND_PCM_FORMAT_S16 then it is using the audio mode and doing the decoding in software |
20:47 | rmk_ | I'm... unconvinced, because it does all the normal pcm format stuff for all the various sizes and signed-nesses, and then does: |
20:47 | rmk_ | default: |
20:47 | rmk_ | if (AOUT_FMT_SPDIF(&aout->format)) |
20:47 | rmk_ | spdif = var_InheritBool (aout, "spdif"); |
20:47 | rmk_ | if (spdif) |
20:47 | rmk_ | { |
20:47 | rmk_ | fourcc = VLC_CODEC_SPDIFL; |
20:47 | rmk_ | pcm_format = SND_PCM_FORMAT_S16; |
20:47 | rmk_ | } |
20:47 | rmk_ | ... |
20:47 | rmk_ | val = snd_pcm_hw_params_set_format (pcm, hw, pcm_format); |
20:48 | rmk_ | and advertises to the other modules... |
20:48 | rmk_ | aout->format.i_bytes_per_frame = AOUT_SPDIF_SIZE; |
20:48 | rmk_ | aout->format.i_frame_length = A52_FRAME_NB; |
20:48 | rmk_ | in that case |
20:49 | rmk_ | its possible, of course, this could be why it doesn't work too well |
20:49 | rmk_ | until I get the chance to dig into it more, I won't know, but I suspect there's something rather wrong with vlc as others are reporting the same issue on x86 |
20:51 | rmk_ | I've already hacked YUYV format support into vlc, so this copy of the source won't take long to build for debugging :) |
20:52 | rmk_ | (it used to want YUV420 out of the hw video decode) |
20:52 | rmk_ | whereas vmeta gives us one of the YUYV formats |
21:05 | shesselba | as I told before, passthrough uses 16b 2ch pcm on spdif frame, i.e. it is possible to make any i2s driver send passthrough without even knowing about it |
21:07 | shesselba | and if the receiver ignores the non-pcm bit in spdif header, it still can guess from the data stream that it is not pcm |
21:07 | rmk_ | yes, ok, I'm not disagreeing, but my point is that _something_ is wrong with vlc because it doesn't work. |
21:07 | rmk_ | and what's more other people are reporting that vlc fails to work in passthrough mode on other hardware |
21:08 | rmk_ | if it's throwing ac3 data away before even giving it to alsa, then you can't ever expect to get coherent audio out of it |
21:08 | rmk_ | doesn't really matter what format it's in... |
21:08 | shesselba | true |
23:11 | shesselba | rmk_: first comment about your patch set: sound/soc/kirkwood/Kconfig should also allow ARCH_DOVE for SND_KIRKWOOD_SOC |
23:11 | shesselba | and currently in mainline linux there is no dove_i2s0/1_init in arch/arm/mach-dove/common.c |
23:12 | rmk_ | it's not a full patch set for dove |
23:12 | rmk_ | not for the cubox; it's meant to move things in that direction |
23:13 | shesselba | I know |
23:15 | shesselba | I don't know about all the kirkwood boards but most of them neither have i2s or spdif routed on their boards.. kirkwood was mainly used for routers and nas |
23:15 | shesselba | maybe that's why it has been never tested in depth |
23:18 | rmk_ | that's the suggestion I heard too; basically anything non-nas isn't well tested |
23:18 | shesselba | is your kirkwood-spdif.c the one from rabeeh's repo? any changes on your side? |
23:19 | shesselba | hehe, "well tested" but built virtually in every successor soc ;) |
23:19 | shesselba | "isn't well tested" of course |
23:22 | rmk_ | there are some changes there... why do you ask? |
23:23 | shesselba | I need it for testing |
23:23 | rmk_ | nothing in there should affect that - but what you will be missing is the spdif code in kirkwood-i2s in that patch set (as I said earlier) |
23:24 | rmk_ | the changes I have in kirkwood-spdif are to shut up the printks, get move the spdif-dit platform device creation to arch/arm/mach-dove, and fix the card->name not to have '/' in it |
23:24 | rmk_ | because / is an illegal sysfs character |
23:26 | shesselba | and replace plat/audio.h with the correct platform_data include ;) |
23:27 | rmk_ | which version are you trying it against? |
23:27 | shesselba | 3.7-rc6 |
23:28 | rmk_ | http://www.home.arm.linux.org.uk/~rmk/misc/kw-i2s-remainder.diff is what's remaining for kirkwood.h/kirkwood-i2s.c |
23:29 | rmk_ | http://www.home.arm.linux.org.uk/~rmk/misc/kw-cubox-remainder.diff is the kirkwood-spdif.c, Kconfig and makefiles |
23:30 | rmk_ | and... |
23:30 | rmk_ | this last one's going to be the not-so-easy to sort... |
23:31 | rmk_ | what would you like a patch against for arch/arm/mach-dove/cubox-setup.c ? |
23:31 | shesselba | yes, I ll sort things out myself |
23:32 | rmk_ | well, it's only a few lines you need there... |
23:32 | rmk_ | +static const struct platform_device_info cubox_spdif_dit __initconst = { |
23:32 | rmk_ | + .name = "spdif-dit", |
23:32 | rmk_ | + .id = -1, |
23:32 | rmk_ | +}; |
23:32 | shesselba | ok, got that already from rabeeh's tree |
23:32 | rmk_ | and in cubox_init: |
23:32 | rmk_ | + platform_device_register_full(&cubox_spdif_dit); |
23:33 | rmk_ | that move is needed to stop things exploding when this stuff is built as modules |
23:33 | shesselba | but I ll have to add auxdata for clock or have a quick DT node patch |
23:33 | rmk_ | yea, probably. |
23:34 | rmk_ | what I'm running on the cubox is rabeeh's + v3.6 + my stuff |
23:35 | shesselba | hmm, latest clk patches for dove will remove legacy dove_clock_init and rely on DT only |
23:35 | shesselba | that's what I am working on currently.. I ll need a DT node first |
23:36 | rmk_ | You may shudder at knowing that I have 191 commits so far |
23:36 | shesselba | I hope all are bug fix patches and will be mainlined soon ;) |
23:36 | rmk_ | lots on galcore, lots on the vmeta uio stuff (the uio people object to vmeta being a uio driver) |
23:37 | rmk_ | a rework of some of the BMM stuff which saves a bit of memory for every bmm object allocated (pointless alignment in userspace) |
23:38 | shesselba | great! |
23:38 | rmk_ | I've not yet plucked up the courage to try again with the vmeta stuff after my last run-in with GregKH over the licensing of it |
23:41 | rmk_ | I did send Rabeeh a few patches which sort out the memory grabbing for vmeta/bmm/gpu stuff but I don't think he ever merged them |
23:42 | shesselba | yeah, he is always busy solving some problems ;) |