I don't use Ubuntu, but I've just downloaded 9.10 and installed it in VMware.
Testify works okay for me - pulseaudio is using about 30% CPU and Testify is
using about 20% - but I can still use the rest of the system okay.
Is it Testify that is using all the CPU in your system? The "top" command will
tell you what is going on.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
ok, thanks for narrowing down the problem - 20090917 was the last release that
used libspotify 0.0.1 - newer releases use libspotify 0.0.2 - I will do some
profiling in my VMware image and see if I can do anything about it...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Got a freeze with ntop and testify both taking ~50% CPU
After restarting ntop and testify, the testify client went into a kind of
"time warp" mode. It was cutting samples short and "song time" was advancing
too rapidly.
Looks like something funky in Ubuntu libs.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Spotify have released a new version of their libspotify library - v0.0.3 - are
you still getting problems with the latest version (2010-01-21) of Testify?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am using Ubuntu 9.10 x64 and have noticed I get an issue after a while that
sounds like this, though restarting testify seems to solve the issue for a
while before it reoccurs, this is with the latest 2010-01-21 version. I have
only noticed testify maxing out one of my cpu cores, I didn't notice the ntop
program ejnevala mentioned. I'm happy to provide more info if you require it?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'll try compiling it on Ubuntu (rather than on the Gentoo boxes I normally
use) and see if that makes any difference. Give me a few days to get gcc etc
installed on my VMware image...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
OK, I've tracked down the problem. Testify is calling the ALSA function
"snd_pcm_writei" to send audio data to the sound card. When the problem
strikes, this function never returns and this ultimately leads to Testify
maxing out the CPU.
Sadly, it looks like the way Testify uses ALSA doesn't work well with
distributions that use Pulse Audio (eg Ubuntu 9.10 and above). Look at this
wiki page:
That page does mention other ways of using ALSA, so I'll look into those. The
method Testify uses is just copied straight from Spotify's jukebox example
code that comes with libspotify. So it looks like some work for me...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In theory, if this is a pulse audio problem, then running testify like this:
pasuspender /usr/local/bin/testify
should make it work - as this disable pulse audio for testify. When I try it
in vmware I get no sound at all, but it may be worth trying on your real
ubuntu system.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The command you suggested seems to cause testify to run but be unable to play
audio at all. Having downloaded v20100209 and updated Ubuntu 9.10 to the
latest updates this still appears to be the case. However, since updating
Ubuntu and Testify I have not had another freezeup, I will keep you posted
though.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
OK well it seems my comment about no more freezeups may be premature, testify
just locked up in the same way as previously :-( Any idea why your suggested
command might cause the program to not play at all?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Failed to load module: /usr/lib/gio/modules/libgiogconf.so
which does not happen when running from the console without the pasuspender
command. It would appear that testify exhibits similar CPU maxing out
behaviour to when it freezes up after a while if launched normally, but
behaviour occurs immediately you try to play a track and no audio is heard.
Hope this info may be helpful.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I started testify just now and it failed with the following error message:
*** glibc detected *** testify: corrupted double-linked list: 0x08315d18 ***
Segmentation fault[/quote]
*** glibc detected *** testify: corrupted double-linked list: 0x08315d18 ***
Segmentation fault
Everyone of course loves a segmentation fault... I checked /var/log/dpkg.log and it seems I have just recently installed the update libc-bin 2.10.1
Soo... is this bad?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
hmmm, I can't trigger the error on my vmware image - how far do you get before
the seg fault? can you run "testify -v" and post the last few log messages?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I haven't experienced any issues yet with Testify and Ubuntu 10.04, either
with an older release or the latest release. It would seem as far as I can
tell at least the earlier issue on Ubuntu that was causing sound to freeze is
no longer a problem. :-)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
When playing is started the testify client hangs almost immediately with high
CPU usage on Ubuntu 9.10 Karmic Koala
Hi,
I don't use Ubuntu, but I've just downloaded 9.10 and installed it in VMware.
Testify works okay for me - pulseaudio is using about 30% CPU and Testify is
using about 20% - but I can still use the rest of the system okay.
Is it Testify that is using all the CPU in your system? The "top" command will
tell you what is going on.
As I recall, yes. I've reinstalled the testify-20090917 version, which does
work quite fine.
ok, thanks for narrowing down the problem - 20090917 was the last release that
used libspotify 0.0.1 - newer releases use libspotify 0.0.2 - I will do some
profiling in my VMware image and see if I can do anything about it...
OK, more info now...
I started the older client after waking from hibernation. This ntop bug was
active
https://bugs.launchpad.net/ubuntu/+source/ntop/+bug/461141
Got a freeze with ntop and testify both taking ~50% CPU
After restarting ntop and testify, the testify client went into a kind of
"time warp" mode. It was cutting samples short and "song time" was advancing
too rapidly.
Looks like something funky in Ubuntu libs.
Hi,
Spotify have released a new version of their libspotify library - v0.0.3 - are
you still getting problems with the latest version (2010-01-21) of Testify?
I am using Ubuntu 9.10 x64 and have noticed I get an issue after a while that
sounds like this, though restarting testify seems to solve the issue for a
while before it reoccurs, this is with the latest 2010-01-21 version. I have
only noticed testify maxing out one of my cpu cores, I didn't notice the ntop
program ejnevala mentioned. I'm happy to provide more info if you require it?
I'll try compiling it on Ubuntu (rather than on the Gentoo boxes I normally
use) and see if that makes any difference. Give me a few days to get gcc etc
installed on my VMware image...
OK, I've tracked down the problem. Testify is calling the ALSA function
"snd_pcm_writei" to send audio data to the sound card. When the problem
strikes, this function never returns and this ultimately leads to Testify
maxing out the CPU.
Sadly, it looks like the way Testify uses ALSA doesn't work well with
distributions that use Pulse Audio (eg Ubuntu 9.10 and above). Look at this
wiki page:
http://alsa.opensrc.org/index.php/HowTo_Asynchronous_Playback
That page does mention other ways of using ALSA, so I'll look into those. The
method Testify uses is just copied straight from Spotify's jukebox example
code that comes with libspotify. So it looks like some work for me...
In theory, if this is a pulse audio problem, then running testify like this:
should make it work - as this disable pulse audio for testify. When I try it
in vmware I get no sound at all, but it may be worth trying on your real
ubuntu system.
The command you suggested seems to cause testify to run but be unable to play
audio at all. Having downloaded v20100209 and updated Ubuntu 9.10 to the
latest updates this still appears to be the case. However, since updating
Ubuntu and Testify I have not had another freezeup, I will keep you posted
though.
OK well it seems my comment about no more freezeups may be premature, testify
just locked up in the same way as previously :-( Any idea why your suggested
command might cause the program to not play at all?
OK I should probably paste the terminal errors as that might help, when
running from terminal with the above command the output is as follows
tom@planck:~$ pasuspender /usr/local/bin/testify
session: message_to_user 'You have 7 invites. https://www.spotify.coklzzwxh:0001m/account/share/">Share Spotify
with your friends!'
/usr/lib/gio/modules/libgvfsdbus.so: wrong ELF class: ELFCLASS64
Failed to load module: /usr/lib/gio/modules/libgvfsdbus.so
/usr/lib/gio/modules/libgioremote-volume-monitor.so: wrong ELF class:
ELFCLASS64
Failed to load module: /usr/lib/gio/modules/libgioremote-volume-monitor.so
/usr/lib/gio/modules/libgiogconf.so: wrong ELF class: ELFCLASS64
Failed to load module: /usr/lib/gio/modules/libgiogconf.so
which does not happen when running from the console without the pasuspender
command. It would appear that testify exhibits similar CPU maxing out
behaviour to when it freezes up after a while if launched normally, but
behaviour occurs immediately you try to play a track and no audio is heard.
Hope this info may be helpful.
ooo-kay... New fun @ Ubuntu.
I started testify just now and it failed with the following error message:
Stupid formatting... The error message is simply
glibc detected testify: corrupted double-linked list: 0x08315d18 ***
Segmentation fault
hmmm, I can't trigger the error on my vmware image - how far do you get before
the seg fault? can you run "testify -v" and post the last few log messages?
ejnevala@hostname:~$ testify -v
session: cache='/var/tmp/ejnevala/testify/'
session: lock='/var/tmp/ejnevala/testify/testify.lock'
session: settings='/home/ejnevala/.config/testify/libspotify/'
login: sent username and password
session: notify_main_thread
session: log_message '08:48:33.153 I Connecting to AP ap5.spotify.com:4070'
session: notify_main_thread
session: message_to_user 'You have X invites. https://www.spotify.coklzzwxh:0000m/account/share/">Share Spotify
with your friends!'
session: notify_main_thread
session: notify_main_thread
session: login success
session: notify_main_thread
session: notify_main_thread
playlists: 3 playlists at login
playlists: playlist_added: position 0 (34 tracks)
playlists: playlist_added: position 1 (621 tracks)
session: notify_main_thread
session: metadata_updated
playlists: resync GUI
session: notify_main_thread
Segmentation fault
I upgraded from the 20090917 release to 20100209. While the client still does
not like the after effects of hibernation, so far no boom...
I haven't experienced any issues yet with Testify and Ubuntu 10.04, either
with an older release or the latest release. It would seem as far as I can
tell at least the earlier issue on Ubuntu that was causing sound to freeze is
no longer a problem. :-)
Hey, that's good news! I don't want to jinx it, but I've just tried it in
VMware with 10.04 and I didn't have any problems either...