... we're still alive!


Black Sliver

Member
Joined
Apr 5, 2016
Messages
53
for me the beauty of gnu/linux is about modularity, do one thing at a time and do it right.
That's why it is/should be called systemd/linux -- maybe sometime it will be systemd/uboot with boot-to-systemd ... wait ... why stop there? why not integrate a bootloader into systemd?

Debian people had long conversations on systemd, so did Arch
Afaik (one of the) main reason(s) for this is to unify init "scripts", so a vendor can ship them (instead of the maintainer). The fact that systemd does more than that is the main reason why people hate it.
I have my doubts that systemd is the right choice for OSes targeting more than just desktop:
a) dbus - makes sense on a desktop pc, but not on server or embedded,
b) "permission management" (logind, etc.) makes only sense on desktop, imho. Linux' permission system (groups) works nicely for other use-cases.
c) reduced freedom/increased bloat (you can't just use/take/mix the parts you need/want),
d) not suitable for *all* devices (e.g. IoT, WRT, ...),
e) last but not least: despite the fact that performance should be better (multi-core C vs. single-core bash), it wasn't for a single device for me.
*BUT* since Pyra should be a ready-to-use end-user desktop-like device, systemd may/does make sense for pyra's default OS.

I found Pulse audio to be easier to work with once I came to the realization that it works more or less like a professional sound mixing board that has had half of it's capabilities removed.
It's just not good/ready/bug-free enough. I used it since "day one" when Ubuntu forced it on us. It was really bad back then - but often still better than plain alsa or oss.
Anyway, after that I still had my share of problems with it. Being on Arch (rolling, latest pulse), I can say that it's still full of bugs, at least when mixing sound cards or using network streaming. The main difference to professional sound is the magical buffering system. It will increase buffer size on the go, which introduces delays, which leads to Problem 1: mixing different sound cards may (or will?) increase the buffer to unlimitted sizes (e.g. +1 second delay per minute). I fixed this by using PortAudio against ALSA and just "replaying" a sink to a source and Problem 2: when streaming over network, the delay will randomly increase (bad connection?) but the logic to decrease the buffer size seems to be missing. I found no settings whatsoever to fix this. You have to go through ALSA, manage the buffering youself and hope that PA does not insert a magic buffer (TM) between your ALSA stream and your ALSA (hardware) sink.
Anyway, for most use cases pulse is better than ALSA. The idea is good, but it has too many bugs and limitations. Routing *everything* through userspace and mixing *everything* in software (no hardware acceleration) using self-growing buffers defies the idea of a good, low-delay sound card.
 
Last edited:
  • Like
Reactions: rSl

Plume

Member
Joined
Sep 21, 2015
Messages
121
I would just like to note that most bugs at the beginning of Pulseaudio were due to buggy sound drivers (or whatever PA used) and not Pulse itself.
 

ilo_pona

Still Fresh
Joined
Jul 31, 2015
Messages
16
Not a big systemd (the desktop people have taken over init, wtf year is this?) or pulseaudio fan but if there is a use-case where they would shine, it is a device like this. I've used pulseaudio as a part of WebOS for many years and it has performed well.

I run sysvinit and jack on all my workstations and laptops and could imagine them working well on the Pyra with some effort too though. sysvinit would be better for power consumption. jack is the high end stuff.
 

EvilDragon

Administrator
Staff member
Joined
Mar 4, 2003
Messages
29,718
Age
43
Location
Ingolstadt
Pulseaudio builds on Alsa, so you can also disable Pulseaudio and just use Alsa. It just won't be as comfortable anymore.
 
  • Like
Reactions: rSl

_jr_

Advanced Member
Joined
May 5, 2013
Messages
1,170
I suspect that some ports (e.g. a phone suite) won't run without the pa daemon.
 

Letalis Sonus

Advanced Member
Joined
Mar 5, 2009
Messages
1,472
I suspect that some ports (e.g. a phone suite) won't run without the pa daemon.
I don't know anything that strictly relies on PA, pretty much everything targets ALSA for maximum compatibility or simply uses a backend like SDL that actually leaves you a choice - old OSS-only artifacts should still be a much larger issue.

Actually, what kind of benefit does one even get by directly supporting PA besides skipping a single audio stream redirection? Does its API offer any sort of killer feature or something? It's not like a program that wants to use ALSA instead would put any limit on what the PA daemon may do with its audio stream.
 

fahrstuhl

Member
Joined
May 29, 2008
Messages
371
Age
30
Location
Germany
I don't know anything that strictly relies on PA, pretty much everything targets ALSA for maximum compatibility or simply uses a backend like SDL that actually leaves you a choice - old OSS-only artifacts should still be a much larger issue.

Actually, what kind of benefit does one even get by directly supporting PA besides skipping a single audio stream redirection? Does its API offer any sort of killer feature or something? It's not like a program that wants to use ALSA instead would put any limit on what the PA daemon may do with its audio stream.

Bluetooth headset support with bluez5 seems to depend on pulseaudio.
 

_jr_

Advanced Member
Joined
May 5, 2013
Messages
1,170
I don't know anything that strictly relies on PA, pretty much everything targets ALSA for maximum compatibility or simply uses a backend like SDL that actually leaves you a choice - old OSS-only artifacts should still be a much larger issue.

Actually, what kind of benefit does one even get by directly supporting PA besides skipping a single audio stream redirection? Does its API offer any sort of killer feature or something? It's not like a program that wants to use ALSA instead would put any limit on what the PA daemon may do with its audio stream.

Actually I don't have a clue, but looking at my N900's packages it seems that the voice support is directly integrated into pa (there are also some misc packages that directly depend on the pa daemon, but these may be erroneous).
 

Z-GRADT

Newbie
Joined
Apr 19, 2016
Messages
1
Anything less than 32 GB is a joke. 16 GB might be acceptable *right now*, but how about 5 years from now? My laptop is older than that.
 

Neelix

Insecticidal Maniac
Joined
Jan 8, 2011
Messages
3,264
Location
Melbourne, Australia
A while back I needed to get a microSD card for one of my devices. I figured I'd only need a small one, so I asked for the smallest card they had at the store, which I figured would be 2GB. Turned out the lowest capacity they carried was 8GB. :)

-Neelix
 

WizardStan

Mega GP Mania
Joined
May 24, 2008
Messages
16,733
Anything less than 32 GB is a joke. 16 GB might be acceptable *right now*, but how about 5 years from now? My laptop is older than that.
You realize there are 3 SD slots on it, yes? One internal microSD, and two external full sized SD. 16GB for high speed storage of the OS is more than enough. 4GB would probably be more than enough for the lifetime of the Pyra.
The Pandora only has 512MB and it doesn't suffer under normal use. The actually rare people that need more space for their OS have used SD cards, and on the Pyra that's going to be even easier.
 

slaeshjag

¯\_(ツ)_/¯
Joined
Apr 8, 2010
Messages
2,687
Location
~Stockholm, Sweden
The pandora suffers greatly from only having 512 MB internal storage. Just look at the clusterfuck that is the code::blocks PND. Had we had storage to install those tools properly, things would've been an awful lot better.
 

rygD

Nihilistic Mystic
Joined
Feb 28, 2014
Messages
7,484
Location
Everywhere
Serious question: Is that normal use? I don't mess with that stuff, so it isn't normal for my use, but I don't know what everyone else does.
 
Top