Keep cool!


Re Pulseaudio, it was firefox's insistence that I need to have pulseaudio installed to listed to html5 audio that finally made me go to the effort of installing it. And then after I broke my headphone jack and replaced it using a USB sound card, I first of all fixed the ALSA config to use that card by default, but it turned out pulse audio didn't inherit that config. But in the end I was able to fix that by installing and running pavucontrol, then choosing the usb card on the third tab.

Testing it now, mplayer using alsa gives me a very smooth update of the time progressed so far in playing an mp3, while started with the '-ao pulse' option to use pulseaudio, the display is much less smooth. In terms of the audio, playing a 44.1kHz source file through a presumably 48k only cheap usb card, the two sound more or less indistinguishable through my headphones, and looking at the CPU usage in htop, under ALSA mplayer uses over four times the CPU power than it does over pulseaudio, although in the latter case, the pulseaudio processes are also active - they're using less CPU than mplayer combined though, so in total I reckon it's using less than half the CPU power. Using a speech based podcast instead, it looks as if mplayer uses even less power under pulseaudio, but about the same under ALSA. I might end up configuring mplayer to use pulseaudio by default at this rate!
 
Brütal Legend on the other hand works perfectly fine with ALSA if you simply use the native Linux client - why are you using Wine for that?

I keep my games on a networked storage drive. As I've always had really good luck with Wine, if there's a Windows version of a game I tend to install that instead (unless of course it has issues with Wine I cannot solve). The reason being my girlfriend uses Windows 7 on her PC because League of Legends via Wine is not smooth enough in Linux, and League of Legends is 75% of her computer gaming. Since she's always booted into Windows it makes sense to have the Windows versions of games (like Brutal Legends) that work well in Wine installed, over the Linux versions that don't work at all in Windows. So we can both play those games at will in any OS.

If only Windows supported Linux versions of games.
 
During my adventures with Linux, I found PulseAudio problematic in one case: Configurability. Command-line tools don't list all options when they should, and sound output is usually set to wrong (at least in Dells). Nice configuration offered by pavucontrol is incomprehensible (I have to check "as spare" to use my output as primary in all applications - logic anyone?) and result is not saved. Configuration made by command-line tools likes to reset between reboots, so the only thing I found working is to mess with files in /etc.
On the other hand, PulseAudio allows to transform these universal sound i/o in a handy and quite documented way if only sound card is supported. And vibration motor may be driven with some modulation, so maybe it's a channel of the DAC?
Ha! I had the same issue, which happened to be on a dell machine when I first tried out debian:
Fixing sound in Debian - Master Mono muted on boot
 
I've actually had a laptop where if you were just using ALSA you had to go in and tweak configuration files to get it to use the right sound device by default, but if you installed PulseAudio, it just worked. PulseAudio has improved quite a bit since Poettering moved on to other projects (systemd) and someone else took over maintaining it. Poettering and company seem to only be concerned about adding features, when it comes to bug-fixing they tend to not care. If it works for them, it works; everything else is an 'edge case.'
 
Which begs the question, why does there stuff still get adopted?
It's because they are really good at advertising. They create software to solve some real or perceived problem, and are good at getting the right people (Distro maintainers) on board.

Despite it's flaws, PulseAudio did actually solve some problems and made some things much easier.
Systemd really isn't that bad to use, I written a couple daemon processes in it. (I disagree with the massive scope creep and some of the devs attitudes). It's easy to forget that there have been many different projects that have tried to fix or improve on init.d. They just happened to have a convincing design and were able to get enough distros on board.
 
I think, I'll always blame systemd for not being able to get anyone but myself interrested in finding the cause for my inability to boot into manjaro after one update. That was me for the first time making a serious attempt at switching to linux ending up having a full blown windows experience.
So, either its on systemd, that no-one could be bothered to investigate deeply, or the manjaro crowd is basically another windows crowd. I prefer to go with poetterware is evil shit.
 
Systemd really isn't that bad to use, I written a couple daemon processes in it.
That's probably because you didn't understand the problem with it. I do like it myself - as the simple startup service concept it originally wanted to be. But that's not what systemd is today, that's just one tiny little bit of it. The big issue is the crapload of useless things added ontop of it, in addition to Poettering's legendary mindset towards issues that are not supposed to exist.
 
well i'm glad we can turn almost any thread into arguments against PA and systemd. maybe we should have some more personal attacks on poettering? just to cement things, real nice.
 
Will these be produced before August or not?
Well, I don't know myself yet.
They should be, the slot is planned, but I haven't heard exactly when (as I certainly need to inspect them before mass production!)
Do you mean you expect the cases to be produced in July or do you mean before the end of August?
_____________________

@EvilDragon Your updates are hugely appreciated of course but if you could find the time to give an overview of the prototyping process it would be much appreciated.

I'd love to know :

How many prototypes are there?
Who has got them?
What are the main goals for the prototype phase? My guess is : OS Software polishing, Hardware bug Hunting, Solving the 4GB issue, Dealing with heat. Have I missed any major goals?
 
Do you mean you expect the cases to be produced in July or do you mean before the end of August?
_____________________

@EvilDragon Your updates are hugely appreciated of course but if you could find the time to give an overview of the prototyping process it would be much appreciated.

I'd love to know :

How many prototypes are there?
Who has got them?
What are the main goals for the prototype phase? My guess is : OS Software polishing, Hardware bug Hunting, Solving the 4GB issue, Dealing with heat. Have I missed any major goals?

I assume he means before the factory shuts in August, which will probably be early in the month, so before the end of this month ideally (but that's getting tighter by the day), or as stated, before August.

FWIW, we've had photos and reports from two devs thus far; ptitseb and askarus. Maybe more have outed themselved in IRC; I've not been checking.

And as far as I know, hardware and software pretty much covers everything ;) But yeah, hardware fixes including the 4GB fixes if needed have got a deadline already in the first post, and other than that software fettling and seeing if it can be made to run faster for longer are the only remaining design tasks I think.
 
Systemd really isn't that bad to use, I written a couple daemon processes in it. (I disagree with the massive scope creep and some of the devs attitudes).

Sorry, but I have to get this off my chest:

<rant>
How systemd works has almost nothing to do with my "hate" towards it.

Soon after it was released and Arch adopted it, I thought it was cool and tried to port it to sabotage linux. (The only musl libc based distro at the time. Alpine hasnt switched yet at the time.)
It wasnt long before I discovered that they used very glibc specific things in systemd that prevented it from being used with any other libc. You would have to rewrite core portions of systemd to make it work.

To make matters worse, systemd started to "assimilate" other services too.
Thankfully the gentoo folks performed micro surgery to extract a working udev from systemd and it is known as eudev today https://wiki.gentoo.org/wiki/Eudev

So basically systemd takes away your freedom to use another libc and who knows what other services that they assimilated.

So, why should we care about another libc ?
The great guys behind musl-libc has gone to great lengths to make a non-bloated, correct and standards compliant libc.
If you are a moderate to advance linux user, you should take Alpine linux for a spin and see for yourself.
For me there are beauty in the simplicity. Everything just works the way you expect without stuff being hidden behind the scenes.
The openrc init system they are using (also borrowed from gentoo) is a joy to use.

All the docker fans will also tell you why you should care about the ability to use another libc. They also started to adopt musl for all its great qualities. Some people report a 10x reduction in bloat.
</rant>
 
Last edited:
Back
Top