2015-01-05 15:44 GMT+01:00 Brent Busby <brent(a)keycorner.org>rg>: ​alsa is there​ and compiling a kernel it's not that hard https://www.freebsd.org/ports/audio.html ​they don't have a port for ardour3​ yet ​apt-get purge pulseaudio systemd apt-get​ install sysvinit /raffaele

On Tue, 6 Jan 2015 18:32:11 +0100 Ralf Mardorf <ralf.mardorf(a)rocketmail.com> wrote: I ended up running on Arch for a lot of the reasons people choose BSD - I can eliminate a lot of the extraneous packages that always seem to go with most other distros, especially Fedora, which I used for a long time. The ability to never install pulseaudio was the tipping point for me. [ snip ] I've been a UNIX/Linux administrator longer than some folks on this list have been alive. systemd has always seemed like a solution to a problem that didn't really exist, and causes more issues than it solves, especially when it comes to kernel logging. That said, it seems to be the way of the future, and I don't despise it to the level others do, or as much as I hate pulseaudio. I have run FreeBSD servers in the past (and may again), but it was never under consideration when I dropped Fedora because to me it doesn't seem to be the right tool for the job. -- ====================================================================== Joe Hartley - UNIX/network Consultant - jh(a)brainiac.com Without deviation from the norm, "progress" is not possible. - FZappa

On Tue, Jan 6, 2015 at 5:15 PM, Brent Busby <brent(a)keycorner.org> wrote: This is ridiculous.

On January 6, 2015 04:21:45 PM Brent Busby wrote: I think PulseAudio is a masterpiece. When I discovered just how deeply and intimately it deals with hardware I was impressed by its breadth and scope. Having said that, well, I still find it a little weird and unusual, a bit hard to follow what it does, how it works, and how to use it and get the most out of it. But it's there and just works, for desktop audio. But I am a "Jack head" after all, like a lot of us... PS: Does anyone know if there are plans to do PA midi? Thanks. Tim.

On Wed, 7 Jan 2015 17:26:28 -0800 (PST) Len Ovens <len(a)ovenwerks.net> wrote: Why do you use PA as intermediate layer at all? You could just route all alsa programs to jack. Alsa at least does what it should instead of doing weird things on its own. [rant] There is this telephony program called jitsi. On Linux it can either use Portaudio or Pulseaudio. The portaudio implementation is broken, after a few minutes everything goes silent and you have to reboot to get sound going again. So I installed Pulseaudio for the sole purpose of running this program. What pulseaudio did was really weird. Every time a call came in it set the mic volume to maximum. It did not just set some software volume level, no, it did set the hardware levels, the same stuff you see in alsamixer. Of course it ignored anything the user had set there, PA is the boss after all. On a machine with intel audio chip that meant that it not only sets all levels to max, it also sets the 'mic boost' to max, causing horrible distortion. So when the call started the person on the other end was, at the start of every call, blasted with a wall of noise. Hurray for clever programs that know what the user wants and 'just work'. [/rant] Philipp

On Thu, 8 Jan 2015, Philipp Überbacher wrote: Just? Just routing all programs to alsa means each or any blocks all others. One ends up with the mess that at least three audio servers have been tried of which Pulse seems to be the one that has been chosen exactly As is portaudio itself. (IMO) Did you read what I wrote before? It would seem not, easier to rant. Use Jack as the audio device and this will never happen. Really, The best audio setup is to use pulse as a front end for jack for any program that does not deal well (or at all) with jack. I agree the pulse/ALSA interface is less than great, but the front end that pulse shows the applications is about the best there is. Jack on the other hand works really well with alsa, but lots of apps have chosen not to work well with jack (it does not seem hard to deal well with jack), so use each for what it is good at. I do look for applications that will deal directly with jack first. The choices in VoIP all seem to work best with Pulse though. (Skype being the big one) -- Len Ovens www.ovenwerks.net

On Thu, 8 Jan 2015 06:10:03 -0800 (PST), Len Ovens wrote: ^^^^^^^ ;) -- Guerilla Open Access Manifesto: https://archive.org/stream/GuerillaOpenAccessManifesto/Goamjuly2008_djvu.txt

On 8 January 2015 at 15:10, Len Ovens <len(a)ovenwerks.net> wrote: I keep seeing people say this, but I have never noticed any program blocking the sound of any other. I can play sound from mplayer, audaciuos, audacity, firefox, whatever, all at the same time, never had pulseaudio installed, everything through alsa. What am I doing wrong? :p

On 8 January 2015 at 17:49, Paul Davis <paul(a)linuxaudiosystems.com> wrote: a) How do I figure out about it b) Doubt it, it's an onboard chip on an Intel motherboard from 2008. (Have a separate card for jack/audio work).

On Thu, Jan 8, 2015 at 12:27 PM, Brent Busby <brent(a)keycorner.org> wrote: it never worked at the device driver level. ALSA only ever did mixing in userspace via dmix, which works *most* of the time but is not reliable enough in the general case. it isn't super hard to find the corner cases that will cause dmix to goof. old school consumer audio used to involve hardware level mixing, but this started dying out in the very early 2000's and is now completely gone. all devices now assume software is used to mix streams.

On Wed, 07 Jan 2015 01:57:54 +0100, Ede Wolf wrote: I used Xfce for my FreeBSD install and tested KDE using PcBSD. There wasn't a difference to Linux, but it took several days to compile everything from ports. I guess today there isn't the need to build everything from ports. However some things, e.g. audio productions with a desktop computer aren't the focus of FreeBSD. They care more about security, by separating "world" from "user space", by providing jails. Rt abilities are completely unimportant. JFTR pulseaudio nowadays is part of FreeBSD too, it wasn't a while back. -- Guerilla Open Access Manifesto: https://archive.org/stream/GuerillaOpenAccessManifesto/Goamjuly2008_djvu.txt

Haven't used Gnome since 1.4, so I could not comment on this. Had an occasional look on its developement, alway got sick, and went back. YMMV, of course. Come on, that was so obvious that I tought a smily was really not needed here at all. Sorry, if you got this wrong

Resume: FreeBSD can't replace a Linux audio production environment. A last note from me regarding systemd: On Wed, 7 Jan 2015 09:42:40 +0100, Raffaele Morelli wrote: The majority of users don't know Torvalds words, but they experienced that one or the other systemd upgrade caused fatal issues. They experienced additional issues when trying to fix issues using journalctl. They experienced completely idiotic changes for defaults on a system that was stable for years, e.g. when eth0 was renamed to enp3s0. The resume is that it caused 100s of little, fixable issues, so you needed to fix a install that was stable before. Several admins know Torvalds words and often agree with him, but the reason that they are against systemd is that they lost functionality, there's no way to get back what they need, at least not that easy as it can be done for our desktop computers, were most problems can be fixed by working a few days. The averaged *buntu replaced Windows user won't notice a difference between SysVinit, Upstart and systemd, but many power-users who set up their machines to their individual needs and work-flows at least from time to time have to spend a few hours to fix systemd issues. Sometimes, when there e.g. was the endless disk checking with each startup, users who don't shutdown their machines, couldn't notice such an issue. The problem is that systemd sometimes tries to fix some odd ideas from the time before we used systemd, but this likely does cause backwards incompatibility, so the user needs to fix it or to completely change her/his work-flow. Usually people don't dislike systemd to fake coolness and wisdom, they experience everything from little annoyances to serious issues and that's why they are against an attitude, not against systemd per se. PS: JFTR I don't separate systemd from udev and from journalctl etc.. ^^^^^^^^^^ I need to correct my previous claim. I'm confusing two different fsck issues that appeared at the same time. IIRC endless fsck issue wasn't caused by systemd, but IIRC another fsck issue was and at least troubleshooting wasn't easy. However similar things not that seldom happen, there only is the need to follow mailing lists of distros that use systemd. Btw. discussions about systemd were censored at some Linux mailing lists, but not at the FreeBSD list: Gnome2 -> Gnome3 - no way "It is worth noting that Gnome3 was a massive change to Gnome2. It has been slightly less controversial than systemd, but only slightly." - http://lists.freebsd.org/pipermail/freebsd-questions/2015-January/263472.ht… ^^^^^^^^^^^^ Such a statement on some Linux mailing lists still easily could result in insults and warnings from list moderators. -- Guerilla Open Access Manifesto: https://archive.org/stream/GuerillaOpenAccessManifesto/Goamjuly2008_djvu.txt

On Wed, 7 Jan 2015 12:49:12 +0100, Raffaele Morelli wrote: After a systemd upgrade it mounts your disk read-only after fsck. So editing was required. Use mkinitcpio fsck hook and rw on the kernel commandline or don't use the hook and ro on the kernel commandline. There also was the systemd-213 bug https://bugs.freedesktop.org/show_bug.cgi?id=79576 When I follow stable releases from upstream I expect backwards compatibility and no serious bugs. You can't blame users, when upstream has got the attitude not to care about different set ups and work-flows. In addition I already gave several examples, however, I dislike to continue this discussion. I likely use a real systemd environment longer than you do. Perhaps Debian doesn't use it's hybrid systemd anymore and switched to a real systemd too. Anyway, the "attitude" not to care about "noobs" or different needs has nothing to do how long we use a real systemd environment from upstream, if we experienced no or much issues. Some people (not a minority) experience/d much issues. I heard even from people who like systemd, that they dislike journalctl. If you like too, I could ask a group of people, including admins, to invite you to an off-list mailing group against systemd. I'm the only Arch user, the others are Debian users. -- Guerilla Open Access Manifesto: https://archive.org/stream/GuerillaOpenAccessManifesto/Goamjuly2008_djvu.txt

On 01/07/2015 02:36 AM, Ralf Mardorf wrote: My encounters with systemd haven't been positive. I have one system now running Debian Sid (Debian 8). Debian has switched to systemd in Sid. Shutdown time before the switch: ~30 seconds. Shutdown time AFTER the switch: 5 minutes. I guess they're still working on systemd. -- David W. Jones gnome(a)hawaii.rr.com authenticity, honesty, community http://dancingtreefrog.com

On Wed, 7 Jan 2015 12:49:12 +0100 Raffaele Morelli <raffaele.morelli(a)gmail.com> wrote: Hi Raffaele. As far as I know Debian switched only very recently. Ralf is using Arch, and so do I. I did not look it up, but I think Arch switched to systemd about two years ago, so we have a lot more experience and were involuntary early adopters. In many respects, in everyday operations, systemd just works, but so did sysvinit. It is just that everything works differently now, and if you run into problems it can be a pain to figure out what is wrong. There is a lot less documentation on the net, and by that I mean stuff that helps with troubleshooting common problems, not the systemd documentation itself. In addition, systemd is a moving target, so what might have worked half a year ago may no longer apply. On top of that, many Arch people seem to have adopted a potterian attitude over the last few years. You can be sure to be scorned at, you may get a solution, but you won't get a proper explanation of the cause of the problem or its solution. I did have some concrete problems. The journal seems to be quite a mess. The only reliable thing about it is that it does not work when you need it the most. Years ago I had some issue with system freezes or crashes and the logs contained nothing. I reported the bug and they changed something so that the log gets written more often. Recently I had another system freeze, and guess what I found in the logs? The full half hour leading up to the freeze was completely empty. Nothing. Nada. Not a single line. How are you supposed to debug something if the logs are empty? It is not that much better with small problems. There was one thing I did using a systemd service file, of course according to the information from the Arch wiki, because without that I would be completely lost. I am rather (but not completely) sure it worked properly, for months. Recently I noticed that it did not work as expected, the program that was started through the service file crashed reliably when it absolutely should not. The only thing in the logs was that the service failed because it was killed by systemd. End of information. Completely useless. Someone in the Arch forums did help me (without explanation), a small modification in the service file solved the issue, but I still don't know whether the program changed, systemd's behavior changed or it never worked correctly in the first place. All I know is that systemd killed the program. Guess how much fun it is to figure out why the heck it did that. How about another grieve? Have you ever tried to figure out the configuration of some service? Now with systemd you no longer have just configuration files, no, you have configuration directories. Not just one. For every single service you may have multiple files in multiple directories with some sort of precedence system that you may be able to figure out if you find the correct man page. Have fun figuring out the configuration. Arch used to be simple, you could configure most system level stuff using two files. And of course there is the more general stuff, like stupid binary logs and that they put everything plus the kitchensink into systemd. I just now found out that systemd in the meanwhile contains a somewhat cron-like thing called timers that is not quite a cron replacement but is probably, directly or indirectly, involved to the system freeze I described above. I know far less about my system than ever before. But at least the gnome users are happy, I guess. I do not see any noteworthy benefit. Regards, Philipp

On 08/01/15 at 01:00am, Philipp Überbacher wrote: "Years ago I had"... just like, "once upon a time" What are you talking about? What's this thing you did? <sarcasm>is it a secret between you and the Arch wiki ? </sarcasm> What's the matter with multiple configuration files? Have you ever jumped into eg. /etc/apache2/ ? or /etc/postgresql/*/main/ ? Come on... There's nothing wrong with binary logs if you can read them. I don't want to dig into this again but this is just another vague post with very unclear points or at least they can be placed in the "software development workflow" ie. coding -> testing -> finding bugs -> fix release -- «My mama said to get things done You'd better not mess with Major Tom» D.Bowie

On 6 January 2015 at 20:04, Joel Roth &lt;joelz(a)pobox.com&gt; wrote: None of the packages you mention depend on systemd as it is, so maybe you just need to move to a "liberated" distro.

On Tue, 6 Jan 2015, Ralf Mardorf wrote: All I see on the web page from the OP is the Alsa libraries and packages for the Alsa tools (user space stuff). I still don't see where you can actually put Alsa itself into your kernel and get yourself beyond OSS style sound and its /dev/dsp mentality. For some of the nicer audio cards (from RME for example) with lots and lots of inputs, that would be really nice. (See the state of FreeBSD audio here, especially their progress on trying to create an Envy24 driver: https://wiki.freebsd.org/Sound) So FreeBSD will give you OSS-style drivers in the kernel, and no realtime. It's impressive that they've done the work necessary to get Ardour to run in that environment (and sort of work), but it still makes me ask...why? Until there are some improvements in their kernel, it makes about as much sense as trying to run Ardour on Solaris/sparc. The solution I'm using is offered by Gentoo -- eudev. They've forked the udev codebase from before the introduction of systemd as a necessary dependency, and they've been merging in changes and updates ever since. If you run Gentoo, you can install eudev and totally free yourself from systemd. It'd be nice to see the other distros start picking eudev up as well. They also let you turn off PulseAudio support in a $USE flag, so that nothing on your system will even look for the libraries because nothing will be compiled for it. -- + Brent A. Busby + "We've all heard that a million monkeys + Sr. UNIX Systems Admin + banging on a million typewriters will + University of Chicago + eventually reproduce the entire works of + James Franck Institute + Shakespeare. Now, thanks to the Internet, + Materials Research Ctr + we know this is not true." -Robert Wilensky

On 06/01/15 at 09:02pm, Robin Gareus wrote: Yes, I saw references here and there to 3.5 beta also. I'll have a try with the guest os anyway. regards /raffaele -- «My mama said to get things done You'd better not mess with Major Tom» D.Bowie

On Tue, 06 Jan 2015 23:06:12 +0100, Ede Wolf wrote: On Tue, 6 Jan 2015 15:58:44 -0600 (CST), Brent Busby wrote: There's a RME HDSPe AIO driver available. It does work with all analog and all SPDIF and ADAT IOs, but IIRC with jackd only stereo pairs were available, not all IOs at the same time. IIRC there was no way to adjust latency, the latency always was very high, perhaps 171 ms or similar. TotalMIx (hdspmixer) wasn't available. OTOH on Linux using hdspmixer for the RME HDSPe AIO only ADAT 1+2 are available by jackd, but at least the other IOs, e.g. the analog IOs are available at the same time when using jackd. On Tue, 6 Jan 2015 16:21:45 -0600 (CST), Brent Busby wrote: RedHat yes, Lennart Poeterring no, he's "just" annoying regarding to his comments. The fundamental attitude is a problem. "So this really really doesn’t make me want to ever work with Kay Sievers, because this all just reinforces the fact that he just doesn’t care if his changes cause other projects pain. In the kernel, we have that “no regressions” rule for a damn good reason. For example, it is not a valid excuse to say “well, user space shouldn’t have done that to begin with, so now we can break it”. But Kay seems to think that breaking other peoples workflow and uses is fine. And is totally unapologetic about it, and closes bug reports when it happens, and dismisses the obvious and reasonable fix." - Torvalds And this attitude became a fashion, even for maintainers and coders of other distros, when e.g. backwards compatibility gets broken within major releases and then coders and maintainers argued that other software is broken. But indeed Poettering released pulseaudio too soon and blamed ALSA drivers that worked without pulseaudio, for not working with pulseaudio.