Audio stuttering on 0.9.1

[moonlight-stream]

Audio stuttering on 0.9.1

[scoobyd00]

Ive still got the same problems as above.
Tested the latest release tonight and ive still got the same problem, major sound breaking up.
Video is fine but sound is awful, sound was fine on 0.8.
Im afraid 0.9.1 hasnt solved the issue, running on 256 model b pi, latest raspbian release and audio through hdmi

Streaming both audio and video are working fine streaming to my Android Galaxy tab 3, so im sure my network/pc is fine and it's something with the Raspberry PI version.

Hope this helps.

[cgutman]

Can you do "java -jar limelight-pi.jar [streaming parameters] &> log.txt" and upload log.txt somewhere for us?

[duncanmcbryde]

I'm away from the raspberry pi for the meantime, so I will create the log this evening. If I remember correctly though stdout looked as it should, establishing handshakes etc and then stating the video bandwidth every second or so while the audio was stuttering.

[scoobyd00]

Heres my log file from tonight. Quick play of Grid.

https://mega.co.nz/#!OpgBxZhY!Z40rhtgWpX5ckvV8wH_L0dTvBZNVVbyMISzAuLPfQTM

Hope this helps to track down the audio stuttering issues.

[duncanmcbryde]

Here's the log file from running the command java -XX:+UseConcMarkSweepGC -XX:+UseThreadPriorities -jar limelht-pi.jar 192.168.0.4 -720 -30fps &> log.txt. I also did sudo initctl stop xbmc and sudo modprobe snd_bcm2835 to stop XBMC and load the sound module. I just loaded up the main steam window since I did not have a controller attached. Not much useful info sadly. I'll give it an actual run with a game tomorrow.

https://gist.github.com/duncanmcbryde/45f03b4239cf53bd60fa

[cgutman]

Very strange. No messages at all indicating any packet loss on video or audio streams. Packets can be silently rejected if they appear to be behind the current sequence number, but that seems highly unlikely to be happening since Android and PC would be having the same problem. Do either of you have an Android device that you could try to see if you have the same symptoms?

[scoobyd00]

Ive tried streaming from my PC to my android samsung galaxy tab 3 and that works fine, no audio loss at all. all 100% working.

[duncanmcbryde]

Yeah, I actually had it installed but not tried it yet! I just gave it a spin, and after realising I was downloading music in the background the audio stream sounded fine. With the audio downloading in the background there was stuttering 50% of the time, but even then it sounded far less garbled compared with the raspberry pi.

[duncanmcbryde]

I should add that limelight-pi did refuse to run due to a large number of dropped packets. I tested the connection with iperf and found that the wifi was playing up (throughput was about 72.9 Kbits/sec) so that part of error detection works well. A router reboot later and I was able to replicate the audio problem without it throwing error messages (5.54 Mbits/sec).

[pillepalle123]

unfortunately, the same sound problem here...

[cybern0id]

I've been experimenting with the code today and it seems the problem lies with changes made in the past to the RTP_RECV_BUFFER setting in the "pi" branch of limelight-common.
In:

    libs/common/src/com/limelight/nvstream/av/audio/AudioStream.java.

If I revert the changes made in irtimmer's pi branch from:

    public static final int RTP_RECV_BUFFER = 12 * 100;

to make them the same as upstream limelight-common:

    public static final int RTP_RECV_BUFFER = 8 * 1024;

then I don't get the audio problems described.

[cybern0id]

........and I've just noticed that upstream now has

public static final int RTP_RECV_BUFFER = 64 * 1024;

rather than

public static final int RTP_RECV_BUFFER = 8 * 1024;

I've just compiled limelight-pi with RTP_RECV_BUFFER = 64 * 1024 and it seems to work even better with regards audio performance.

[H3llK33p3r]

I just reading this part and I don't understand your previous comment. So I don't need to test with :

ublic static final int RTP_RECV_BUFFER = 8 * 1024;

In my case, I also have stuttering issue with the actual trunk of limelight-pi. That's strange if people have problem and others not ...

Is it possible to know the configuration of your pi ? (overclocked or not, the size of the GPU, the command used to start limelight)... ?

[cybern0id]

@HellKeeper62, sorry for the confusion. I would test with:

public static final int RTP_RECV_BUFFER = 64 * 1024;

which is the same as upstream limelight-stream/limelight-common and it works best for me.

I'm running up to date Raspbian and my Pi is a first version model B which is set up as follows:

/boot/config.txt:

arm_freq=1000
core_freq=500
sdram_freq=600
over_voltage=6
gpu_mem=256

** Make sure GPU memory is set to 256!!! I've found 128MB is not enough and causes audio problems. **

/boot/cmdline.txt:

dwc_otg.lpm_enable=0 console=ttyAMA0,115200 console=tty1 root=/dev/mmcblk0p10 rootfstype=ext4 elevator=deadline rootwait

/opt/vc/bin/vcgencmd version:

Aug  6 2014 17:55:53
Copyright (c) 2012 Broadcom
version 3da89bd3cdef7980b684f48fe60944aff4502f50 (tainted) (release)

uname -a:

Linux raspberrypi 3.12.26+ #702 PREEMPT Wed Aug 6 17:43:49 BST 2014 armv6l GNU/Linux

I also do the following on my pi before running limelight-pi:

echo performance > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor

I run limelight-pi as follows:

java -XX:+UseConcMarkSweepGC -XX:+UseThreadPriorities -jar /home/pi/limelight-pi-test.jar 192.168.x.x

[cybern0id]

Someone can test my experimental release here if they want:
https://github.com/7hunderbug/limelight-pi/releases

[H3llK33p3r]

Sorry I don't have enough time to test your version but what is different from original limelight-pi ?

I just test the impact of the overclock and effectively this one greatly improves performance. I have no stuttering issue with an overclocked pi (only audio lag :/). I have borrow a pi to a friend exclusively to test limelight on it. I hesitate to buy a raspberry or may be a banana pi. Only with this trick it seems that a stock raspberry is a little bit too limited for the stream :/

[cybern0id]

The only difference is

public static final int RTP_RECV_BUFFER = 64 * 1024;

in

libs/common/src/com/limelight/nvstream/av/audio/AudioStream.java

This change is in the limelight-common submodule, which should be the "pi" branch of irtimmer's limelight-common repo. With this change and the overclock and gpu settings for the pi that I use and have detailed previously, I don't get any audio stuttering at all. I'm happily playing my Steam games with a Nintendo Wii Classic controller - the Raspberry Pi can handle limelight streaming, bluetooth input and wifi quite well.

You might want to disable any services on the pi that aren't pertinent to limelight streaming. I disable the following before streaming (though this might be unnecessary):

service rsyslog stop
service cron stop
service dbus stop
service triggerhappy stop
service ifplugd stop
service ntp stop

[cybern0id]

I'll need to play a bit more to check audio lag though... I've not noticed it being too laggy so far.

[H3llK33p3r]

I just noticed it on batman arkham origin movies. But I don't understand why your version is different from irtimmer one because the AudioStream class is also set with the following parameter:

public static final int RTP_RECV_BUFFER = 64 * 1024;

I will test asap to shutdown the services to analyze if there is any impact but I don't think so.

[cybern0id]

irtimmer's limelight-pi repo uses his limelight-common "pi" branch (not the "master" branch) due to this commit: 5fbcff3
The "pi" branch of limelight-common is used to compile limelight-pi (when you do git submodule update --init) and it has RTP_RECV_BUFFER = 12 * 100;

[cybern0id]

I've done some more digging into the code and commit history and have found that changes made to improve audio and video performance by reducing the size of the buffers in this commit: irtimmer/moonlight-common@dc35277 have been reverted by this commit: irtimmer/moonlight-common@3dd9a41
In particular the "DU_LIMIT" in both

libs/common/src/com/limelight/nvstream/av/audio/AudioDepacketizer.java

and

libs/common/src/com/limelight/nvstream/av/video/VideoDepacketizer.java

I've changed those back to DU_LIMIT = 5; in both the Audio and Video Depacketizer java files in my fork and changed RTP_RECV_BUFFER = 8 * 1024; and have found the performance of the compiled jar file to be good, possibly slightly better than before.

I've compiled an experimental jar file if anyone wants to try it? See https://github.com/7hunderbug/limelight-pi/releases/tag/v0.9.1-al-test

[scoobyd00]

That's great, I'll test the file out tomorrow when ive got access to my pi

[irtimmer]

DU_LIMIT isn't used for Audio. While it is for video. It haven't much of a performance benefit. Except that a too small DU_LIMIT will block big video packets.

RTP_RECV_BUFFER influences the buffer used. I have set it to 12 * 100 to allow a maximum delay of 100ms. Setting this to absurd high values maybe solved stuttering. It become really annoying if after a few minutes the audio is a second delayed. As my version work flawlessly on my own Pi I guess we haven't yet found the real problem.

[scoobyd00]

Ive just done some stress testing with the 0.9.1.-al-test and irtimmer is right, although it does solve the audio stuttering issues weve been getting to start with but after a few minutes of play there is a second delay of about 1 second on the audio and it seems that input lag is also introduced.

Ive also tried irtimmer 0.9.1 release on a new model b+ pi with a new install on a microsd card and i still get the serious audio stuttering.

Irtimmer could you tell us what os your running with to get 0.9.1 to run flawlessly and maybe your setup?, im running RASPBIAN

Debian Wheezy
Version:June 2014
Release date:2014-06-20

Its strange how 0.9.1 is working for some people and not others.

[cybern0id]

Hmmm, it is very strange. I stress tested my experimental build last night also for about an hour playing "The Swapper" and had no noticeable audio lag build up at all! I did get a couple of audio and video hiccups but nothing significant at all.

@irtimmer is the AudioDepacketizer not used in your version of limelight? Also, could you let us know which OS you use, which model Raspberry Pi, whether you overclock, GPU memory allocation, which firmware/kernel version and which version of Oracle Java SDK (on your video you seem to be running java-embedded binary which isn't part of the Raspian release of Oracle Java 7 SDK)

I have this version of java SDK installed:

dpkg -l | grep oracle
ii  oracle-java7-jdk                      1.7.0+update40                          armhf        Java™ Platform, Standard Edition 7 Development Kit
ii  oracle-java8-jdk                      8                                       armhf        Java™ Platform, Standard Edition 8 Development Kit

with Java 7 being the default as set in /etc/alternatives/

Perhaps the introduction of the RTP queue moonlight-stream/moonlight-common-android@5cbfe48 is causing the issue for those of us who v0.9.1 doesn't work??.....

[beakersoft]

Mine seems to be working really well with the new 0.9.1 test version, the previous release still gave me the stuttering audio issue. I'm using an overclocked B+ pi

[irtimmer]

I'm using Archlinux. But could you test with getCapabilities in AlsaAudioRenderer returning 0 and DU_LIMIT = 12 in AudioDepacketizer.

[cybern0id]

Please check that I've done this correctly, I'm not a coder, merely a tinkerer!

I commented out the return line in getCapabilities() in AlsaAudioRenderer

//    return CAPABILITY_DIRECT_SUBMIT;

and put

return 0;

instead. I changed DU_LIMIT=12 in AudioDepacketizer also (from DU_LIMIT=30).

The resultant compiled .jar does improve audio stuttering somewhat but it isn't perfect. I've uploaded the .jar to my releases page here: https://github.com/7hunderbug/limelight-pi/releases/tag/v0.9.1-test2

I should mention that the compile process does throw up some warnings but I've always ignored them because the compile was always successful. Does this matter at all? This is what the compile shows on stdout:

JAVA_HOME=/usr/lib/jvm/jdk-7-oracle-armhf ant dist
Buildfile: /home/pi/sources/irtimmer/limelight-pi/build.xml

compile-native:
     [exec] cc -I /usr/lib/jvm/jdk-7-oracle-armhf/include -I /usr/lib/jvm/jdk-7-oracle-armhf/include/linux -I /opt/vc/include -I/opt/vc/include/interface/v/interface/vmcs_host/linux -I ./inc -fPIC -L. -DSTANDALONE -D__STDC_CONSTANT_MACROS -D__STDC_LIMIT_MACROS -DTARGET_POSIX -D_LINUX -fPIC -DPIC -D_REENTRANT OFFSET_BITS=64 -U_FORTIFY_SOURCE -Wall -g -DHAVE_LIBOPENMAX=2 -DOMX -DOMX_SKIP64BIT -ftree-vectorize -pipe -DUSE_EXTERNAL_OMX -DHAVE_LIBBCM_HOST -DUSE_EXTERM -Wno-psabi   -c -o nv_omx_dec.o nv_omx_dec.c
     [exec] nv_omx_dec.c: In function ‘nv_omx_init’:
     [exec] nv_omx_dec.c:59:6: warning: unused variable ‘packet_size’ [-Wunused-variable]
     [exec] nv_omx_dec.c:58:15: warning: unused variable ‘data_len’ [-Wunused-variable]
     [exec] nv_omx_dec.c:56:15: warning: unused variable ‘clock’ [-Wunused-variable]
     [exec] nv_omx_dec.c:55:33: warning: unused variable ‘cstate’ [-Wunused-variable]
     [exec] nv_omx_dec.c: In function ‘nv_omx_stop’:
     [exec] nv_omx_dec.c:167:6: warning: variable ‘status’ set but not used [-Wunused-but-set-variable]
     [exec] nv_omx_dec.c: In function ‘nv_omx_decode’:
     [exec] nv_omx_dec.c:164:1: warning: control reaches end of non-void function [-Wreturn-type]
     [exec] cc -I /usr/lib/jvm/jdk-7-oracle-armhf/include -I /usr/lib/jvm/jdk-7-oracle-armhf/include/linux -I /opt/vc/include -I/opt/vc/include/interface/v/interface/vmcs_host/linux -I ./inc -fPIC -L. -DSTANDALONE -D__STDC_CONSTANT_MACROS -D__STDC_LIMIT_MACROS -DTARGET_POSIX -D_LINUX -fPIC -DPIC -D_REENTRANT OFFSET_BITS=64 -U_FORTIFY_SOURCE -Wall -g -DHAVE_LIBOPENMAX=2 -DOMX -DOMX_SKIP64BIT -ftree-vectorize -pipe -DUSE_EXTERNAL_OMX -DHAVE_LIBBCM_HOST -DUSE_EXTERM -Wno-psabi   -c -o nv_omx_dec_jni.o nv_omx_dec_jni.c
     [exec] nv_omx_dec_jni.c: In function ‘Java_com_limelight_binding_video_OmxDecoder_decode’:
     [exec] nv_omx_dec_jni.c:41:2: warning: pointer targets in passing argument 1 of ‘nv_omx_decode’ differ in signedness [-Wpointer-sign]
     [exec] nv_omx_dec.h:5:5: note: expected ‘unsigned char *’ but argument is of type ‘jbyte *’
     [exec] cc -I /usr/lib/jvm/jdk-7-oracle-armhf/include -I /usr/lib/jvm/jdk-7-oracle-armhf/include/linux -I /opt/vc/include -I/opt/vc/include/interface/v/interface/vmcs_host/linux -I ./inc -fPIC -L. -DSTANDALONE -D__STDC_CONSTANT_MACROS -D__STDC_LIMIT_MACROS -DTARGET_POSIX -D_LINUX -fPIC -DPIC -D_REENTRANT OFFSET_BITS=64 -U_FORTIFY_SOURCE -Wall -g -DHAVE_LIBOPENMAX=2 -DOMX -DOMX_SKIP64BIT -ftree-vectorize -pipe -DUSE_EXTERNAL_OMX -DHAVE_LIBBCM_HOST -DUSE_EXTERM -Wno-psabi   -c -o inc/ilclient.o inc/ilclient.c
     [exec] cc -I /usr/lib/jvm/jdk-7-oracle-armhf/include -I /usr/lib/jvm/jdk-7-oracle-armhf/include/linux -I /opt/vc/include -I/opt/vc/include/interface/v/interface/vmcs_host/linux -I ./inc -fPIC -L. -DSTANDALONE -D__STDC_CONSTANT_MACROS -D__STDC_LIMIT_MACROS -DTARGET_POSIX -D_LINUX -fPIC -DPIC -D_REENTRANT OFFSET_BITS=64 -U_FORTIFY_SOURCE -Wall -g -DHAVE_LIBOPENMAX=2 -DOMX -DOMX_SKIP64BIT -ftree-vectorize -pipe -DUSE_EXTERNAL_OMX -DHAVE_LIBBCM_HOST -DUSE_EXTERM -Wno-psabi   -c -o inc/ilcore.o inc/ilcore.c
     [exec] cc -shared -Wl,--no-undefined -L. -L /opt/vc/lib/ -lbcm_host -lopenmaxil -lvcos -lvchiq_arm -lpthread -lrt -o libnv_omx_dec.so nv_omx_dec.o nv_nc/ilcore.o
     [exec] cc -I /usr/lib/jvm/jdk-7-oracle-armhf/include -I /usr/lib/jvm/jdk-7-oracle-armhf/include/linux -I /usr/include/opus -fPIC -L.   -c -o nv_opus_d
     [exec] cc -I /usr/lib/jvm/jdk-7-oracle-armhf/include -I /usr/lib/jvm/jdk-7-oracle-armhf/include/linux -I /usr/include/opus -fPIC -L.   -c -o nv_opus_d
     [exec] cc -shared -Wl,--no-undefined -lopus -L. -o libnv_opus_dec.so nv_opus_dec_jni.o nv_opus_dec.o
     [exec] cc -I /usr/lib/jvm/jdk-7-oracle-armhf/include -I /usr/lib/jvm/jdk-7-oracle-armhf/include/linux -fPIC -L.   -c -o nv_alsa.o nv_alsa.c
     [exec] cc -I /usr/lib/jvm/jdk-7-oracle-armhf/include -I /usr/lib/jvm/jdk-7-oracle-armhf/include/linux -fPIC -L.   -c -o nv_alsa_jni.o nv_alsa_jni.c
     [exec] nv_alsa_jni.c: In function ‘Java_com_limelight_binding_audio_AlsaAudio_init’:
     [exec] nv_alsa_jni.c:14:13: warning: assignment discards ‘const’ qualifier from pointer target type [enabled by default]
     [exec] cc -shared -Wl,--no-undefined -L. -lasound -o libnv_alsa.so nv_alsa.o nv_alsa_jni.o
     [exec] cc -I /usr/lib/jvm/jdk-7-oracle-armhf/include -I /usr/lib/jvm/jdk-7-oracle-armhf/include/linux -fPIC -L.   -c -o nv_io_jni.o nv_io_jni.c
     [exec] cc -shared -Wl,--no-undefined -L. -o libnv_io.so nv_io_jni.o

init:
    [mkdir] Created dir: /home/pi/sources/irtimmer/limelight-pi/classes
    [mkdir] Created dir: /home/pi/sources/irtimmer/limelight-pi/classes/common
    [mkdir] Created dir: /home/pi/sources/irtimmer/limelight-pi/classes/src
    [mkdir] Created dir: /home/pi/sources/irtimmer/limelight-pi/build

compile-common:
    [javac] Compiling 40 source files to /home/pi/sources/irtimmer/limelight-pi/classes/common

compile-java:
    [javac] Compiling 17 source files to /home/pi/sources/irtimmer/limelight-pi/classes/src

build:

dist:
  [one-jar] Building jar: /home/pi/sources/irtimmer/limelight-pi/build/limelight-pi.jar

[clonmac]

I just wanted to post that I had a chance to do some tests with some of the versions that have been posted and thought I'd post my results. I'm using a stock Raspbian install on my Raspberry Pi B with 256 GPU memory allocated.

Version 0.9.1 gave me awful audio stuttering, but the video was decent.

I tested out both test versions that 7hunderbug posted up. The first one ran the best for me. The audio performed the best and video was good. I had slight input lag here and there, but it was still playable. I played for about an hour and didn't notice any audio lag that built up over time.

The second test .jar that 7hunderbug posted was better audio wise that the official 0.9.1 release, but the audio was still stuttering and I'd say unplayable.

I hope this helps.

[irtimmer]

I've found the problem. You're propably using Pulseaudio. Solution is simple

sudo aptitude remove pulseaudio

or disable pulseaudio using pasuspender

pasuspender -- java -jar limelight-pi.jar [ip-address]

For the next version of Limelight Pi I probably add a check to warn users about pulseaudio.

[cybern0id]

No, the problem isn't pulseaudio. I don't have it installed and still suffer audio problems with 0.9.1. I don't think pulseaudio is part of the default raspbian install any more any way.

[irtimmer]

Could you test with the latest commit on Github. Because with that I'm unable to reproduce the problem on Raspbian (up-to-date) with default config.txt on my Raspberry Pi B (256MB)

[scoobyd00]

Just compiled the latest commit (first time ever!!, took me a while to figure out what i need to do but got there :)

I can confirm its fixed :) sound stuttering has gone with the latest commit and its working fine.
Im running Raspbian and Pi model B(256mb) with 128/128 memory split.

Excellent work irtimmer.

[H3llK33p3r]

@scoobyd00 on an overclocked pi ? I just test on a non overclocked pi ( raspberry B.2 256 system / 256 GPU ) and I always have stuttering (I try to update the pi with rpi-update but no changes). But If you confirm that you use a overclocked raspberry I understand that work for you.

[scoobyd00]

@HellKeeper62 My PI isnt overclocked and ive tested a couple of times now and my audio is fixed.
Have you compiled the latest commit?.

[H3llK33p3r]

@scoobyd00 Yes... Don't understand why so difference between all of us on this thread...

[scoobyd00]

@HellKeeper62 It is strange, i had awful sound stuttering making the gaming unplayable but after the latest commit this has totally disappeared and its running smoothly now, even playing at 1080 is fine.

[H3llK33p3r]

So if other people can confirm it's may be a problem in my side ;) !

[pillepalle123]

can't check it yet, since I'm not sure how to compile....
but I don't think that I have pulseaudio running.

Besides I have to run "sudo modprobe snd-bcm2835" to get alsamixer working, otherwise limelight wont't start... maybe that's part of the issue?

[cybern0id]

I haven't tried with the new commits though I doubt the changes will make any difference to my setup either. I won't get chance this weekend to test but will do so beginning of next week.

I have been using my 512MB RPi split 256/256 for all testing so far and so I decided to test the latest 0.9.1 limelight-pi release on one of my 256MB Pis with 128/128 split and I had exactly the same audio stuttering issues.

What is also very strange is that the changes I made for my test releases work really well for my setup but cause audio lag for others.

Clutching at straws here but I'm beginning to wonder whether this problem is related to certain batches of Rpi from certain suppliers and/or the type of memory used on the board. All my Pis are from very early batches of the model B 256MB (with poly fuses) and the model B 512MB (without poly fuses).

Other than that, it must be network related. Has anyone any advice for capturing limelight-pi RTP traffic on the RPi whilst streaming is occurring? tcpdump or nmap or similar?

[stoicails]

hi all

first of all a big thanks for the work on this great project!

I just made a git account now to tell you that the latest commit made the audio stuttering disappear :D

I always had the audio stuttering with the versions 0.9 and 0.91.. today I wanted to do more tests and found this discussion and finally after compiling everything works magically :)

But I couldn't do a longer testing yet ;)

I don't know if my compiled jar can work on others pi, but I thought I upload it in case it should ;) here: http://netcay.ch/files/limelight-pi-20140815.jar

im running raspbian, allocated 128 from 512 to the gpu. arm freq 800, core freq 300, sdram freq 400, over voltage 0

for this first test I ran it without any arguments like -720 or similiar.. just java -jar ..

thx again for your hard work.. :)

[clonmac]

Thanks for uploading the latest commit compiled. I've been experiencing the stuttering too. I'll give it a test a little later on and post my results.

[clonmac]

I tried testing the with .jar that you compiled, stoicails, but I wasn't able to get it to work. It said something about a version mismatch. I'm not at my RPi at the moment, so I can't say exactly what the error message referred to. Is anyone else able to compile it for me to test?

[scoobyd00]

You can try mine..

http://www.filedropper.com/limelight-pi

[clonmac]

Thanks Scooby for hosting that. I was able to get yours to work on my RPi. Unfortunately the audio still stuttered quite frequently. Not as bad as the current release version, but still enough to make you not want to play a game with it.

So far, the best version that works for me was the first test one uploaded by 7hunderBug. Though there is room left for improvement in that version as well.

Thanks so far for everyone's efforts in this project.

[bundyboss]

I've same problem with sound.
I've tested the last jar of 7hunderbug and now the problem is solved.
So I confirm that change made by 7hunderbug is working on my raspberry pi.
I've a Raspberry pi model B not overclocked with 256 mem split.
Still a delay when I play (pinball games are very hard with this delay) but playing Outlast is possible.
The sound level is low

I've tested to play with a PS3 controller with Bluetooth but with the "real" version and 7hunderbug version it's unplayable. Game is very slow
If I start the jar without bluetooth game start normaly.
Hope I can help with this return

[bundyboss]

I've tested scoobyd00 jar version too and it's working correctly.
No sound problem with this version. Same as 7hunderbug for me.
I've tested with my pi overclocked and the delay with the keyboard seems to be better.

[irtimmer]

If there are people who still have audio problems with scoobyd00 version. Could you send me the output of:
dmesg
top -b
dpkg-query -l

[pillepalle123]

scoobyd00s version solved the sound problem for me too! thx!

[clonmac]

OK, so I just reinstalled the latest Raspbian on my SD card and ran the latest commit again and I don't get any stuttering.

The catch is that anytime I send any input, I receive audio stuttering. So if I don't type or move my mouse, audio is fine. But, as soon as I move my mouse and start clicking on this, the audio starts to get choppy. Maybe this is the stuttering some others are experiencing when testing?

Also, if I send a lot of input through, it all backs up and lags more and more until I stop. For example, I'll circle the mouse around the screen and it starts out OK, but then starts to lag behind and the mouse pointer gets laggier and laggier until I stop circling.

All is fine without stutter in the audio or video if I don't touch any input controls and just watch the screen.

The latency must be from the RPi as I stream using several other methods from the same host PC over the same network without these problems.

Does anyone else experience this?

[H3llK33p3r]

I don't know why my previous comment is not in this thread but :

@clonmac I monitored the same issue since we have notified the sound issue.

I tried another OS (arch linux) but I still have the same problem with a non overcloked pi.

@irtimmer FYI, the video decoders are "bugged" (the load method) because they always return "false" ;) ! So the actual trunk version does not display video :). Just to fix the return In ImxDecoder and OmxDecoder ;).

[irtimmer]

It looks like audio stuttering is now solved. The other problems can be put in a seperate issue reports.