Re: [LAD] Screencasting with JACK [SOLVED!]
On 09/26/2013 05:44 PM, J. Liles wrote: On Thu, Sep 26, 2013 at 8:16 AM, F. Medeiros excali...@gmail.com mailto:excali...@gmail.com wrote: Hello, I have the same problem, audio and video are not in sync and the data is not aligned Warning. This also happens when using Xephyr. This is what I get from ffmpeg: x@space:~/Documents/ffmpeg$ ./ffmpeg -fflags +genpts+igndts -f x11grab -vsync 0 -r 30 -s 1920x1080 -i :1.0+0,0 -vcodec h264 -f jack -ac 2 -r:a 48000 -i screencast -acodec pcm_s16le -r:v 30 -vsync 2 -async 1 -map 0:0,1,0 -map 1:0 -preset ultrafast -qp 0 test.mkv ffmpeg version N-56669-g1906e00 Copyright (c) 2000-2013 the FFmpeg developers built on Sep 26 2013 11:48:30 with gcc 4.6 (Ubuntu/Linaro 4.6.3-1ubuntu5) configuration: --enable-libvorbis --enable-gpl --enable-libx264 --enable-x11grab libavutil 52. 46.100 / 52. 46.100 libavcodec 55. 33.100 / 55. 33.100 libavformat55. 18.102 / 55. 18.102 libavdevice55. 3.100 / 55. 3.100 libavfilter 3. 87.100 / 3. 87.100 libswscale 2. 5.100 / 2. 5.100 libswresample 0. 17.103 / 0. 17.103 tel:17.103%20%2F%C2%A0%200.%2017.103 libpostproc52. 3.100 / 52. 3.100 [x11grab @ 0x917dfc0] device: :1.0+0,0 - display: :1.0 x: 0 y: 0 width: 1920 height: 1080 [x11grab @ 0x917dfc0] shared memory extension found Input #0, x11grab, from ':1.0+0,0': Duration: N/A, start: 1380208288.085940, bitrate: 1990656 kb/s Stream #0:0: Video: rawvideo (BGR[0] / 0x524742), bgr0, 1920x1080, 1990656 kb/s, 30 tbr, 1000k tbn, 30 tbc jack_port_get_latency_range called with an incorrect port 0 [jack @ 0x918e260] JACK client registered and activated (rate=48000Hz, buffer_size=256 frames) Guessed Channel Layout for Input Stream #1.0 : stereo Input #1, jack, from 'screencast': Duration: N/A, start: 1380144319.409428, bitrate: 3072 kb/s Stream #1:0: Audio: pcm_f32le, 48000 Hz, stereo, flt, 3072 kb/s [swscaler @ 0x9171fc0] deprecated pixel format used, make sure you did set range correctly No pixel format specified, yuv444p for H.264 encoding chosen. Use -pix_fmt yuv420p for compatibility with outdated media players. -async is forwarded to lavfi similarly to -af aresample=async=1:min_hard_comp=0.10:first_pts=0. [libx264 @ 0x95e97c0] using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.2 [libx264 @ 0x95e97c0] profile High 4:4:4 Predictive, level 4.0, 4:4:4 8-bit [libx264 @ 0x95e97c0] 64 - core 120 r2151 a3f4407 - H.264/MPEG-4 AVC codec - Copyleft 2003-2011 - http://www.videolan.org/x264.html - options: cabac=0 ref=1 deblock=0:0:0 analyse=0:0 me=dia subme=0 psy=0 mixed_ref=0 me_range=16 chroma_me=1 trellis=0 8x8dct=0 cqm=0 deadzone=21,11 fast_pskip=0 chroma_qp_offset=0 threads=6 sliced_threads=0 nr=0 decimate=1 interlaced=0 bluray_compat=0 constrained_intra=0 bframes=0 weightp=0 keyint=250 keyint_min=25 scenecut=0 intra_refresh=0 rc=cqp mbtree=0 qp=0 Output #0, matroska, to 'test.mkv': Metadata: encoder : Lavf55.18.102 Stream #0:0: Video: h264 (libx264) (H264 / 0x34363248), yuv444p, 1920x1080, q=-1--1, 1k tbn, 30 tbc Stream #0:1: Audio: pcm_s16le ([1][0][0][0] / 0x0001), 48000 Hz, stereo, s16, 1536 kb/s Stream mapping: Stream #0:0 - #0:0 (rawvideo - libx264) Stream #1:0 - #0:1 (pcm_f32le - pcm_s16le) Press [q] to stop, [?] for help [swscaler @ 0x9171fc0] Warning: data is not aligned! This can lead to a speedloss frame= 76 fps= 30 q=-1.0 Lsize=1218kB time=00:00:02.53 bitrate=3939.6kbits/s video:745kB audio:469kB subtitle:0 global headers:0kB muxing overhead 0.358030% [libx264 @ 0x95e97c0] frame I:1 Avg QP: 0.00 size: 7840 [libx264 @ 0x95e97c0] frame P:75Avg QP: 0.00 size: 10057 [libx264 @ 0x95e97c0] mb I I16..4: 100.0% 0.0% 0.0% [libx264 @ 0x95e97c0] mb P I16..4: 98.5% 0.0% 0.0% P16..4: 0.0% 0.0% 0.0% 0.0% 0.0%skip: 1.5% [libx264 @ 0x95e97c0] coded y,u,v intra: 0.0% 0.0% 0.0% inter: 0.0% 0.0% 0.0% [libx264 @ 0x95e97c0] i16 v,h,dc,p: 100% 0% 0% 0% [libx264 @ 0x95e97c0] kb/s:2406.68 x@space:~/Documents/ffmpeg$ On 08/12/2013 03:18 AM, J. Liles wrote: On Sun, Aug 11, 2013 at 6:18 AM, Diego Simak diego.si...@gmail.com mailto:diego.si...@gmail.com wrote: 2013/8/8 J. Liles malnour...@gmail.com mailto:malnour...@gmail.com As some of you may recall, every time I've posted a demo video to LAD, I've had to include a disclaimer excusing the poor quality due to a lack of functional screencasting tools. Well, it took a couple of weeks of hair pulling and many, many hours of testing, but I finally arrived at a solution.
[LAD] JACK + PA Latency
Hi, Moving this to the LAD list as it seems to be getting to a more technical and challenging stage now. This may be a simple answer and if so that is great but suspect it is a bit more complex than that so might require the brain power of the LAD list rather than just my capabilities. To recap I am trying to get hard data on the best case latency while running a combination of JACK + PA. There are various reasons for and against doing this but discussing them is not the purpose of this thread. - I am using jack_delay to measure the round trip latency between jack - PA - JACK - I also have been testing a complete loop including system i/o but for the purposes of this thread we can ignore those results. - I have seen some interesting numbers come up today. If I run the following command: pactl list sink-inputs I get numbers similar to this: Buffer Latency: 8000 usec Sink Latency: 3166 usec The combination of the two shows the actual PA Stream Buffer latency (approx 10 - 11ms). This number stays approximately static while polling with this command. To be clear there is also the additional latency that occurs as the data is transferred from PA to the output but I am told it is negligible although it might turn out to be a key player. The results from jack_delay are somewhat different. I have included a snapshot below*. For reference sake it was also suggested that I open /dev/cpu_dma_latency and give it a value of 0. /dev/cpu_dma_latency allows to write the latency you can tolerate (in ms). The kernel will translate this to the deepest C-state the processor can enter. I have been running my tests with this value at zero in case it helps. I have checked with powertop and turbostat but it doesn't appear to make any difference on this machine. Possibly because it is an older cpu. Armed with that preliminary information there are a couple of issues that I am interested in at this juncture. 1: Why PA is reporting 10ms for the stream buffer but jack_delay is giving the results below. 2: Why PA is reporting 10ms for the stream buffer when I am running jack at 64 frames/period and ecasound too. 3: Where the fluctuating measurements from jack_delay are coming from in the graph as PA Stream Buffer is static at 10ms and ecasound is basically in pass through with a 64/48k buffer same as JACK. A back of the envelop estimation suggests latency should be stable well under 20ms including the 10ms set aside for the PA Stream buffer. - RESULTS - jack_delay - pa - ecasound - pa - jack_delay hda_intel driver dual core Intel(R) Core(TM)2 CPU T5600 @ 1.83GHz jack is run at 64/48000/2 ecasound has a period size of 64 PA is configured to run at 48khz too [*] Here's the snapshot from jack_delay: 62784.000 frames 1308.000 ms total roundtrip latency extra loopback latency: 62784 frames use 31392 for the backend arguments -I and -O 62784.000 frames 1308.000 ms total roundtrip latency extra loopback latency: 62784 frames use 31392 for the backend arguments -I and -O ?? Inv 63168.000 frames 1316.000 ms total roundtrip latency extra loopback latency: 63168 frames use 31584 for the backend arguments -I and -O 63743.999 frames 1328.000 ms total roundtrip latency extra loopback latency: 63743 frames use 31871 for the backend arguments -I and -O 64639.999 frames 1346.667 ms total roundtrip latency extra loopback latency: 64639 frames use 32319 for the backend arguments -I and -O 64640.000 frames 1346.667 ms total roundtrip latency extra loopback latency: 64639 frames use 32319 for the backend arguments -I and -O 64639.999 frames 1346.667 ms total roundtrip latency extra loopback latency: 64639 frames use 32319 for the backend arguments -I and -O 64640.000 frames 1346.667 ms total roundtrip latency extra loopback latency: 64639 frames use 32319 for the backend arguments -I and -O 64640.000 frames 1346.667 ms total roundtrip latency extra loopback latency: 64639 frames use 32319 for the backend arguments -I and -O 64639.999 frames 1346.667 ms total roundtrip latency extra loopback latency: 64639 frames use 32319 for the backend arguments -I and -O 64640.000 frames 1346.667 ms total roundtrip latency extra loopback latency: 64639 frames use 32319 for the backend arguments -I and -O 64640.000 frames 1346.667 ms total roundtrip latency extra loopback latency: 64639 frames use 32319 for the backend arguments -I and -O 64640.000 frames 1346.667 ms total roundtrip latency extra loopback latency: 64639 frames use 32319 for the backend arguments -I and -O 65088.000 frames 1356.000 ms total roundtrip latency extra loopback latency: 65088 frames use 32544 for the backend arguments -I and -O 65088.000 frames 1356.000 ms total
Re: [LAD] JACK + PA Latency
On Sat, Sep 28, 2013 at 12:42:26AM +1000, Patrick Shirkey wrote: 1: Why PA is reporting 10ms for the stream buffer but jack_delay is giving the results below. 2: Why PA is reporting 10ms for the stream buffer when I am running jack at 64 frames/period and ecasound too. 3: Where the fluctuating measurements from jack_delay are coming from in the graph as PA Stream Buffer is static at 10ms and ecasound is basically in pass through with a 64/48k buffer same as JACK. A back of the envelop estimation suggests latency should be stable well under 20ms including the 10ms set aside for the PA Stream buffer. (1) and (2) you should really ask to the PA author(s). Regarding (3): * The results you included can't be consecutive outputs of jack_iodelay at least not as I wrote it. So what is the real timing of them ? * How is ecasound taling to PA ? Some native PA interface ? ALSA ? Any ALSA 'plugs' in the chain ? * Going from 65216 to 64 is just an overflow modulo 2^16 (which the maximum that jack_(io)delay can measure. Apart from that, the delay seems to be continuously increasing, but since you edited the result it's not possible to say how fast. Either PA is adding more and more buffering as time goes on, or it is resampling and doing a very bad job at it. Hint: use jack_delay (on my website), it will output less clutter (one line per value), and is also more resistant to abnormal circumstances. Ciao, -- FA A world of exhaustive, reliable metadata would be an utopia. It's also a pipe-dream, founded on self-delusion, nerd hubris and hysterically inflated market opportunities. (Cory Doctorow) ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] JACK + PA Latency
On Sat, September 28, 2013 1:29 am, Fons Adriaensen wrote: On Sat, Sep 28, 2013 at 12:42:26AM +1000, Patrick Shirkey wrote: 1: Why PA is reporting 10ms for the stream buffer but jack_delay is giving the results below. 2: Why PA is reporting 10ms for the stream buffer when I am running jack at 64 frames/period and ecasound too. 3: Where the fluctuating measurements from jack_delay are coming from in the graph as PA Stream Buffer is static at 10ms and ecasound is basically in pass through with a 64/48k buffer same as JACK. A back of the envelop estimation suggests latency should be stable well under 20ms including the 10ms set aside for the PA Stream buffer. (1) and (2) you should really ask to the PA author(s). Regarding (3): * The results you included can't be consecutive outputs of jack_iodelay at least not as I wrote it. So what is the real timing of them ? Those results are sequentially copied with no editing. I was surprised to see it as I thought it would just keep climbing. I have included the full log here: http://boosthardware.com/pa-jack-latency-1.txt Absolutely no editing. * How is ecasound taling to PA ? Some native PA interface ? ALSA ? Any ALSA 'plugs' in the chain ? ecasound -f:32,2,48000 -b:64 -i alsa -o alsa It's possible that something is creeping in between ecasound and PA. Or maybe it is the way PA is handling the stream? * Going from 65216 to 64 is just an overflow modulo 2^16 (which the maximum that jack_(io)delay can measure. Apart from that, the delay seems to be continuously increasing, but since you edited the result it's not possible to say how fast. Either PA is adding more and more buffering as time goes on, or it is resampling and doing a very bad job at it. Hint: use jack_delay (on my website), it will output less clutter (one line per value), and is also more resistant to abnormal circumstances. I will try that next. -- Patrick Shirkey Boost Hardware Ltd ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] JACK + PA Latency
On Sat, September 28, 2013 2:47 am, Patrick Shirkey wrote: On Sat, September 28, 2013 1:29 am, Fons Adriaensen wrote: On Sat, Sep 28, 2013 at 12:42:26AM +1000, Patrick Shirkey wrote: 1: Why PA is reporting 10ms for the stream buffer but jack_delay is giving the results below. 2: Why PA is reporting 10ms for the stream buffer when I am running jack at 64 frames/period and ecasound too. 3: Where the fluctuating measurements from jack_delay are coming from in the graph as PA Stream Buffer is static at 10ms and ecasound is basically in pass through with a 64/48k buffer same as JACK. A back of the envelop estimation suggests latency should be stable well under 20ms including the 10ms set aside for the PA Stream buffer. (1) and (2) you should really ask to the PA author(s). Regarding (3): * The results you included can't be consecutive outputs of jack_iodelay at least not as I wrote it. So what is the real timing of them ? Those results are sequentially copied with no editing. I was surprised to see it as I thought it would just keep climbing. I have included the full log here: http://boosthardware.com/pa-jack-latency-1.txt Absolutely no editing. * How is ecasound taling to PA ? Some native PA interface ? ALSA ? Any ALSA 'plugs' in the chain ? ecasound -f:32,2,48000 -b:64 -i alsa -o alsa It's possible that something is creeping in between ecasound and PA. Or maybe it is the way PA is handling the stream? * Going from 65216 to 64 is just an overflow modulo 2^16 (which the maximum that jack_(io)delay can measure. Apart from that, the delay seems to be continuously increasing, but since you edited the result it's not possible to say how fast. Either PA is adding more and more buffering as time goes on, or it is resampling and doing a very bad job at it. Hint: use jack_delay (on my website), it will output less clutter (one line per value), and is also more resistant to abnormal circumstances. I will try that next. http://boosthardware.com/pa-jack-latency-2.txt The results are quite different so that's a good sign. However they are still changing on a regular basis so my quest to understand the cause of this behaviour to find out if it is a localised issue or a bug of some kind is not over yet. -- Patrick Shirkey Boost Hardware Ltd ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] JACK + PA Latency
On Sat, Sep 28, 2013 at 03:09:36AM +1000, Patrick Shirkey wrote: The results are quite different so that's a good sign. However they are still changing on a regular basis so my quest to understand the cause of this behaviour to find out if it is a localised issue or a bug of some kind is not over yet. I'd say you have two ways to find out: 1. Get the PA sources and rip them apart, 2. Get the PA authors and make them sing (or rip them apart as well). Ciao, -- FA A world of exhaustive, reliable metadata would be an utopia. It's also a pipe-dream, founded on self-delusion, nerd hubris and hysterically inflated market opportunities. (Cory Doctorow) ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] JACK + PA Latency
[satire] Fons wrote: Get the PA authors and [snip] rip them apart [snip] Patrick wrote: There are various reasons for and against doing this [snip] [/satire] SICR to set the quotes in a wrong context ;). I can't understand that e.g. Ubuntu Studio by default combines Jack and PA. Even if PA would be of high quality, I've got serious doubts about the purpose using a combination of sound servers. For me this is a strange kind of Linux audio development. But I understand, discussing it's purpose is not the purpose of this thread. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
