Hi all,
just as a quick status message: I'm currently working on integrating PulseAudio into the OS X client and it looks good so far.
PA will be started as soon as the client launches and killed on terminate... well, actually is.
A quick test on 10.5 and 10.6 boxes show that the OS X version of PA works reasonably fine (at least it starts up and can play a sample WAVE file, so I call it a success.)
Will try implementing PA session stuff tomorrow and do a few tests with it.
We'll see, fingers crossed...
Best regards,
Mihai
Hi Mihai,
short notice: your former patches have all been accepted and are
pending Git inclusion. Thanks for doing all that great work!!!
On Di 29 Mai 2012 14:25:39 CEST Mihai Moldovan wrote:
A quick test on 10.5 and 10.6 boxes show that the OS X version of PA works reasonably fine (at least it starts up and can play a sample WAVE file, so I call it a success.)
A better test is: run the pavucontrol tool within the X2Go session and
test if the PA process on the MAC survives all the PA-specific mixer
and volume meter API calls.
With the old Windows version (and also old PA versions on Linux), this
has often been an issue.
Mike
--
DAS-NETZWERKTEAM mike gabriel, rothenstein 5, 24214 neudorf-bornstein fon: +49 (1520) 1976 148
GnuPG Key ID 0xB588399B mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de
freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xf...
- On 29.05.2012 03:07 PM, Mike Gabriel wrote:
short notice: your former patches have all been accepted and are pending Git inclusion. Thanks for doing all that great work!!!
Thanks.
A better test is: run the pavucontrol tool within the X2Go session and test if the PA process on the MAC survives all the PA-specific mixer and volume meter API calls.
WORKSFORME... it seems to work fine on my Debian Unstable based remote server. I'll guess I'll have Stefan test on (older) Ubuntu boxes and stuff, if he's up to.
With the old Windows version (and also old PA versions on Linux), this has often been an issue.
I do have some other issues, though. Especially when starting a flash video in Iceweasel, sound is choppy, distorted, (< buffer underruns?) the video will halt a few seconds in-play, sound will roll on for like 20 seconds, then stop, video catch up fast and once the video has reached the sound position, both video and sound playback will pick up again, but sound and picture will be desynchronized as the sound makes a 20 seconds jump into the "future".
This is a very odd behavior, but I'm not sure what to make of it.
On the other hand, playing some MP3 file via mplayer (w/o any other application running) works flawlessly.
I have noticed problems when running pavucontrol and mplayer both at the same time, though.
But I figure both the pavucontrol+mplayer and flash video problems are due to the remote ADSL connection. I see a peak incoming traffic of about 250KB/s, hardly enough for both sound and video. Another circumstance that may well confirm this theory is that lowering the image quality (i.e., set to JPEG compression with 64 colors) has a positive effect on the sound output.
I'd really be interested to see tests on LAN, but unfortunately my only other box has no PA installed and I don't want to pollute the system with it. However, I guess that Stefan could come in here handy.
The code is not yet ready and I still have to tackle the esound emulation stuff, but I'd be happy to dump a test build here. Is anyone interested? Let me know.
Best regards,
Mihai
Am 30.05.2012 08:32, schrieb Mihai Moldovan:
A better test is: run the pavucontrol tool within the X2Go session and test if the PA process on the MAC survives all the PA-specific mixer and volume meter API calls.
WORKSFORME... it seems to work fine on my Debian Unstable based remote server. I'll guess I'll have Stefan test on (older) Ubuntu boxes and stuff, if he's up to.
No can do. I can test against a Debian Squeeze server with X2Go's stable packages, though.
[...]
I do have some other issues, though. Especially when starting a flash video in Iceweasel, sound is choppy, distorted, (< buffer underruns?) the video will halt a few seconds in-play, sound will roll on for like 20 seconds, then stop, video catch up fast and once the video has reached the sound position, both video and sound playback will pick up again, but sound and picture will be desynchronized as the sound makes a 20 seconds jump into the "future".
This is a very odd behavior, but I'm not sure what to make of it.
Our old friend Nagle?
I have noticed problems when running pavucontrol and mplayer both at the same time, though.
What kind of problems?
But I figure both the pavucontrol+mplayer and flash video problems are due to the remote ADSL connection. I see a peak incoming traffic of about 250KB/s, hardly enough for both sound and video. Another circumstance that may well confirm this theory is that lowering the image quality (i.e., set to JPEG compression with 64 colors) has a positive effect on the sound output.
Do we have some sort of rough estimate how much bandwidth we need for which color depth?
And would it be possible to lower the sound quality to conserve some bandwidth? I mean, it's rather unlikely somebody is going to expect Dolby 5.1 sound quality via GSM... ;-)
I'd really be interested to see tests on LAN, but unfortunately my only other box has no PA installed and I don't want to pollute the system with it. However, I guess that Stefan could come in here handy.
I'll give it a try, but I'm not really a Mac user (I bought this Mac solely to support X2Go development for Mac), so Jan and Stephan should join in if you want reliable results.
The code is not yet ready and I still have to tackle the esound emulation stuff, but I'd be happy to dump a test build here. Is anyone interested? Let me know.
Jan, Stephan, your call!
-Stefan
On Holiday until 18.6. I have to Test it later.
Stephan
Von meinem iPhone gesendet
Am 30.05.2012 um 03:09 schrieb Stefan Baur <newsgroups.mail2@stefanbaur.de>:
Am 30.05.2012 08:32, schrieb Mihai Moldovan:
A better test is: run the pavucontrol tool within the X2Go session and test if the PA process on the MAC survives all the PA-specific mixer and volume meter API calls.
WORKSFORME... it seems to work fine on my Debian Unstable based remote server. I'll guess I'll have Stefan test on (older) Ubuntu boxes and stuff, if he's up to.
No can do. I can test against a Debian Squeeze server with X2Go's stable packages, though.
[...]
I do have some other issues, though. Especially when starting a flash video in Iceweasel, sound is choppy, distorted, (< buffer underruns?) the video will halt a few seconds in-play, sound will roll on for like 20 seconds, then stop, video catch up fast and once the video has reached the sound position, both video and sound playback will pick up again, but sound and picture will be desynchronized as the sound makes a 20 seconds jump into the "future".
This is a very odd behavior, but I'm not sure what to make of it.
Our old friend Nagle?
I have noticed problems when running pavucontrol and mplayer both at the same time, though.
What kind of problems?
But I figure both the pavucontrol+mplayer and flash video problems are due to the remote ADSL connection. I see a peak incoming traffic of about 250KB/s, hardly enough for both sound and video. Another circumstance that may well confirm this theory is that lowering the image quality (i.e., set to JPEG compression with 64 colors) has a positive effect on the sound output.
Do we have some sort of rough estimate how much bandwidth we need for which color depth?
And would it be possible to lower the sound quality to conserve some bandwidth? I mean, it's rather unlikely somebody is going to expect Dolby 5.1 sound quality via GSM... ;-)
I'd really be interested to see tests on LAN, but unfortunately my only other box has no PA installed and I don't want to pollute the system with it. However, I guess that Stefan could come in here handy.
I'll give it a try, but I'm not really a Mac user (I bought this Mac solely to support X2Go development for Mac), so Jan and Stephan should join in if you want reliable results.
The code is not yet ready and I still have to tackle the esound emulation stuff, but I'd be happy to dump a test build here. Is anyone interested? Let me know.
Jan, Stephan, your call!
-Stefan
X2Go-Dev mailing list X2Go-Dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/x2go-dev
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi there,
Am 30.05.2012 09:09, schrieb Stefan Baur:
I'd really be interested to see tests on LAN, but unfortunately my only other box has no PA installed and I don't want to pollute the system with it. However, I guess that Stefan could come in here handy.
I'll give it a try, but I'm not really a Mac user (I bought this Mac solely to support X2Go development for Mac), so Jan and Stephan should join in if you want reliable results.
The code is not yet ready and I still have to tackle the esound emulation stuff, but I'd be happy to dump a test build here. Is anyone interested? Let me know.
Jan, Stephan, your call!
I didn't follow the discussion closely. What exactly should be tested?
Cheers, Jan.
Never write mail to <waja@spamfalle.info>, you have been warned!
- -----BEGIN GEEK CODE BLOCK----- Version: 3.12 GIT d-- s+: a C+++ UL++++ P+ L+++ E--- W+++ N+++ o++ K++ w--- O M V- PS PE Y++ PGP++ t-- 5 X R tv- b+ DI D+ G++ e++ h---- r+++ y++++
- ------END GEEK CODE BLOCK------ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux)
iD8DBQFPypDu9u6Dud+QFyQRAonPAKD6oHBIopYDnnuXcMJCbta536B1DACfUGlx 0AvA0gEYIOug+rwf6RjX6hQ= =A0Vk -----END PGP SIGNATURE-----
Hi,
I've done some tests on Ubuntu and Debian stable VMs in my local network.
- On 30.05.2012 08:32 AM, Mihai Moldovan wrote:
I do have some other issues, though. Especially when starting a flash video in Iceweasel, sound is choppy, distorted, (< buffer underruns?) the video will halt a few seconds in-play, sound will roll on for like 20 seconds, then stop, video catch up fast and once the video has reached the sound position, both video and sound playback will pick up again, but sound and picture will be desynchronized as the sound makes a 20 seconds jump into the "future".
While I'm not seeing any synchronizing errors on my local network (probably due to the increased throughput, video is also way more fluent), sound output in YouTube video streams is still not perfect. Just seems like the buffer is not filling up fast enough.
People using x2go on Windows/Linux: what is your experience with YouTube videos? Is the playback (at least audio) always smooth for you?
On the other hand, playing some MP3 file via mplayer (w/o any other application running) works flawlessly.
I can confirm this on my local network, too. Just streaming sound without any video playback is smooth and seems to work great. This also includes Flash based audio players found on the WWW.
I have noticed problems when running pavucontrol and mplayer both at the same time, though.
No problems there. Again, probably due to the increased maximum throughput compared to my ADSL line.
Best regards,
Mihai
Am 30.05.2012 08:32, Mihai Moldovan schrieb:
I do have some other issues, though. Especially when starting a flash video in Iceweasel, sound is choppy, distorted, (< buffer underruns?) the video will halt a few seconds in-play, sound will roll on for like 20 seconds, then stop, video catch up fast and once the video has reached the sound position, both video and sound playback will pick up again, but sound and picture will be desynchronized as the sound makes a 20 seconds jump into the "future".
This is a very odd behavior, but I'm not sure what to make of it.
On the other hand, playing some MP3 file via mplayer (w/o any other application running) works flawlessly.
I have noticed problems when running pavucontrol and mplayer both at the same time, though.
But I figure both the pavucontrol+mplayer and flash video problems are due to the remote ADSL connection. I see a peak incoming traffic of about 250KB/s, hardly enough for both sound and video. Another circumstance that may well confirm this theory is that lowering the image quality (i.e., set to JPEG compression with 64 colors) has a positive effect on the sound output.
If the network connection is limited pulse becomes pretty unhappy. It's buffering algorithm is designed for LANs or at least stable conditions. It also seems to make certain assumptions about the delay of other data or whatever. In your case it seems like it's buffering 20 secs; but reacts immediately to play and pause commands, which is what you want when listening to mp3s. As the setup will not allow to connect timestamps to images and sound I'm afraid video and sound will just not work properly over a limited connection and will never be perfectly in sync even when using a LAN.
Cheers Morty
Am 31.05.2012 09:08, schrieb Moritz Strübe:
As the setup will not allow to connect timestamps to images and sound I'm afraid video and sound will just not work properly over a limited connection and will never be perfectly in sync even when using a LAN.
Do we have any chance to re-code the audio on the server into a lossy, lower-quality version before transmitting it to the client? I mean, we provide quie a few options for image compression, to match different bandwidth limits - would a similar approach be possible for audio as well?
-Stefan
Am 31.05.2012 09:19, Stefan Baur schrieb:
Do we have any chance to re-code the audio on the server into a lossy, lower-quality version before transmitting it to the client? I mean, we provide quie a few options for image compression, to match different bandwidth limits - would a similar approach be possible for audio as well?
As long as video uses the same connection this will not help, as the delay is the problem, not the amount of audio data. The only way to get it working is to encode sound and video together..... QoS might help a bit, but only under certain circumstances. I'm afraid at the moment we have to be happy with what we have (which is way better then everything else :-) ).
Cheers Morty
On Thu, 2012-05-31 at 10:17 +0200, Moritz Strübe wrote:
Am 31.05.2012 09:19, Stefan Baur schrieb:
Do we have any chance to re-code the audio on the server into a lossy, lower-quality version before transmitting it to the client? I mean, we provide quie a few options for image compression, to match different bandwidth limits - would a similar approach be possible for audio as well?
As long as video uses the same connection this will not help, as the delay is the problem, not the amount of audio data. The only way to get it working is to encode sound and video together..... QoS might help a bit, but only under certain circumstances. I'm afraid at the moment we have to be happy with what we have (which is way better then everything else :-) ). <snip> Despite the fact that it will not solve this problem, the idea of compressing audio based upon bandwidth is very attractive.
I have found video on NX difficult even on a LAN. SPICE handles this much better. As I mentioned several times, as it matures, we may wish to slot it in as an alternative to NX in the X2Go framework - John
-
Jan Wagner -
John A. Sullivan III -
Mihai Moldovan -
Mike Gabriel -
Moritz Strübe -
Stefan Baur -
Stephan Diehl