Debian Bug Report for quodlibet
-
@Sebastian Dröge said:
since SVN revision r4027 quodlibet's source code is personally insulting me, probably as reaction of Debian bug #421167 which was caused by a mistake on my side:
..snip..
- "file:///Sebastian/Droge/please/choke/on/a/bucket/of/cocks", ""):
A bit of "this isn't serious" and "yes, it is", including:
@Bastian Kleineidam said:
This is bad style, and it even could result in a law suit brought upon the Debian project.
Followed by:
@Julien Cristau said:
No, this can't result in a lawsuit against Debian, please take your bullshit elsewhere, kthxbye.
Credit to morbiuswilters for pointing this one out.
-
Heh. Good read.
-
Quod Libet: The only music player in existence that is powered entirely by Internet drama.
-
that would show up if you were, say, logging filesystem access...
TRWTF is the state of audio on linux.
-
@WWWWolf said:
Quod Libet: The only music player in existence that is powered entirely by Internet drama.
Ha, good one!
-
@zipfruder said:
that would show up if you were, say, logging filesystem access...
Yeah. Some of the commenters in the bug report seem to miss the distinction that not only is there a difference between merely insulting a program that doesn't work and making ad hominem attacks at a contributor, no matter how misguided that contributor may be... but there's a huge difference between doing so merely in comments and doing so in actual compiled, running code. O_o
-
@zipfruder said:
TRWTF is the state of audio on linux.
People keep telling me that, but I haven't had a problem with audio on Linux this decade. (And even then, it was only an annoying pause when the first application tried to play audio). I listen to music, watch videos (with audio), flash games, etc. all without any kind of audio issues. Can somebody please tell me what the big problem is supposed to be?
-
@mallard said:
@zipfruder said:
TRWTF is the state of audio on linux.
People keep telling me that, but I haven't had a problem with audio on Linux this decade. (And even then, it was only an annoying pause when the first application tried to play audio). I listen to music, watch videos (with audio), flash games, etc. all without any kind of audio issues. Can somebody please tell me what the big problem is supposed to be?
You're either running one of the rare soundcards that supports hardware mixing, or you've never had two OSS-based applications try to produce sound at the same time. The problem is the large number of standards for sound on Linux (I'm aware of half a dozen), and the lack of interoperability and concurrency support.
-
@Carnildo said:
You're either running one of the rare soundcards that supports hardware mixing, or you've never had two OSS-based applications try to produce sound at the same time. The problem is the large number of standards for sound on Linux (I'm aware of half a dozen), and the lack of interoperability and concurrency support.
Been buying your weed from Swampy again? There's only one sound standard for Linux: the best one. Sound on Windows is this jumbled mess of proprietary code and Microsoft lock-in. You think MS wants you to able to listen to any sounds through your speakers? This is a convicted monopolist we're talking about. It has been shown time and time again that Windows has intentional flaws built-in to degrade the quality of non-M$ sounds. Bowl of custard splattering on tile? You can't tell me that's what it's supposed to sound like. Now listen to the sheaf of notebook paper twisting as a gentle breeze enters through a cracked window. You hear the difference? You can't tell me the difference in fidelity is purely a result of acoustics.
-
@morbiuswilters said:
@Carnildo said:
You're either running one of the rare soundcards that supports hardware mixing, or you've never had two OSS-based applications try to produce sound at the same time. The problem is the large number of standards for sound on Linux (I'm aware of half a dozen), and the lack of interoperability and concurrency support.
Been buying your weed from Swampy again? There's only one sound standard for Linux: the best one.
Are you merely ignorant, or smoking buttcrack? Just from memory, I'm aware of OSS and ALSA as low-level layers. They're semi-compatible: if you're running OSS, you can't run ALSA apps, and a single app can lock all others out from playing sound; if you're running ALSA, an OSS app can lock everyone else out from the sound card. High-level layers include aRts, JACK, ESD, Asound, OpenAL, SDL, NAS, and PulseAudio, and they are not mutually compatible. aRts, for example, acquires exclusive access to the sound card -- any other app must either output through it or wait until it's finished. JACK's extreme low-latency requirements can cause sound from other systems to stutter. NAS and PulseAudio suffer from the latency problems that any network sound system does. I haven't used ESD in a while, but it used to have a horrible network security system that would randomly prevent applications from playing sounds.
Sound on Windows is this jumbled mess of proprietary code and Microsoft lock-in. You think MS wants you to able to listen to any sounds through your speakers? This is a convicted monopolist we're talking about. It has been shown time and time again that Windows has intentional flaws built-in to degrade the quality of non-M$ sounds. Bowl of custard splattering on tile? You can't tell me that's what it's supposed to sound like. Now listen to the sheaf of notebook paper twisting as a gentle breeze enters through a cracked window. You hear the difference? You can't tell me the difference in fidelity is purely a result of acoustics.
Sound on Windows may be a mess, but it works, with no though on the part of the user. As an application designer, you can pick the audio API of your choice, and you can count on the sound you produce making it to the speakers, within a reasonable amount of time.
-
@Carnildo said:
Are you merely ignorant, or smoking buttcrack?
Are you blind, or do you just not read the tags?
Seriously, WTF.
-
As I was reading that I kept hoping that the next post would be
"Someone seems to have made a checkin with this comment: Randomly changed all variable names in file xxx to piss off that fucktard xxx caz he don't like my jokes..."
I was dissapointed.
<lame>
@Carnildo said:
Are you merely ignorant, or smoking buttcrack?
</lame>
-
@Carnildo said:
Are you merely ignorant, or smoking buttcrack?
Quod Libet: The only music player that can cause massive tangential flamewars wherever it goes.
@Carnildo said:
They're semi-compatible: if you're running OSS, you can't run ALSA apps, and a single app can lock all others out from playing sound;
I think with proper hardware and drivers OSS also does hardware mixing. It's been a really long time since I used OSS, though, but I have vague memories of having a perfectly working hw mixing on an Audigy2 card (which never got ALSA drivers, by the way).
@Carnildo said:
if you're running ALSA, an OSS app can lock everyone else out from the sound card.
Funny, that doesn't seem to happen to me - just tested by running Amarok (ALSA) and madplay (OSS) at the same time and they cooperate just fine. The only time snd-pcm-oss froze on me was when I was recording something years and years and years ago...
@Carnildo said:
JACK's extreme low-latency requirements can cause sound from other systems to stutter.
It's probably because it's currently optimised for high-end cards and tweaking the settings for consumer models is probably painful. I have an oldish SBLive! card and I've yet to find the perfect settings for it. =) But anyway, JACK's real forté is with audio routing between different apps; using it for audio playback is a bit excessive in my opinion, because ultimately JACK just talks to ALSA. I don't leave jackd running unless I'm using apps that actually benefit from it (i.e. running stuff from fluidsynth to ardour, etc). There's a wonderful frontend called qjackctl that can be used to start/stop/control jackd.
-
@WWWWolf said:
Funny, that doesn't seem to happen to me - just tested by running Amarok (ALSA) and madplay (OSS) at the same time and they cooperate just fine. The only time snd-pcm-oss froze on me was when I was recording something years and years and years ago...
Doesn't ALSA have an emulation layer for OSS to prevent locks done by OSS?
-
Wow, I never expected to start such an awesome flamewar with that. Carnildo, it was obviously a joke, but I guess the best of us can be duped. Seriously, "bowl of custard splattering on tile"? Did you read that and think "that son of a bitch, the acoustics of splattering custard sound fabulous on Windows!"
-
@morbiuswilters said:
Wow, I never expected to start such an awesome flamewar with that.
I thought it was quite brilliant.
-
@morbiuswilters said:
Did you read that and think "that son of a bitch, the acoustics of splattering custard sound fabulous on Windows!"
But it's true, the acoustics on Windows are crystal-clear. They get quite muddy on tiles, though.
-
@Lingerance said:
@WWWWolf said:
Funny, that doesn't seem to happen to me - just tested by running Amarok (ALSA) and madplay (OSS) at the same time and they cooperate just fine. The only time snd-pcm-oss froze on me was when I was recording something years and years and years ago...
Doesn't ALSA have an emulation layer for OSS to prevent locks done by OSS?I haven't used OSS recently, so things may have changed in the past year or so, but in the past, it depended on which emulation layer the app used. If it accessed /dev/dsp directly, it would block all other applications; if it was run by the "aoss" wrapper, ALSA mixing would work properly.
-
In any case, it's been fixed.
220 220 if gst.element_make_from_uri( 221 221 gst.URI_SRC, 222 "file:///Sebastian/Droge/please/choke/on/a/bucket/of/co cks", ""):222 "file:///Sebastian/Droge/please/choke/on/a/bucket/of/cookies", ""): 223 223 return GStreamerPlayer(pipeline, librarian) 224 224 else:
-
@Carnildo said:
I haven't used OSS recently, so things may have changed in the past year or so, but in the past, it depended on which emulation layer the app used. If it accessed /dev/dsp directly, it would block all other applications; if it was run by the "aoss" wrapper, ALSA mixing would work properly.
"/dev/dsp directly"? I thought /dev/dsp is accessed pretty much directly by any OSS application, and you don't need any extra wrapper programs for that. I thought the whole point of ALSA's OSS driver was to emulate /dev/dsp for the apps that still need that junk, and it has never ever failed for me. You're not supposed to load both ALSA and OSS at the same time (I don't know if that's even possible); either use pure OSS or use ALSA + ALSA's OSS emulation.
$ grep "OSS" /boot/config-2.6.24-1-686 ... CONFIG_SND_OSSEMUL=y CONFIG_SOUND_OSS=m ... $ lsmod ...
(Despite of the lack of above-mentioned Debian's crazy decision to build a kernel with OSS drivers as modules in 2.6 era, we should observe the conspicuous lack of the module "sound" here)
... snd_pcm_oss 38272 0 ... snd_mixer_oss 15296 1 snd_pcm_oss snd_seq_oss 29472 0 ...
That's all I've need in the past half a decade or so.
Then, let's play some stuff...
$ madplay 'ruaste - c64.mp3'
...and see the amazing consequences...
$ lsof /dev/dsp ... COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME madplay 21152 wwwwolf 4w CHR 14,3 71065754 /dev/dsp
See - it's accessing /dev/dsp directly, without any other wrapper-stuff, and causes no lockups whatsoever!
-
-
-
So what happens if I have a file at /fake/path/for/gst?
#477454 - Insulting source code - Debian Bug report logs
