--- Please enter the report below this line. --- Hi folks, All is in the subject. This bug's active either when bb is windowed (no switches) or full console (-width 1300 -height 700 on a 1366x768 LCD). Regards, Jean-Yves Debian Release: jessie/sid 500 unstable www.deb-multimedia.org 500 unstable ftp.fr.debian.org 500 trusty ppa.launchpad.net --- Package information. --- Depends (Version) | Installed =========================-+-=========== libaa1 (>= 1.4p5) | 1.4p5-43 libc6 (>= 2.14) | 2.19-10 libmikmod3 (>= 3.3.3) | 3.3.7-1 oss-compat | 6 Package's Recommends field is empty. Package's Suggests field is empty.
Dear Maintainer,
i have the same problem,
* What led up to the situation?
started bb with sound y
* What exactly did you do (or not do) that was effective (or
ineffective)?
my system uses pulseaudio in user mode which works grate for the most but not for any application, i just installed bb on it using apt-get and startet it.
* What was the outcome of this action?
on this computer it is working until sound starts than the picture freezed. On another computer (running debian 7 (stable) also with pulseaudio) it is running, even if i enable sound, without sound and a littlebit slow. If i chose no at the sound question the picture is working propably (but without sound) i guess that has something to do that the OSS sound interface is used as an real timer which isnt propably working with the alsa/pulseaudio compatiblity layer. On my debian 7 i guess the compatiblity layer isnt working at all.
* What outcome did you expect instead?
sound and moving ascii-art like on the knoppix 5 compact disc i used it long time ago...
thanks for fixing this in advance, that problem is propably not locateted in this package, insted it sould be moved to that compatiblity layer if this is confirmed by someone else..
PS: one thing i miss from windows is the compatiblity mode with windows on windows stuff, that backwards compatiblity on debian gnu/linux has much often problems, very often with sound....
Additional Information:
It looks like the sound is coming on debian testing to the pulseaudio
server directly from bb which is using the mikMod lib. So the problem is
not to be found in compatibility layer of some kind, because it is using
pulse in a native way. So i guess the old bb source code is not
compatible with the new libMikMod...
Some output:
$ pacmd
Welcome to PulseAudio 5.0! Use "help" for usage information.
5 sink input(s) available.
[...]
index: 30438
driver: <protocol-native.c>
flags:
state: RUNNING
sink: 1 <alsa_output.pci-0000_00_1b.0.analog-stereo>
volume: front-left: 39794 / 61% / -13.00 dB, front-right: 39794
/ 61% / -13.00 dB
balance 0.00
muted: no
current latency: 129.50 ms
requested latency: 106.00 ms
sample spec: s16le 2ch 44100Hz
channel map: front-left,front-right
Stereo
resample method: (null)
module: 8
client: 215 <libMikMod client>
properties:
media.name = "libMikMod music"
application.name = "libMikMod client"
native-protocol.peer = "UNIX socket client"
native-protocol.version = "29"
application.process.id = "19262"
application.process.user = "treaki"
application.process.host = "treakis-tp"
application.process.binary = "bb"
application.language = "C"
window.x11.display = ":0"
application.process.machine_id = "7a9a724838671fbefb524d5453b08fe1"
application.process.session_id = "2"
module-stream-restore.id =
"sink-input-by-application-name:libMikMod client"
severity 761023 grave
thanks
I can confirm these report; once the audio kicks in, the ASCII art
freezes.
This renders bb unusable in jessie, so I'm bumping the severity.
Cheers,
Moritz
control: severity -1 important Hi, I have used bb a few times *with* audio, mostly I have used it without. Also bb is used as a nice demo at events, usually without audio. So I'd argue that this bug perfectly fits the description of severity important: "important: a bug which has a major effect on the usability of a package, without rendering it completely unusable to everyone." To prevent removal from jessie I've downgraded the severity accordingly. cheers, Holger
Everyone will use audio by default (most people have a sound card these
days!) so it will crash for everyone unless they dig somewhere in the
BTS and discover this bug.
So at least sound should be disabled by default.
So it should be fixed instead of talked away.
Cheers,
Moritz
Yeah, after the audio starts, timestuff() seems never to return again.
Hi, Moritz Muehlenhoff wrote: Which is IMHO to correct classification... ... because neither this ... ... nor the statement above are true: It doesn't affect "everyone", at least bb works fine with audio here -- with the default settings, i.e. these key presses: bb<Enter> Y 8 This IMHO depends a lot on how many people it affects. But then again, IMHO disabling audio by default doesn't hurt at all. (I'd actually expect that most people actually do disable audio, e.g. to not bother other people while viewing bb. At least I usually do.) Regards, Axel
I did a few extra tests: - bb works fine with the music on the console (no X). - I had the same bug on X. Uninstalling pulseaudio - and rebooting - fixed the issue. - I tried compiling with --disable-libmikmodtest, but video also freezes when pulse-audio is there.
Control: retitle -1 bb: Visual stops when audio starts under pulseaudio Like Axel and Nirgal I can confirm that bb works fine without pulseaudio. Cheers, gregor
Hi, gregor herrmann wrote: I can confirm that I don't have pulseaudio installed. (And this is one more reason for me to continue to avoid it...) Despite my disliking of pulseaudio, I think that a "Conflicts: pulseaudio" is not a good way to "fix" this issue, especially since it seems to work fine on the console even if pulseaudio is installed. Some other ideas come to my mind: * A wrapper script which checks the above mentioned condition (X + pulseaudio) and either warns plus exits or, if possible, just removes all indicators for pulseadio (environment variables or whatever it uses to indicate its present). * Downgrading the bug to "important" again (which IMHO is now even more the most appropriate severity) and adding a paragraph to README.Debian or similar to mention this issue. Regards, Axel
Hi, Axel Beckert wrote: [...] As I have no idea how to check for pulseaudio being active, this is not viable for short-term NMU. I've discussed this with Gregor on IRC and we came to the conclusion that disabling audio by default plus adding the above mentioned warning should suffice to downgrade this issue from RC to important. Due to the Jessie release date being quite close[1] and this being one of the bug reports listed on [2], I plan to do an NMU with the above mentioned characteristics either directly to unstable or at most to DELAYED-1 -- mostly depending on how quickly I manage to get a suitable package. So answer soon if you disagree. [1] https://lists.debian.org/debian-devel-announce/2015/03/msg00016.html [2] https://udd.debian.org/bugs/?release=jessie_and_sid&merged=ign&keypackages=ign&fnewerval=7&flastmodval=7&rc=1&ctags=1&cdeferred=1&sortby=id&sorto=asc&format=html#results Regards, Axel
Hi,
Axel Beckert wrote:
I've just uploaded bb 1.3rc1-8.2 to DELAYED/1. Following is the
reduced debdiff which contains all manual changes. If necessary, I can
also reschedule the upload.
Building the source package always updates config.guess and
config.sub, but I suppressed them from the following debdiff.
diff -u bb-1.3rc1/main.c bb-1.3rc1/main.c
--- bb-1.3rc1/main.c
+++ bb-1.3rc1/main.c
@@ -155,9 +155,9 @@
bbinit (argc, argv);
#ifdef HAVE_LIBMIKMOD
- aa_puts (context, 0, p++, AA_SPECIAL, "Music?[Y/n]");
+ aa_puts (context, 0, p++, AA_SPECIAL, "Music?[y/N]");
aa_flush (context);
- if (tolower (aa_getkey (context, 1)) != 'n')
+ if (tolower (aa_getkey (context, 1)) == 'y')
{
MikMod_RegisterAllDrivers ();
MikMod_RegisterLoader (&load_s3m);
diff -u bb-1.3rc1/debian/changelog bb-1.3rc1/debian/changelog
--- bb-1.3rc1/debian/changelog
+++ bb-1.3rc1/debian/changelog
@@ -1,3 +1,13 @@
+bb (1.3rc1-8.2) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Mitigate hanging visuals in combination with PulseAudio.
+ + Set default answer for Music to "no".
+ + Add README.Debian explaining the situation.
+ + Mitigates: #761023
+
+ -- Axel Beckert <abe@debian.org> Wed, 01 Apr 2015 21:35:03 +0200
+
bb (1.3rc1-8.1) unstable; urgency=low
* Non-maintainer upload.
only in patch2:
unchanged:
--- bb-1.3rc1.orig/debian/README.Debian
+++ bb-1.3rc1/debian/README.Debian
@@ -0,0 +1,14 @@
+BB vs PulseAudio
+================
+
+Unfortunately BB does not work under X if PulseAudio is active and
+Music is requested. If you have PulseAudio installed and want to show
+off BB with Music, you can do that by switching to the virtual text
+console and running BB there.
+
+Due to this issue Music in BB is turned of by default in Debian.
+
+This issue is tracked in the Debian Bug Tracking System at
+https://bugs.debian.org/761023
+
+ -- Axel Beckert <abe@debian.org>, Wed, 1 Apr 2015 22:13:34 +0200
I'll also file an unblock request for that upload soon.
Regards, Axel
Hi, No objections, please go ahead. The diff looks good (though I didn't test the code). Uwe.
Hi Uwe, Uwe Hermann wrote: Will do. Thanks for the acknowledgement and diff review. Regards, Axel
Lowering the severity of #761023 as 1.3rc1-8.2 mitigates this issue
and has just been unblocked for inclusion in Debian 8 Jessie.
Removing the "pending" tag as 1.3rc1-8.2 only mitigates the issue, but
doesn't fix the underlying cause.
Accepted:
Format: 1.8
Date: Wed, 01 Apr 2015 21:35:03 +0200
Source: bb
Binary: bb
Architecture: source amd64
Version: 1.3rc1-8.2
Distribution: unstable
Urgency: medium
Maintainer: Uwe Hermann <uwe@debian.org>
Changed-By: Axel Beckert <abe@debian.org>
Description:
bb - ASCII-art demo based on AAlib
Changes:
bb (1.3rc1-8.2) unstable; urgency=medium
.
* Non-maintainer upload.
* Mitigate hanging visuals in combination with PulseAudio.
+ Set default answer for Music to "no".
+ Add README.Debian explaining the situation.
+ Mitigates: #761023
Checksums-Sha1:
0b5787e587cfd691ee1758c9ce23d579911cca58 1680 bb_1.3rc1-8.2.dsc
8c0680e0231cdf19c97c2324a03e29abd9822b8f 32781 bb_1.3rc1-8.2.diff.gz
29336c4437298f5e8573ae88e0b5647a1c3d29f4 989354 bb_1.3rc1-8.2_amd64.deb
Checksums-Sha256:
8d502c81c3307f271ded45353b7726f98bd214e43e09de641976be72fa344cba 1680 bb_1.3rc1-8.2.dsc
f852c02a99777cc368930c7dbd18259c7975e5009166b7d0b36ce88fbed8b822 32781 bb_1.3rc1-8.2.diff.gz
34287e587df59b8bd9ca8462e0c417064e3e34c72a8d8bc00fc3043cb3603c4f 989354 bb_1.3rc1-8.2_amd64.deb
Files:
df083e5d585c92171023462b2f49c83d 1680 games optional bb_1.3rc1-8.2.dsc
30e15b10b638667c41fe8f0f21add4cf 32781 games optional bb_1.3rc1-8.2.diff.gz
c946d333e5e5351ff0d1f5928576b5aa 989354 games optional bb_1.3rc1-8.2_amd64.deb
Thank you for your contribution to Debian.
----- End forwarded message -----
----- Forwarded message from Niels Thykier <niels@thykier.net> -----
Date: Thu, 02 Apr 2015 16:30:49 +0200
Unblocked, thanks.
~Niels
----- End forwarded message -----
Regards, Axel
Thanks for mitigating this issue, but I wanted to point out the following typo in /usr/share/doc/bb/README.Debian: "turned of" should be "turned off". Best,
If you do a README.Debian update to fix that typo, here is another
thing to add—this makes bb work on my PA system:
pasuspender -- env PULSE_SERVER= bb
pasuspender makes PulseAudio release the sound hardware, then setting
PULSE_SERVER= to blank makes bb not connect to PA (falling back to ALSA
instead, which works).
- -- System Information:
Debian Release: 8.0
APT prefers testing
APT policy: (500, 'testing'), (130, 'unstable'), (120, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)
Versions of packages bb depends on:
ii libaa1 1.4p5-43
ii libc6 2.19-17
ii libmikmod3 3.3.7-1
ii oss-compat 6
bb recommends no packages.
bb suggests no packages.
- -- no debconf information
iEYEARECAAYFAlUoXPIACgkQ+z+IwlXqWf4jhACgisipycEFHwdCVlA1kxQtyW6C
M2wAniiFqSHa+qvDUub6sRTO6bcpleLg
=/Yoz
-----END PGP SIGNATURE-----
Hi Anthony, Anthony DeRobertis wrote: Thanks for that information. I wouldn't have done another upload just because of that typo, but the information you've sent is possible a reason to do another upload. Regards, Axel
Hi, Antoine Amarilli wrote: Thanks for the noticed. Will be fixed with the next upload. Regards, Axel
It makes me wonder; would it make sense, instead of disabling the music by default, to have a wrapper that runs bb with this hack, so that the music can work? (Otherwise the user need to find and read the README to find out about this, which is not ideal...) Of course, the devil is in the details: implementing this solution would require pasuspender, hence pulseaudio-utils; however having bb depend on pulseaudio-utils would be strange as the hack is only needed because of pulseaudio itself. Ideally the wrapper could be smarter and only disable the music when pulseaudio seems in use but pasuspender is not installed, but that's not so easy because bb does not seems to have flags to control the music from the command-line when running it. So I don't know if that's a reasonable idea, but I wanted to make the suggestion.
many PA systems without it. I suppose it might be possible if the system
is using a remote PA daemon, but that's by far not a normal setup.
So you could do something like:
if command -v pasuspender > /dev/null; then
pasuspender -- env PULSE_SERVER= bb
else
bb
fi
Downsides: Anything else playing audio through PA is suddenly going to
go silent.
The PA mixer still works, so things like desktop volume keys should
continue to work.
Hi, Antoine Amarilli wrote: Yes, that idea came to me, too, and may be a valid fix for this bug (which is still open), BUT it's definitely out of scope for the Jessie release. I've also discussed that with Niels of the Release Team and he agrees that anything else than a documentation update is out of scope that close to the release. No, it wouldn't. The fix I'm imagining would be a wrapper script which does the following: * Checking if it runs under X and PulseAudio is active. * If so, use the above mention commandline. * Else just start bb normaly. That would not need any additional dependencies as far as I can see. Regards, Axel
Sure. I was suggesting this in general, I don't know anything about specific milestones. :) Indeed I had missed that pulseaudio depended on pulseaudio-utils, so it's reasonable to assume that pasuspender is available whenever pulseaudio is run and there was no reason to worry. Sorry for the confusion. Your suggestion looks fine to me.
Hi Uwe, I'll soon upload the following debdiff of bb as NMU. Since you agreed with the previous NMU and this is a pure improvement of the README.Debian file I introduced in the previous NMU, and we're very close to the release, I'll upload it directly to unstable. diff -u bb-1.3rc1/debian/README.Debian bb-1.3rc1/debian/README.Debian --- bb-1.3rc1/debian/README.Debian +++ bb-1.3rc1/debian/README.Debian @@ -5,10 +5,18 @@ -Music is requested. If you have PulseAudio installed and want to show -off BB with Music, you can do that by switching to the virtual text -console and running BB there. +Music is requested. Due to this issue Music in BB is turned off by +default in Debian.
Samuel Bronson wrote: > Yeah, after the audio starts, timestuff() seems never to return again. I get the impression that the problem is that it's making the incorrect assumption that running a timer handler is more or less instantaneous. Because if it notices that a timer is lagging behind, it will call the timer handler again and again until it has caught up. See tl_process_group() in timers.c. However, it looks like the timer it creates to call update_sound() will on average take longer than one timer interval to run, when using the PulseAudio driver. In that case, that timer will never ever catch up, and while it's trying to it won't be able to process any other timers in that group. I'm not sure what the proper fix for this is, though. Torbjörn Andersson
Dear Maintainer,
I get the same behavior on an Dell XPS 13 already described in previous report.
I start bb and the demo starts. At the point of time the music starts the ascii
art animation stops.
Without activated sound the animation continous without any problem.
I am using the Gnome standard desktop!
*** Reporter, please consider answering these questions, where appropriate ***
* What led up to the situation?
* What exactly did you do (or not do) that was effective (or
ineffective)?
* What was the outcome of this action?
* What outcome did you expect instead?
*** End of the template - remove these template lines ***