00:35 | rabeeh | ajayr: ping |
00:35 | rabeeh | dung: ping |
00:39 | rabeeh | shesselba: ping |
00:40 | shesselba | rabeeh: pong |
00:43 | rabeeh | shesselba: we are seeing some audio delays on XBMC gui and seen some post on the forums about delays (0.7 seconds) in ubuntu 12.04 |
00:43 | rabeeh | my guess would be driver issue; but i have been trying to figure it out but nothing |
00:43 | rabeeh | any idea? |
00:44 | rabeeh | maybe that's the time difference until the si5351 clock stabilizes? |
00:44 | shesselba | sorry, audio is way out my current focus.. you could try to disable external clock on kirkwood-i2s |
00:45 | shesselba | and check again with internal clock |
00:45 | rabeeh | ok |
00:45 | shesselba | but this delay is constant, i.e. it is an a/v offset? |
00:45 | shesselba | or just initially? |
00:45 | rabeeh | well... in xbmc there is a constant delay in the GUI |
00:45 | rabeeh | but in playback it goes well. |
00:46 | rabeeh | so i agree it's not clock generator related |
00:46 | rabeeh | (if that's your claim) |
00:47 | shesselba | hmm, external clock is set on play, i.e. start of stream, as long as you don't restart the stream the clock gen is up and running |
00:47 | shesselba | if the a/v offset is constant over time, i doubt it's a driver/clockgen related issue |
00:48 | shesselba | but I don't know and none of my cuboxes is in a state I could easily test |
00:53 | rabeeh | shesselba: there is a feedback on the status of consumed buffer that an alsa polls on. |
00:53 | rabeeh | it might be related to that. |
00:55 | shesselba | rabeeh: can you please point me to the thread where the audio issue is reported |
01:06 | rabee | 01:06 * rabeeh still looking |
01:17 | rabeeh | shesselba: http://www.solid-run.com/phpbb/viewtopic.php?f=6&t=685 |
01:18 | rabeeh | look at 0.7s |
01:19 | shesselba | ok, but what is this latency related to, e.g. what is the time base? |
01:22 | shesselba | in general latency is introduced by software (here jackd?), alsa buffering, i2s dma, spdif encoding inside i2s... |
01:22 | shesselba | can you reproduce this measurement of .7s? |
01:27 | shesselba | I checked kirkwood-i2s.c in your repo, it doesn't even use external clock but internal dco if rate is 44k1, 48k or 96k |
01:27 | rabeeh | there is some sense with this 0.7s |
01:28 | shesselba | I don't doubt the latency itself but just want to know how it is measured |
01:29 | rabeeh | https://github.com/rabeeh/linux/blob/master/sound/soc/kirkwood/kirkwood-i2s.c#L227 |
01:30 | rabeeh | right. |
01:30 | rabeeh | so, it's unrelated. |
01:30 | rabeeh | (btw - i have a patch i kept for my self to always use external clock) |
01:30 | rabeeh | i tend to rely more on the external clock source rather than the dco inside the chip |
01:31 | shesselba | hehe, maybe you know why ;) have you ever tried to play with uncommon audio rates? |
01:31 | rabeeh | http://pastebin.com/R6hqbYDD |
01:31 | rabeeh | nop |
01:31 | rabeeh | like what? |
01:32 | shesselba | don't know.. cbxbiker61 was requesting support for HBR spdif IIRC? |
01:33 | rabeeh | HBR === TrueHD? |
01:33 | shesselba | yeah, had kind of the same patch back the days I was implementing external clk ;) |
01:33 | shesselba | yep |
01:33 | rabeeh | but i's impossible. |
01:33 | rabeeh | the laser from SPDIF is up to 15Mbps |
01:33 | rabeeh | i recall we had this calculation and reached to the conclusion that the bitrate on the laser would be higher |
01:34 | rabeeh | and the receiver that cbxbiker61 has is an Onkyo one that gets HDMI-in |
01:34 | rabeeh | (for the TrueHD part) |
01:37 | shesselba | Just to make it clear: You measured the spdif led and found out that it is not capable of TrueHD bitrate? (I can recall the bitrate on TrueHD right now) |
01:37 | rabeeh | nop. it was a discussion between both of us. |
01:38 | rabeeh | i recall we got max bitrate (192khz 32b x 7.1 channels) |
01:39 | rabeeh | Max. bitrate for TrueHD in BD is 18.64 Mbps (24.5 Mbps DTS-HD, 27.748 Mbps LPCM) |
01:39 | rabeeh | http://forum.doom9.org/archive/index.php/t-156667.html |
01:43 | shesselba | phew.. I tried to sum up all the stuff I used to know about HDMI/IEC61937 (60937?) ... but that would be very unprecise because I just can't remember the correct numbers :( |
01:44 | rabeeh | 00:45 in Germany? |
01:44 | shesselba | 1:45 |
01:44 | rabeeh | :) |
01:44 | rabeeh | oh |
01:44 | rabeeh | that explains it |
01:44 | shesselba | http://www.epanorama.net/documents/audio/spdif.html |
01:45 | shesselba | this gives a good overview about channel encoding on spdif |
01:45 | shesselba | I used that back these days to implement an spdif encoder in hardware |
01:45 | shesselba | actually silicon-proven ;) |
01:46 | rabeeh | :) |
01:46 | rabeeh | are you familiar with cox spdif? |
01:46 | rabeeh | are you familiar with coax spdif? |
01:46 | shesselba | nope |
01:46 | shesselba | I used an TOTX for my experiments |
01:46 | rabeeh | most of the hi end audio systems uses coax (and not optical) |
01:47 | rabeeh | i was wondering how mpd / coax would behave on such systems |
01:47 | shesselba | well, from the "sound quality" point-of-view it is _the same_ ;) |
01:48 | rabeeh | well. hi end audio fanatics would disagree |
01:49 | shesselba | because they never try to get one important thing |
01:49 | rabeeh | even if it's digital; the slope of the signal might introduce some jitter that causes audio distrotions |
01:49 | shesselba | sure |
01:49 | shesselba | ;) |
01:49 | rabeeh | hehe |
01:49 | shesselba | that the human ear is capable of hearing.. |
01:50 | shesselba | at 3 MHz... |
01:50 | rabeeh | well. i have a friend that would swear that once he changed his AC cables with golden ones he stopped hearing some noise from the speakers |
01:50 | shesselba | yep, he also buys golden hdmi cables doen't he? |
01:50 | rabeeh | hehe. |
01:50 | rabeeh | he doesn't use hdmi |
01:50 | rabeeh | :) |
01:51 | rabeeh | stereo flac |
01:51 | rabeeh | no video at all |
01:51 | shesselba | because the image looks sharp since he spent hundreds of eur/$/... |
01:51 | shesselba | hehe |
01:51 | shesselba | I accept that there are some things that can be heard/seen .. but some are just imagination ;) |
01:51 | rabeeh | i have other friend that worked in a company that did video post processing for digital TVs |
01:52 | rabeeh | he can't watch any movie today since he would always look for the decoding artifacts and completely forget about the movie |
01:53 | shesselba | yeah, I know that ;) |
01:53 | shesselba | I remember the days when DVB-T was introduced in Germany and everybody I know of told me that the image is the best ever seen.. |
01:54 | shesselba | (IMHO it is the _worst_ image you can ever get) |
01:55 | shesselba | Not even blind people can oversee the quantization artifacts.. |
01:58 | shesselba | especially on soccer games where the codecs always predict the playground being "kind of" similar to the last block of green.. and missing that the most important stuff isn't the playground but ball and players.. |
01:59 | shesselba | anyway: back to TrueHD, somehow 6.144 Mbps is in my mind.. |
02:00 | shesselba | as being a max bitrate of something.. |
02:01 | shesselba | ahh.. hdmi spec 1.3a, section 5.3.11 |
02:02 | shesselba | HBR (>6 |
02:02 | rabeeh | 54Mbps? |
02:02 | shesselba | (>6.144Mbps) compressed audio streams |
02:02 | shesselba | conforming to IEC 61937 are carried using HBR Audio Stream Packets |
02:02 | rabeeh | so that can be transferred over optical s/pdif |
02:03 | shesselba | IIRC "normal" audio packets are meant to replace SPDIF on HDMI |
02:03 | shesselba | therefore SPDIF is <= 6.144Mbps |
02:04 | shesselba | I once knew how to calculate that.. |
02:05 | shesselba | ok |
02:05 | shesselba | 192 frames x 32b = 6.144 Mbps |
02:07 | shesselba | an spdif block is made up of 2ch of 32b of 192 frames.. |
02:08 | shesselba | but for non-LPCM only 16b per subframe are usable.. |
02:08 | shesselba | 192 frames x 2 ch x 16 b = 6.144 Mbps to be precise |
02:11 | rabeeh | ok. |
02:12 | rabeeh | if you say. |
02:12 | rabeeh | for now i see dark in my left eye; and the right one is closing |
02:12 | rabeeh | going to sleep. ttyl |
02:12 | shesselba | k |
02:12 | shesselba | me too |
02:12 | rabeeh | i need to extend the 24hrs a day for more |
02:12 | rabeeh | and get more 10 fingers |
02:13 | rabeeh | good night :) |
02:16 | shesselba | hehe |
08:52 | cbxbiker61 | i think i may have to get a ti am335x starter kit, it has two gig-e nics and an lcd display, should make a very nice low-power firewall machine |
08:53 | cbxbiker61 | ram is only 256M, but that's fine for a firewall, $199 |
09:36 | Thirsty | They can better buy a TP-Link WR1043ND, it has 5x1Gb managed switch in it and WLAN 11n. |
09:38 | Thirsty | I have two WR1043ND, I upgrade one with openwrt. Now you can do everything with it. |
17:28 | av_jui | ping rabeeh |
18:11 | rabeeh_ | av_jui: pong |
18:12 | av_jui | hi if have start metest abaout 8 hours and it run and run and run |
18:14 | rabeeh_ | ok. so memory is good |
18:15 | rabeeh_ | what's connected to CuBox? |
18:15 | rabeeh_ | and what does running 'temp' on u-boot show? |
18:15 | av_jui | at the moment hdmi microsd usb and microusb |
18:16 | av_jui | should i stop mtest? |
18:16 | rabeeh_ | yes |
18:16 | rabeeh_ | ctrl-c |
18:16 | rabeeh_ | (and wait for 1m) |
18:16 | av_jui | Temprature (Tj): 60 |
18:16 | rabeeh_ | ok. so it's cool |
18:16 | av_jui | ok I wait 1 min |
18:17 | av_jui | Temprature (Tj): 60 the same |
18:18 | rabeeh_ | can u take out the hdmi and try booting? |
18:18 | rabeeh_ | then take out the micro-sd |
18:18 | av_jui | then take out the micro-sd -> when it boots or after |
18:20 | rabeeh_ | try removing items one by one |
18:20 | av_jui | first boot without hdmi but with sdcard http://pastebin.com/RnnRaURK |
18:22 | av_jui | the same without microsd http://pastebin.com/rhLKfvFW |
18:24 | rabeeh_ | av_jui: you said on the threads that it previously worked for you? |
18:24 | rabeeh_ | any idea what changed from then? |
18:24 | rabeeh_ | are you using the same power supply? |
18:24 | rabeeh_ | same micro-USB cable with PC? |
18:25 | av_jui | all is the same and at beginning of the problems sometimes it works but yet it never work |
18:26 | av_jui | this problem beginns with the geexbox built within cec at this point the cubox freez very often after start and than the box beginn to make trouble with starting and yet the box never starting :-( |
18:30 | av_jui | hi gimli nice to see you here |
18:30 | gimli | :) |
18:32 | av_jui | @rabeeh do you have an other idea or is my worst case be real and the hardware is defect |
18:33 | av_jui | @ gimli is there any work on progress with your marvel-dovce port? |
18:33 | av_jui | marvel-dove |
18:37 | gimli | av_jui: not from my side. was realy lazy on the dove port |
18:38 | av_jui | @rabeeh do you have an other idea or is my worst case be real and the hardware is defect |
18:39 | rabeeh | 18:39 * rabeeh_ thinking |
18:40 | av_jui | @gimli is the cubox not good enouth for you :-) |
18:41 | rabeeh | 18:41 * rabeeh_ is starting at gimli |
18:41 | rabeeh | 18:41 * rabeeh_ is staring at gimli |
18:42 | giml | 18:42 * gimli hides |
18:44 | rabeeh_ | av_jui: gimli started the first native vmeta on XBMC |
18:45 | av_jui | I know and my question was that gimli make progress on this port |
21:36 | av_jui | ping rabeeh |
22:39 | av_jui | ping rabeeh |
23:48 | av_jui | ping rabeeh |
23:52 | rabeeh | av_jui: pong |
23:53 | av_jui | so do you have an other idea? |
23:54 | av_jui | I beginning to frustraid |
23:54 | av_jui | but first I wannt to say thanks and good support from you |
23:55 | rabeeh | :) |
23:55 | rabeeh | let's figure it out first |