Hi Sebastian,
On Thu, Jun 11, 2015 at 08:19:45PM +0200, Sebastian Reitenbach wrote:
Hi,
didn't got around earlier to try, see below...
On 06/10/15 03:42, Richard Stonehouse wrote:
Hi Sebastian,
I've tested playing MP3s on 32-bit and it seems to be fine (as it was
before on 32-bit).
However, I have another problem, which seems to be 64-bit only. I did
see it in the previous version of Cynthiune (SVN rev 2647) but assumed
it was just another feature of the MP3 bug - but it's still there and
perhaps more consistent.
The following steps reproduce it consistently for me on 64-bit, and do
not reproduce it on 32-bit:
1. Put some files in the Playlist (any type).
2. Play one or more files (any type).
3. Select all the files in the Playlist, using the mouse.
Here I clicked on the first in the list, scrolled to the last
pressed ctrl, and then clicked the last one so that all got highlighted.
4. Click on the 'Remove Selection' button.
I'm unable to reproduce.
When I do that, then all songs disappear, and Cynthiune stops playing.
Aha! should have said - I was trying to remove songs after
Cynthiune had stopped playing, either because it had reached the
end of the playlist or due to clicking the Stop button. I didn't
test the case of emptying the playlist while it was playing - now I
have, that works for me just like it does for you. However,
removing the songs after it has stopped still causes the hang for
me.
Tried on OpenBSD amd64. I compile with
clang, and make use of libobjc2. Otherwise, using all the latest
releases.
What versions of the libraries are you running, and compiler using?
Compiled under GCC 4.8 (on openSUSE 13.2) and using GCC's libobjc1
(which they call libobjc4). I can try clang/libobjc if that would
be helpful but will take a little time to set up.
address@hidden:~> ldd /usr/bin/Cynthiune
linux-vdso.so.1 (0x00007fffd76a3000)
libCynthiune.so.0 => /usr/lib64/libCynthiune.so.0
(0x00007f887a2c3000)
libgnustep-gui.so.0.24 => /usr/lib64/libgnustep-gui.so.0.24
(0x00007f8879a1c000)
libgnustep-base.so.1.24 => /usr/lib64/libgnustep-base.so.1.24
(0x00007f8879213000)
libobjc.so.4 => /usr/lib64/libobjc.so.4 (0x00007f8878ff5000)
libm.so.6 => /lib64/libm.so.6 (0x00007f8878cf4000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f8878adc000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f88788bf000)
libc.so.6 => /lib64/libc.so.6 (0x00007f8878517000)
libicui18n.so.53.1 => /usr/lib64/libicui18n.so.53.1
(0x00007f88780d3000)
libicuuc.so.53.1 => /usr/lib64/libicuuc.so.53.1 (0x00007f8877d51000)
libicudata.so.53.1 => /usr/lib64/libicudata.so.53.1
(0x00007f8877b50000)
libaspell.so.15 => /usr/lib64/libaspell.so.15 (0x00007f887788d000)
libgif.so.6 => /usr/lib64/libgif.so.6 (0x00007f8877684000)
libtiff.so.5 => /usr/lib64/libtiff.so.5 (0x00007f887740f000)
libz.so.1 => /lib64/libz.so.1 (0x00007f88771f8000)
libjpeg.so.8 => /usr/lib64/libjpeg.so.8 (0x00007f8876fa3000)
libgmp.so.10 => /usr/lib64/libgmp.so.10 (0x00007f8876d1c000)
libavahi-common.so.3 => /usr/lib64/libavahi-common.so.3
(0x00007f8876b0e000)
libavahi-client.so.3 => /usr/lib64/libavahi-client.so.3
(0x00007f88768fd000)
libgnutls.so.28 => /usr/lib64/libgnutls.so.28 (0x00007f88765e7000)
libxslt.so.1 => /usr/lib64/libxslt.so.1 (0x00007f88763a7000)
libxml2.so.2 => /usr/lib64/libxml2.so.2 (0x00007f887603c000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007f8875e38000)
libffi.so.4 => /usr/lib64/libffi.so.4 (0x00007f8875c2f000)
librt.so.1 => /lib64/librt.so.1 (0x00007f8875a27000)
/lib64/ld-linux-x86-64.so.2 (0x00007f887a4e7000)
libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007f887571e000)
liblzma.so.5 => /usr/lib64/liblzma.so.5 (0x00007f88754f8000)
libjbig.so.2 => /usr/lib64/libjbig.so.2 (0x00007f88752ec000)
libdbus-1.so.3 => /lib64/libdbus-1.so.3 (0x00007f88750a4000)
libp11-kit.so.0 => /usr/lib64/libp11-kit.so.0 (0x00007f8874e61000)
libtasn1.so.6 => /usr/lib64/libtasn1.so.6 (0x00007f8874c4c000)
libnettle.so.4 => /usr/lib64/libnettle.so.4 (0x00007f8874a1b000)
libhogweed.so.2 => /usr/lib64/libhogweed.so.2 (0x00007f88747ec000)
Do you can compile all objc stuff with debugging information, and
run Cynthiune in gdb and try getting a backtrace when it hangs?
Got it to hang, interrupted (ctrl-C) and typed in 'bt'. Results attached.
I don't really think so, but maybe its a backend problem, do you
can reproduce it with a different audio output backend?
Sebastian
Having killed off pulseaudio, so that the output goes direct to
alsa, I get the same results. However I don't think Cynthiune uses
pulse (should it?) so maybe it was going direct to alsa anyway?
With ESD, I get the same results again. The Cynthiune build says it
has Bundles/Esound.
Cynthiune hangs. It doesn't look like a loop - no CPU is being
consumed. If you double-click on the title bar of the upper Cynthiune
window to shrink the window to title bar only, then double-click again
to re-expand it, the upper window reappears with no content. It isn't
possible to miniaturise the window.
It doesn't go into this state if you omit step 2, playing a file.
It doesn't if, at step 3, you select only some of the files in the
playlist. However it does occur even if there is just one file in the
playlist, and you try to select and then remove it.
I also hit another problem when, while messing about trying to
reproduce
the above, clicking on the 'Next' button crashed Cynthiune. It produced
a lot of output to the terminal - the first bit of this was
lost but the
attached is as much was retrievable. I haven't found a way of
reproducing this again.
On Tue, Jun 09, 2015 at 09:03:03AM +0200, Sebastian Reitenbach wrote:
Hi,
Am 6/9/2015 um 2:52 AM schrieb Richard Stonehouse:
Hi Sebastian,
On Mon, Jun 08, 2015 at 07:15:58PM +0200, Sebastian Reitenbach wrote:
For me on OpenBSD, trying to play any MP3 segfaulted Cynthiune, on
amd64 and on i386.
I exchanged a memcpy with a memmove, and that segfaulting
now was gone
on both platforms.
Afterward, playing that test file, sounds exactly the same for me on
both. It's in SVN now.
Do you can check, whether that might have fixed the noise problem
for you too?
svn co svn://svn.savannah.nongnu.org/gap/trunk/user-apps/Cynthiune
Yes thanks, that fixes it for me on 64-bit. I've tried several MP3s
and they all play fine. Great!
thanks for feedback.
I'll build the 32-bit version and try it again tomorrow - but that
used to work anyway, it would be just a regression test.
At least it works for me, but please let us know. I guess it's time
then for a new bugfix release.
Otherwise, what audio output backend do you use? I use
OpenBSD specific
sndiod. If you still get that noise problem, do you can try another
audio backend?
I'm now using the Pulse Audio server but the same problem occurred
with output direct to alsa.
Yeah, I was also more expecting the input drive to be the problem,
than those getting the music out.
While there I fixed two other minor compilation warnings
also in SVN.
Sebastian
Also attached are the /proc/cpuinfo from both machines.