Open kokoko3k opened 9 years ago
XSDL stops music playback when in background, but it should not stop clients from redrawing the screen. I'll look into the ways to fix music issue. Xdmx will not help here, because the music is played through PulseAudio server, not through X socket.
On Tue, Oct 27, 2015 at 10:00 AM, Antonio Orefice notifications@github.com wrote:
I just installed a chroot environment on a galaxy s2 and almost everything is working fine except for a single irritating issue. If the Xserver is not the frontmost application, it becomes unresponsive and the underliyng clients just hangs until i bring it to the front again.
Use case: if i am playing an mp3 via an X gui application, as soon as i switch to another android app, the music just stops, because the X player cant update his gui (eg: for displaying the new song time position). So i switch to Xserver again and the music starts.
Sure i could use vnc for that, but i'd like Xserver xsdl :)
Is there a way to force Xserver Xsdl to answer to clients even when it is not the frontmost app? Maybe i can use some sort of X.org proxy like Xdmx, but i suspect that i'll have a performance hit.
Thanks for your attention.
— Reply to this email directly or view it on GitHub https://github.com/pelya/xserver-xsdl/issues/50.
I'm not using XSDL to play music. (I use pulseaudio via network and another app to play it back.) The client just stops to send music because it is waiting for the graphic server to update the screen, i think.
Okay, so it's a different bug then. Unfortunately it's quite complicated to change existing rendering process, I'll try to work around that when I'll have time.
On Tue, Oct 27, 2015 at 9:45 PM, Antonio Orefice notifications@github.com wrote:
I'm not using XSDL to play music. (I use pulseaudio via network and another app to play it back.) The client just stops to send music because it is waiting for the graphic server to update the screen, i think.
— Reply to this email directly or view it on GitHub https://github.com/pelya/xserver-xsdl/issues/50#issuecomment-151621995.
Thanks, meanwhile a simple proof: 1 - start xsdl switch to terminal 2 - DISPLAY=:0.0 openbox & 3 - DISPLAY=:0.0 xterm & switch to xsdl and see that open box and xterm are correctly initialized now bring xsdl to the background and go back to the terminal 4 - DISPLAY=:0.0 xterm -e "touch /tmp/touch" (xterm -e executes a command) 5- go in another terminal and see that /tmp/touch is not there. 6- bring XSDL to the front 7- see that /tmp/touch has been created as soon as XSDL has gained the "focus" that means that xterm -e was waiting for an answer from the X server, i think.
I'll see if Xdmx could bypass the issue.
Could you please try this build? http://sourceforge.net/projects/libsdl-android/files/tmp/XServer-XSDL-1.11.37-non-blocking-video.apk/download
On Tue, Oct 27, 2015 at 9:56 PM, Antonio Orefice notifications@github.com wrote:
Thanks, meanwhile a simple proof: 1 - start xsdl switch to terminal 2 - DISPLAY=:0.0 openbox & 3 - DISPLAY=:0.0 xterm & switch to xsdl and see that open box and xterm are correctly initialized now bring xsdl to the background and go back to the terminal 4 - DISPLAY=:0.0 xterm -e "touch /tmp/touch" (xterm -e executes a command) 5- go in another terminal and see that /tmp/touch is not there. 6- bring XSDL to the front 7- see that /tmp/touch has been created as soon as XSDL has gained the "focus"
— Reply to this email directly or view it on GitHub https://github.com/pelya/xserver-xsdl/issues/50#issuecomment-151624842.
Seems to work great! Many thanks.
Okay. Unfortunately I won't be putting that into Play Store, as it's buggy and sometimes does not re-init graphics when invoked from background.
On Thu, Oct 29, 2015 at 7:40 PM, Antonio Orefice notifications@github.com wrote:
Seems to work great! Many thanks.
— Reply to this email directly or view it on GitHub https://github.com/pelya/xserver-xsdl/issues/50#issuecomment-152260843.
I really hope you manage to correct the bugs and publish it to the play store. Meanwhile i gave a try to the audio streaming provided by xsdl, and, sadly it stops to play too. (as you pointed out in your first comment). Now that xsdl is able to update the screen when in background, it would be even better if the audio would continue to work as well.
PS: i've still had to spot any instability. The only strange thing i see is that if i close the android window the server stops and then starts again. While if i just keep it open and switch to another android window, it works flawlessly
Any update on this? Redrawing wouldn't be so important for me but music playback continuing would be...
I just installed a chroot environment on a galaxy s2 and almost everything is working fine except for a single irritating issue. If the Xserver is not the frontmost application, it becomes unresponsive and the underliyng clients just hangs until i bring it to the front again.
Use case: if i am playing an mp3 via an X gui application, as soon as i switch to another android app, the music just stops, because the X player cant update his gui (eg: for displaying the new song time position). So i switch to Xserver again and the music starts.
Sure i could use vnc for that, but i'd like Xserver xsdl :)
Is there a way to force Xserver Xsdl to answer to clients even when it is not the frontmost app? Maybe i can use some sort of X.org proxy like Xdmx, but i suspect that i'll have a performance hit.
Thanks for your attention.