On Sat, Jan 28, 2012 at 12:35 AM, G. Schlisio wrote:

Am 28.01.2012 00:26, schrieb G. Schlisio:

...

Hi all, i used to keep a folder in /media to serve as mountpoint if some manual mountis was needed. since some days, this folder disappeared, even if created again. is there any change in filesystems, kernel or whatsoever changing behavior there, is it intended (if so, why?) or a bug? every hint appreciated.

If you are using initscripts this should not happen. If you are using systemd it should. The justification being that /media is meant for ephemeral mount points (i.e. stuff created by udisks et al.). -t

On Fri, Jan 27, 2012 at 5:56 PM, Fons Adriaensen wrote:

Wouldn't most users associate /media with cd, dvd etc. ? Seems like on odd name for what systemd uses it for.

for as long as i remember anyway, the DE will often mount stuff there automatically, ergo it's not safe to put manual mount points there. /mnt is specifically reserved for admin, so /mnt/media is safe. under systemd, /media is a tmpfs. -- C Anthony

On Fri, Jan 27, 2012 at 8:39 PM, Heiko Baums wrote:

Am Fri, 27 Jan 2012 19:41:54 -0600 schrieb C Anthony Risinger :

...

On Fri, Jan 27, 2012 at 5:56 PM, Fons Adriaensen wrote:

...

Wouldn't most users associate /media with cd, dvd etc. ? Seems like on odd name for what systemd uses it for.

for as long as i remember anyway, the DE will often mount stuff there automatically, ergo it's not safe to put manual mount points there. /mnt is specifically reserved for admin, so /mnt/media is safe.

This is not true. If this is what some DEs are doing, than you should file a bug report to the DE's upstream.

well ... gnome3 is doing it right now, and IIRC kde4 did as well, been quite awhile since i used that though. i want to say xfce did it too ... but it's been even longer since i used that. this functionality is provided thru udisks/dbus, and it seems perfectly reasonable to me.

...

under systemd, /media is a tmpfs.

The same for systemd.

the same what? file a bug? systemd does this because the mounts/directory structure are ephermal. there may be other reasons i'm unaware of, but i don't see a problem.

There's a Linux Filesystem Hierarchy Standard which says that /media is meant for removable media and /mnt is for temporarily mounted filesystems. Whatever the difference between an optical media and a temporary filesystem may be.

http://www.pathname.com/fhs/pub/fhs-2.3.html#MEDIAMOUNTPOINT

yes i'm quite familiar with the FHS, and have read the spec in depth, as packaging/deployment is of great interest to me. while my own designs take the FHS into consideration, there is no reason to believe their are not better schemes, esp. consideration the current age of virtualization and usage patterns. IMO at least, the document is clearly outdated, and i've read more than once that the maintainers are non-responsive to requests for amendment/alteration.

I know that Lennart Poettering doesn't care much about Linux standards and likes to declare his non working crap as standard. But fortunately he is not a standardization authority.

So if a software doesn't follow those FHS you should file a bug report to upstream.

well, i can't say i care much about the FHS either. IMO, systemd/pulseaudio work fantastic, and are orders of magnitude better than their predecessors, and only move the ecosystem forward. i also make extensive use of avahi/libnss-mdns/libnss-myhost ... soooo, they seem to work OK ;-) there are many contributors to these projects ... he's not a one-man band.

And yes, /media is supposed to contain subdirectories for cd, dvd, etc. Nevertheless /media was also invented by SUSE in the past, because originally those optical media was also meant to be mounted to subdirectories of /mnt. Nevertheless meanwhile FHS was changed to include /mnt as well as /media for whatever reasons.

i see no reason to include those directories unconditionally, nor any reason to avoid alternatives. -- C Anthony

OT: PulseAudio On Sat, 2012-01-28 at 14:02 +0100, Heiko Baums wrote:

...

IMO, systemd/pulseaudio work fantastic, and are orders of magnitude better than their predecessors, and only move the ecosystem forward. No, PulseAudio doesn't work fantastic, it's pure crap as long as it can't handle every sound and audio card, which ALSA, btw., does

Am Fri, 27 Jan 2012 21:21:01 -0600 schrieb C Anthony Risinger : perfectly out-of-the-box.

And, no, artificially crippling a (semi-)professional audio card down to stereo with a strange ALSA configuration is not a solution for this.

The majority of Linux users on non-audio Linux mailing lists praise PA, OTOH as soon as they run into trouble regarding to PA, the Linux "pro-"audio users will help them to fix it, usually it's not that majority of users who praise PA, giving the needed hints. I always had issues with PA and I never had an issue when I replaced PA by dummy packages, but seemingly there's a work flow by a majority of Linux users, where having PA installed is an advantage. You might take a look at Debian users mailing list. On KDE4 PA is using 2% CPU already when doing nothing. For some people using 2% for nothing isn't a bug, it's ok for them.

And why should I trust other software by [someone] if he isn't able to get this one software working perfectly.

Why should I trust that a musician is a good drummer, when she's a bad guitarist? Perhaps because she's a drummer ;). - Ralf

2012/1/28 Heiko Baums :

Am Sat, 28 Jan 2012 15:29:33 +0100 schrieb Ralf Mardorf :

...

The majority of Linux users on non-audio Linux mailing lists praise PA, ...

And the most computer users use Windows. So what's the point? That doesn't mean that Windows is better than Linux or that Windows works perfectly.

I'm sure that most Linux users just use their stereo or maybe surround SoundBlaster like or onboard AC'97 sound card and not a (semi-)professional audio card.

For those people PulseAudio may work, but that doesn't mean that it really works, because they just don't see all the flaws. And it definitely doesn't work with those ice1712 cards. And I've seen a lot of discussions in Linux and IT forums where PulseAudio absolutely wasn't praised, where most users said that it is crap or at least unnecessary, because of the missing hardware support, and because most of the features are already done by ALSA itself out-of-the-box.

...

I always had issues with PA and I never had an issue when I replaced PA by dummy packages, but seemingly there's a work flow by a majority of Linux users, where having PA installed is an advantage.

You might take a look at Debian users mailing list. On KDE4 PA is using 2% CPU already when doing nothing. For some people using 2% for nothing isn't a bug, it's ok for them.

So you see, that some people just don't care, maybe because they don't know better. I would call those 2% buggy and a waste of resources. Another reason not to using PulseAudio.

...

Why should I trust that a musician is a good drummer, when she's a bad guitarist? Perhaps because she's a drummer ;).

This comparison is flawed. A guitarist wouldn't go on stage and drum, if he can't drum, and vice versa. But Lennart writes a software for something he at least doesn't know enough about (PulseAudio) and tries to have this declared as standard, and at the same time writes another software (systemd), which also has several issues or is at least not really compatible with existing systems or script as far as I know, instead of first fixing the first one, so that it really works. And then he thinks he has to get involved in other things at the same time. This is something completely different, and this is what I'm worried about.

If he would do one thing and would really try to fix its issues and he would really try to learn how to fix them, I wouldn't say much. But I don't see this. So how should I trust him and his software if he gets himself involved in several different things if he's not able to do the one and even the other thing correctly?

Heiko

Does this really need to be rehashed yet again? This isn't arch related yet these PA back and forths keeps popping up in the mailboxes of all the registered people looking for arch-related content. I didn't follow the original discussion so I cant argument on that extent, but the last thing we need on this list is more noise.

On Sat, Jan 28, 2012 at 11:34 AM, Heiko Baums wrote:

If Lennart would either fix all those issues in PulseAudio and systemd, so that they would really work for everybody and would really bring advantages for everybody or at least no disadvantages, or if his software would just be optional and not needed as a dependency by some distros or DEs, I'm pretty sure this discussion wouldn't always pop up again.

dear Lennart and co., the community would appreciate software that is 100% free of all bugs, now and forever. we expect these things to work with every card ever manufactured, even stuff 10yrs obsolete or in the 1% of use cases. and no, before you ask, just working is not good enough, please be sure that all possible features are exposed. also, ensure your software integrates perfectly with legacy systems and perfectly with future systems that haven't been thought of. lastly, after achieving completely awesome and 150% interoperability (must include future), make sure that your software is 100% optional and free of dependencies in either direction. seriously, if you can't hit this entry-level 3rd grade target, there is no hope of becoming a l33t linnicks developer, and you should right fuxxor off, guy. signed, Your Friends in the Community ...... haha, i make myself laugh, that's all that really matters. is this roughly message you want to send? both PA and systemd already do a pretty good job coping with legacy stuff, in two areas that are *notorious* for their excessive proliferation ... you seem to have some basic misunderstandings of ALSA/alsa-lib/init ... you do know that init doesn't actually do *anything*, right? i reimplemented init in ~40 lines of bash years ago for LXC containers ... and it was full-featured, supporting all signals, and even inittab. that shiz was unfixable garbage imo. i think if you read a bit more ... eg. man pages, documentation, introductory blogs/etc, and not rants by random-equally-infuriated users ... you may find some reason, and *maybe* even some use. ftw, PA idles at 0% CPU for me, and when streaming over the network to an XBMC sound system, it uses a steady average 1-2% (actually brief intermittent bursts at 10% or so) ... nothing outrageous ...meanwhile, FF consumes 3-5% to run flash, and flash consumes 8-10% to run Pandora ... PA is the lightest link in the chain. ... and that's a wrap on this topic, for me that is. -- C Anthony

Am Sat, 28 Jan 2012 12:37:14 -0600 schrieb C Anthony Risinger :

is this roughly message you want to send?

No, this is not the message, and I guess you totally misunderstood me. The problem is that PulseAudio is not working with every sound and audio card, but users are forced to install it as a dependency by some distros and/or DEs, even if it doesn't support several audio cards. And the problem is that this leads to being called PulseAudio as a standard even if it doesn't support a lot of sound and audio cards, so that sound probably wouldn't work with those cards some day. And the problem is upstream's reaction on bug reports about this, that they say something like "it's ALSA's fault that our software doesn't work with your audio card" even if ALSA supports these card perfectly out-of-the-box, etc. So to me it just sounds like "We want our software to be a standard but we just don't care about hardware we don't understand, and we just ignore it." That are the problems. Like I said before, if PulseAudio was just another piece of software which I can install or not, I totally wouldn't care about it. But as soon as someone forces me to installing this, I do care. Well, I'm currently using Arch Linux and Xfce. So I'm not, yet, forced to install it. But I'd like to keep it this way.

i think if you read a bit more ... eg. man pages, documentation, introductory blogs/etc, and not rants by random-equally-infuriated users ... you may find some reason, and *maybe* even some use. ftw, PA idles at 0% CPU for me, and when streaming over the network to an XBMC sound system, it uses a steady average 1-2% (actually brief intermittent bursts at 10% or so) ... nothing outrageous ...meanwhile, FF consumes 3-5% to run flash, and flash consumes 8-10% to run Pandora ... PA is the lightest link in the chain.

I didn't say anything about PulseAudio's CPU usage. That was someone else. I just answered that 2% CPU usage at idle time would be too much. Actually I don't know how many resources it needs. Heiko

Am Sat, 28 Jan 2012 11:24:47 +0100 schrieb Tom Gundersen :

Maybe I (or others) were unclear in our explanations, but at least you should have had a look at the software you are claiming to be buggy (you would quickly see that there is no problem).

Again, PulseAudio which Lennart Poettering likes to have as a standard completely doesn't work with (semi-)professional audio cards with an ice1712 chip. Yes, I had a look at PulseAudio. And as I already asked previously, why should I believe that his other software really works if he's not able to get that one software working. And, yes, there are incompatibilities in systemd. As far as I read there are a lot of initscripts which don't work with systemd and therefore have/had to be rewritten to get them working with systemd. Where's the bug? In the scripts or in systemd?

This is what all DEs I'm aware of have been doing for a long time. They create mountpoints and mount removable media under /media, which is perfectly in line with the FHS.

If they create a subdirectory under /media it's indeed corresponding to the FHS.

"Whatever the difference [...] may be", this should give you a hint that there is something you are missing...

Then explain it to me. An optical drive is also only mounted temporarily. I don't see a difference between mounting a harddisk temporarily or mounting a dvd temporarily. Maybe you can explain the difference.

Please stop this nonsense. First of all, the way in which /media is (and has been) used has nothing to do with Lennart. Secondly, the FHS has not been breached in this instance. Thirdly, anyone who knows anything about these matters agree that the FHS is outdated and needs to be rewritten (and that until it is, we should not care too much about it).

So let everybody invent their own directory scheme, because FHS is so called outdated so that every Linux distribution and every Unix derivate is totally incompatible with each other? Right, great idea! What about first rewriting the FHS first to make it up-to-date again and only then using this new FHS? Until then the FHS should be fully respected. And why doesn't have "anyone who knows anything about these matters" updated this FHS, yet? Because "anyone who knows anything about these matters agrees that the FHS is outdated and needs to be rewritten"? Come on, if this was really true then the FHS would have already been rewritten by those guys. So this is nonesense. And, btw., I don't see any point in which the FHS doesn't work anymore. But maybe you can explain this, too.

This is a waste of time. The upstream developers are well aware of the FHS. If their apps violate it, it is intentional.

Wrong again, it's not intentional, it's buggy. It was intentional if the FHS would first be rewritten and the upstream developers would then follow the new FHS. Heiko

Am Sat, 28 Jan 2012 15:09:30 +0100 schrieb Tom Gundersen :

Have you tried after this fix was released: http://git.alsa-project.org/?p=alsa-lib.git;a=commitdiff;h=d3906a93072171e5b...?

Like I've written in another e-mail in this thread: And, no, artificially crippling a (semi-)professional audio card down to stereo with a strange ALSA configuration is not a solution for this. And, no, it's not ALSA's fault like Lennart Poettering says, it's PulseAudio's fault. This is what is done by this fix. But those (semi-)professional audio cards with an ice1712 chip aren't SoundBlaster like stereo sound cards for playing some games. They work completely different, because they have several separate channels which can be mixed however you want (of course to normal stereo, too, but not only). Look at the only working mixer for this card, envy24control in alsa-tools (or alsa-tools-ice1712 from AUR), to get a clue. It's sort of a clone of the original mixer and patchbay of the Windows driver for these cards. Or search for documentation of these cards. The problem is, that Lennart Poettering and the other PulseAudio guys don't know anything about these cards. There's also an upstream bug (I don't have the URL to hand), which was indeed closed as fixed with a reference to this commit. Since this is not a fix and not even a workaround I reopened the bug report and never got an update of this bug, yet. So, no, as long as the PulseAudio developers don't know enough about sound and audio and as long as they don't support every sound and audio card in the way those cards are supposed to by the hardware developers and the users, it's just crap, and definitely not a candidate for being a standard. ALSA can handle every sound and audio card including the ice1712 cards perfectly out-of-the-box without such a strange configuration.

Dunno. Depends on the bug. Point me at it and I'll fix it wherever it is.

I'm not using systemd and never will until Arch Linux switches officially to it. But it was already announced that this will most likely not happen. I guess there are good reasons for this decision.

The different usecases of /media and /mnt are explained in the FHS link you provided.

I don't see any difference there. Optical media contain a filesystem and harddisks contain filesystems. Both are usually mounted temporarily. So what's the difference?

Nope. We are working with the other distros to make things more uniform, not less. In my humble opinion doing this work within the framework of the FHS is not very effective. Coding by committee seldom works.

If this is really done this way it's OK. But somehow I still have my doubts. But I'm open to conviction. My impression recently was that there are a lot of people doing and inventing a lot of things on their own which has almost nothing to do with any Linux standards, particularly again Lennart Poettering, and that some other distros just take Lennart's ideas without thinking about it, while other distros don't do this, etc. And you know what I still think of Lennart.

The things that are agreed upon are being added to the next version of FHS, but I guess things are not done in the order you would prefer.

If this will indeed happen, then it's OK for me. Still I have some doubts. Heiko

Am Sat, 28 Jan 2012 17:05:25 +0000 schrieb Fons Adriaensen :

PA is for 'consumer' use, its scope ends at ITU 5.1 or so. It doesn't support any serious multichannel card (like the the comlete RME series, up to 64+64 channels). Users of such cards don't need or want PA, so it's really not a problem at all.

That's principally what I said. The problem is that several distros and DEs like Gnome depend on PulseAudio as far as I know. This is what I'm concerned about. Arch Linux and Xfce, what I'm using, fortunately don't depend on it. If PulseAudio was generally only optional and if its developers wouldn't try to declare it as a standard, I just wouldn't care.

If you use such cards you probably have Jack running, and if you really want PA you can configure it as a Jack client.

I'm using an M-Audio Audiophile 24/96, so one of the cheapest semi-professional audio cards of this kind. And I admit I primarily use it for listening to music, watching videos etc. because of its sound quality. But you're right I don't want and need PulseAudio. Heiko

Am Sat, 28 Jan 2012 17:34:32 +0000 schrieb Fons Adriaensen :

It's part of a more general trend, that of dependencies on specific desktop junk trickling down into even basic system components and plain apps.

And that's a problem. This should be changed again.

And it's staring to affect Arch as well, be it much less than some others.

The Arch devs fortunately try to avoid this trend as good as possible. I hope they can keep it up. And I hope that other distros and upstream developers will rethink soon. Heiko

On Sat, 2012-01-28 at 13:14 -0600, Leonid Isaev wrote:

Please please please not again!!!

PA is a great consumer thing, and that's exactly what we need. Because noone cares about "pro" audio solutions which are a nightmare to configure.

PA goes far beyond you KDE/gnome to embedded systems with android and webos. Having different volume controls for different ergimes is very handy there.

The discussion would stop once and for all, if there would simply be a dummy package available by the repositories of all the distros who make PA a dependency. Neither the OP nor I have started this discussion on several other lists, where it was a thread some days ago. All the time there are averaged non-pro-audio users having trouble with PA. And now I shut up, Ralf

Thanks. On Sat, Jan 28, 2012 at 11:29 AM, Ralf Mardorf wrote:

...

Please please please not again!!!

PA is a great consumer thing, and that's exactly what we need. Because noone cares about "pro" audio solutions which are a nightmare to configure.

PA goes far beyond you KDE/gnome to embedded systems with android and webos. Having different volume controls for different ergimes is very handy

On Sat, 2012-01-28 at 13:14 -0600, Leonid Isaev wrote: there.

The discussion would stop once and for all, if there would simply be a dummy package available by the repositories of all the distros who make PA a dependency.

Neither the OP nor I have started this discussion on several other lists, where it was a thread some days ago. All the time there are averaged non-pro-audio users having trouble with PA.

And now I shut up, Ralf

Am Sat, 28 Jan 2012 13:14:47 -0600 schrieb Leonid Isaev :

PA is a great consumer thing, and that's exactly what we need.

That may be exactly what you need, but not what we need. Otherwise we all could stick with Windows. You can read your e-mails and write some letters with Windows. So why using Linux?

Because noone cares about "pro" audio solutions which are a nightmare to configure.

I don't need to configure anything to get my M-Audio Audiophile 24/96 to get running perfectly with ALSA. And all the pro audio software work without any configuration out-of-the-box with this card and ALSA. What's not working with this card is PulseAudio, and to get it working with PulseAudio somehow I need to cripple it down to stereo with a nightmare of configuration. Heiko

On Sat, 2012-01-28 at 20:25 +0000, Fons Adriaensen wrote:

On Sat, Jan 28, 2012 at 01:14:47PM -0600, Leonid Isaev wrote:

...

PA is a great consumer thing, and that's exactly what we need.

PA is indeed a great consumer thing, and it may be what you need. It is definitely not what some others need.

...

Because noone cares about "pro" audio solutions

You mean _you_ don't.

...

which are a nightmare to configure.

Very strange that you claim to have some knowledge on something you don't care about. Which 'pro' audio HW have you actually used ? On what experience is is your 'nightmare to configure' comment based ?

Having used a significant percentage of what is available, and earning my daily pizza by providing services and consultancy mostly based on Linux audio using 'pro' HW, I can only say that your comment is pure nonsense.

I need to chime in here. (Hard to shut up) After some conversation off list I agree that a dummy package provided by the repositories might be a less good idea. But I noticed some lacks of knowhow. E.g. it's not a problem for a classic Jack only. Cards as the Envy24 ones (the OP already tried to explain this) or the RME (Fons already mentioned it) already don't work with PA. So if even software like GDM depends to PA (it might be a dependency of a dependency), it's ridiculous. Of cause, it's possible to use another login manager, but someday too many apps might depend on PA, that don't need PA. The different "solutions" to turn off PA often don't work. "autospawn = no" might work for Arch Linux, but AFAIK some distros still kept disadvantages of PA when using this. Cheers, Ralf

On Sat, 2012-01-28 at 18:30 +0100, Tom Gundersen wrote:

On Sat, Jan 28, 2012 at 6:05 PM, Fons Adriaensen wrote:

...

If you use such cards you probably have Jack running, and if you really want PA you can configure it as a Jack client.

For what it's worth, PA and Jack have a protocol to peacefully coexist. So, if you use Jack, even if PA is installed and running, PA will move out of the way and everything should "just work".

-t

Sorry, I can't be quiet, because this isn't true. Audio in for my RME HDSPe AIO worked, but audio out didn't work. I had to replace PA by a dummy package for my Arch Linux install. Even after pulseaudio --kill nothing changed. Btw. sometimes I'm using my RME card without Jack, but ALSA only. Why should I use Jack to listen to YouTube? - Ralf

On Jan 29, 2012 3:29 AM, "Tom Gundersen" wrote:

On Sat, Jan 28, 2012 at 7:59 PM, Ralf Mardorf wrote:

...

On Sat, 2012-01-28 at 18:30 +0100, Tom Gundersen wrote:

...

For what it's worth, PA and Jack have a protocol to peacefully coexist. So, if you use Jack, even if PA is installed and running, PA will move out of the way and everything should "just work".

Sorry, I can't be quiet, because this isn't true.

It should be possible, though I don't use Jack, so this is all I know:

http://trac.jackaudio.org/wiki/JackDbusPackaging

-t

It is true, using jack 2 and pulse. Lots of hear say and too little actual knowledge in these sort of threads... "Alsa works perfectly for me, pulse doesn't, it sucks and its maintainer has a secret agenda against all Linux pros...."

On Sun, 2012-01-29 at 10:46 +0100, Ralf Mardorf wrote:

On Sun, 2012-01-29 at 07:22 +0800, Oon-Ee Ng wrote:

...

On Jan 29, 2012 3:29 AM, "Tom Gundersen" wrote:

...

On Sat, Jan 28, 2012 at 7:59 PM, Ralf Mardorf wrote:

...

On Sat, 2012-01-28 at 18:30 +0100, Tom Gundersen wrote:

...

For what it's worth, PA and Jack have a protocol to peacefully coexist. So, if you use Jack, even if PA is installed and running, PA will move out of the way and everything should "just work".

Sorry, I can't be quiet, because this isn't true.

It should be possible, though I don't use Jack, so this is all I know:

http://trac.jackaudio.org/wiki/JackDbusPackaging

-t

It is true, using jack 2 and pulse. Lots of hear say and too little actual knowledge in these sort of threads... "Alsa works perfectly for me, pulse doesn't, it sucks and its maintainer has a secret agenda against all Linux pros...."

Are you a professional audio engineer using Linux audio? You're using Jack DBus? For what kind of productions? What setup do you use?

Even if Jack DBus should be ok for my needs, it's uneconomic to switch back from familiar setup. ^^^^ away (English isn't my native language ;)

A lot of people need to switch from GNOME to Xfce, not because of PA, since PA easily can be replaced by a dummy package, but because of other bad changes. You can't do such hard changes of the work flow in a professional environment from one day to the other, when several people are involved.

FWIW I'm jobless at the moment, but my life career is audio and video engineer for around 30 years, from small studios to world famous companies. I might have less knowledge about Linux, but I know about professional audio work flow.

Comments like you makes a majority of engineers use Apple and Windows for pro-audio, while Linux would be the better choice, if there wouldn't be such issues and comments like yours.

Regards,

Ralf

On Sun, 2012-01-29 at 18:13 +0800, Oon-Ee Ng wrote:

On Jan 29, 2012 5:46 PM, "Ralf Mardorf" wrote:

...

On Sun, 2012-01-29 at 07:22 +0800, Oon-Ee Ng wrote:

...

On Jan 29, 2012 3:29 AM, "Tom Gundersen" wrote:

...

On Sat, Jan 28, 2012 at 7:59 PM, Ralf Mardorf wrote:

...

On Sat, 2012-01-28 at 18:30 +0100, Tom Gundersen wrote:

...

For what it's worth, PA and Jack have a protocol to peacefully coexist. So, if you use Jack, even if PA is installed and

...

...

...

...

...

will move out of the way and everything should "just work".

Sorry, I can't be quiet, because this isn't true.

It should be possible, though I don't use Jack, so this is all I know:

http://trac.jackaudio.org/wiki/JackDbusPackaging

-t It is true, using jack 2 and pulse. Lots of hear say and too little actual knowledge in these sort of threads... "Alsa works perfectly for me,

running, PA pulse

...

...

doesn't, it sucks and its maintainer has a secret agenda against all Linux pros...."

Are you a professional audio engineer using Linux audio? You're using Jack DBus? For what kind of productions? What setup do you use?

Even if Jack DBus should be ok for my needs, it's uneconomic to switch back from familiar setup.

No I am not, if I was I'd be ashamed to be criticizing a project without first getting my facts right.

...

A lot of people need to switch from GNOME to Xfce, not because of PA, since PA easily can be replaced by a dummy package, but because of other bad changes. You can't do such hard changes of the work flow in a professional environment from one day to the other, when several people are involved.

FWIW I'm jobless at the moment, but my life career is audio and video engineer for around 30 years, from small studios to world famous companies. I might have less knowledge about Linux, but I know about professional audio work flow.

Yes, why not generalize when a specific example is debunked? I'm sure all Linux installs MUST be ready to use out of the box for professional audio users. after all, the same is true for the other operating systems.

...

Comments like you makes a majority of engineers use Apple and Windows for pro-audio, while Linux would be the better choice, if there wouldn't be such issues and comments like yours.

No one here has claimed Linux to be the better choice (opinion) because systems are tools, not ideologies. Linux comes with disadvantages and advantages, in the case of audio you have choice (just like you can replace coreaudio on Macs, right), which comes at the cost of having to actually maintain your system and not expecting it to always work the same way.

Just use windows and Apple already, Linux's pro audio is Jack, it is NOT ootb friendly (that's why is "pro"), and pulse does not change that. You're just looking for something to rant about related to Lennart, I think.

...

Regards,

Ralf

I never said anything against Lennart. I don't know him, I even didn't know that he has to do with PA, before Heiko or who ever it was has written about him. Why this assumption? Again, I never rant against Lennart! Quote any rant I have done! I claim that Linux is the best choice to go for pro-audio. Where didn't I get the facts right? Again: Do you know about problems when using Jack DBus? Have you ever used it? You might search the LAD and LAU archives before you claim, that I don't get the facts right. Regards, Ralf

On Sun, Jan 29, 2012 at 11:50 AM, Ralf Mardorf wrote:

...

...

I'm sure all Linux installs MUST be ready to use out of the box for professional audio users. after all, the same is true for the other operating systems.

I just ask that upgrades don't break a working machine, caused by unneeded dependencies. If a studio used GNOME, than an upgrade shouldn't add PA and break the machine. Only add dependencies if they are needed. PA isn't needed, it's optional. If upstream add it, it might be allowed to explain, why it isn't good to do so.

Sounds like possibly valid concerns. But this is not something to discuss here. Please contact gnome and/or pulseaudio if you have issues. We just package their software, we don't decide their priorities or policies. And I think this discussion has gone on for way too long... -t

On Sun, Jan 29, 2012 at 02:46:37PM +0100, Heiko Baums wrote:

This has already been tried at least with pulseaudio. Their reactions are known. Blame ALSA for PA's faults while ALSA supports those card perfectly since years, and crippling those audio cards down to stereo with some very strange ALSA configs, because PA's upstream just doesn't have the knowledge about those cards and about pro-audio.

They *DO* know and understand the difference between consumer and 'pro' audio. PA just isn't meant for the latter. I wonder what your problem is. There is no audio production software I know of that uses or depends on PA. It's going to stay that way. So _it doesn't matter_ if PA doesn't support your soundcard. I'd even say it's a good thing that PA stays away from anything 'pro'. Ciao, -- FA Vor uns liegt ein weites Tal, die Sonne scheint - ein Glitzerstrahl.

On Sun, 2012-01-29 at 11:06 -0400, Norbert Zeh wrote:

Fons Adriaensen [2012.01.29 1442 +0000]:

...

On Sun, Jan 29, 2012 at 02:46:37PM +0100, Heiko Baums wrote:

...

This has already been tried at least with pulseaudio. Their reactions are known. Blame ALSA for PA's faults while ALSA supports those card perfectly since years, and crippling those audio cards down to stereo with some very strange ALSA configs, because PA's upstream just doesn't have the knowledge about those cards and about pro-audio.

They *DO* know and understand the difference between consumer and 'pro' audio. PA just isn't meant for the latter.

I wonder what your problem is. There is no audio production software I know of that uses or depends on PA. It's going to stay that way. So _it doesn't matter_ if PA doesn't support your soundcard. I'd even say it's a good thing that PA stays away from anything 'pro'.

I just posted a comment in this thread, observing that the problem is not pro-audio vs non-pro-audio hardware. The difference is between hardware that works and hardware that doesn't work, and the latter most certainly includes distinctly non-pro hardware that works great with ALSA but not with PA.

Cheers, Norbert

At least one user pointed out that he's using an Envy24 card, but he isn't using audio production software. He only use such a sound card to get better sound quality, than consumer crap will produce. Btw. a wise decision, a Hifi CD player is more expensive, than an Envy24 sound card, that at Ebay are available at around 30,-€. The other point is, that more and more depends to PA, even if it's unneeded. Comparable to Emacs depending to ConsoleKit. When will stop those dependency issues? Will Firefox become a dependency for leafpad next week? At the beginning of this discussion I pointed out, that most averaged desktop audio users on mailing lists are comfortable with PA, as long as they don't get issues, but once they run into PA related troubles, then they need some good advice. Cheers, Ralf -- Really hard to shut up :(.

On Sun, Jan 29, 2012 at 10:02:25PM +0100, Heiko Baums wrote:

Am Sun, 29 Jan 2012 14:42:33 +0000 schrieb Fons Adriaensen :

...

They *DO* know and understand the difference between consumer and 'pro' audio.

I have another impression.

Could be. My impression is based on talking with LP face to face. And yours ?

...

I wonder what your problem is. There is no audio production software I know of that uses or depends on PA. It's going to stay that way. So _it doesn't matter_ if PA doesn't support your soundcard. I'd even say it's a good thing that PA stays away from anything 'pro'.

I didn't say anything about pro-audio software, I've spoken about DEs like Gnome 3 and some distros which want to have PA installed as a dependency and probably don't work anymore without PA. If this is or at least will be the case then also the pro-audio software won't work anymore with those.

I fully agree that designing Gnome or KDE so they can't be installed easily without PA by a user who accepts the consequences of doing so (no desktop sounds) is a sign of *very crappy* engineering. OTOH, if you use one of those desktops you can just suspend PA, start Jack and your apps and go on. I don't use Gnome or KDE, I don't have PA installed so I can't talk from experience. But I know that people are doing this all the time. For example Joern Nettingsmeier, who is probably using the most complex and advanced pro audio setups ever done in Linux, apparently has no problem with this. Ciao, -- FA Vor uns liegt ein weites Tal, die Sonne scheint - ein Glitzerstrahl.

On Sun, Jan 29, 2012 at 11:17:38PM +0100, Heiko Baums wrote:

My is based on a bug report, upstream's solution for closing this bug report - this weird ALSA configuration which cripples those cards to pure stereo cards - and their response to the reopening of this bug report.

The ALSA 'route' device doesn't cripple the card, it just reduces it to what PA is able to use. Even if PA would accept the card with its full channel count there are no PA enabled apps that could all those channels, and that's probably a good thing. Just imagine PA venturing into 'pro audio' territory - that would be a real disaster. -- FA Vor uns liegt ein weites Tal, die Sonne scheint - ein Glitzerstrahl.

On Sun, Jan 29, 2012 at 4:12 PM, Jan Steffens wrote:

You seem to possess the misconception that the existence of PA on a system is somehow in conflict with pro-audio software.

It's true that professional users typically make some compromises to have the best system for audio. But.. not using PulseAudio isn't really a compromise, one is not losing anything. There are other kind of examples. Professional musicians are not interested in battery file but in a system with realtime preemption tuned for performance. There is no joy in a long battery life with lots noises coming out of the speakers... Not for most of them at least. PulseAudio is even worse. It does not work at all for professional sound cards and professional audio software. What's the point to have it, since it's a complex and buggy system and you can have exactly the same features using alsa, jack and alsa-plugins? Professional audio system with low latency requires other set of priorities. Arch is filling this need as far as I see. One can set such a system very easily. But some care is wise to keep things simple, including not enforcing the use of useless heavy tools.

Heiko Baums [2012.01.29 1446 +0100]:

Am Sun, 29 Jan 2012 11:58:31 +0100 schrieb Tom Gundersen :

...

Sounds like possibly valid concerns. But this is not something to discuss here. Please contact gnome and/or pulseaudio if you have issues.

This has already been tried at least with pulseaudio. Their reactions are known. Blame ALSA for PA's faults while ALSA supports those card perfectly since years, and crippling those audio cards down to stereo with some very strange ALSA configs, because PA's upstream just doesn't have the knowledge about those cards and about pro-audio.

Maybe I'm not the best to explain the concepts of those audio cards, but that doesn't mean that I don't know anything about them. When I bought this card it took me a while until I got to know what they are doing and how they work, so maybe I can't explain it in detail. But that doesn't mean that I'm missing anything.

...

We just package their software, we don't decide their priorities or policies.

But you and the developers of the other distributions are the people who decide if they just want to package what upstream thinks should become a standard. So if every distribution just install PA as a dependency then nothing will change and a very big regression regarding audio will happen, because PA will indeed become a standard, and no pro-audio user will be able to hear and work with sound anymore. If the distros refuse to package those bad software dependencies, then also upstream probably has to change their minds.

So I think this has to be discussed with downstream, too.

...

And I think this discussion has gone on for way too long...

Think about it again. Think again why this discussion about PA always pops up on every occasion in almost every mailing list and forum. Rethink if pro-audio users really have no knowledge about the underlying concepts. I bet pro-audio users have a lot more knowledge than PA upstream and all the people who claim that pro-audio users are missing something.

I'm sure that this discussion will always pop up until these issues regarding PA are fixed. That said, it will end if either PA will fully support those audio cards and show that they learned about (pro-)audio or if PA wouldn't be installed as a dependency anymore by upstream as well as by downstream of all distros and just be treated as a normal and optional piece of software which can but doesn't need to be installed and used.

Let me chime in here to add an important point to this discussion. The whole discussion so far sounds as if PA works great with non-pro cards and breaks only on pro cards. That's not the case: PA has problems even with what is probably the lowest end of chips: built-in audio chips on all my motherboards. And the behaviour I observed is exactly what Heiko and Ralf observed too: everything works great with ALSA and starts to act up when using PA. Things I observed (on Ubuntu, Mint, openSUSE, Arch...so it's not distro-specific) were way too low input (mic) and output volumes even when setting the volume controls to 100%. I really wanted to use PA because it offers something ALSA does not: simultaneous audio streams from different applications (i.e., when firing up Windows in a VirtualBox, it does not hog my audio). So I googled for hours, read through forum posts, etc. and all I could find were hacks that either didn't work at all or resulted in the right volume but at completely unacceptable distortion levels. So, I'm almost certain that I am doing something wrong with configuring my audio setup using PA, but the whole point of PA as I understand it is to make using audio easier, at least for completely standard desktop audio use, which is what I want. So, either it should work out of the box or, similar to the arch way, there should be clear documentation on how to configure things right. The former is not the case on my hardware, and hours of googling did not lead me to the latter. So, to me it feels like this "standard" is moving us way too close to Windows land for my taste: if you know the magic incantation, then all will just work, but you have to be a member of our guild to be taught the incantation. As many others, I am happily running without PA and will probably be able to continue to do so for a long time because I don't even use Gnome or KDE. I just felt the need to add to the discussion because some people in this thread defend PA as the golden bullet for desktop audio use, which it absolutely isn't in my experience. If this was a result of using hardware that simply isn't supported well by linux drivers, then that would be my fault, but, as already said, plain ALSA works simply great. Throw PA into the mix, and things start to go wonky. Cheers, Norbert

On Sun, Jan 29, 2012 at 11:03:13AM -0400, Norbert Zeh wrote:

Things I observed (on Ubuntu, Mint, openSUSE, Arch...so it's not distro-specific) were way too low input (mic) and output volumes even when setting the volume controls to 100%. I really wanted to use PA because it offers something ALSA does not: simultaneous audio streams from different applications (i.e., when firing up Windows in a VirtualBox, it does not hog my audio). So I googled for hours, read through forum posts, etc. and all I could find were hacks that either didn't work at all or resulted in the right volume but at completely unacceptable distortion levels.

hey funny you mention it, when I came from ubuntu I configured alsa/dmix on arch and for the first time since I was using linux I heard sound from multiple applications at once... we could just settle that the depth of support varies between the two. Also, duplicate efforts are a common linux problem, and maybe some people would like to see pa devs on alsa/dmix. Saying such a thing is ridiculous though, since one will not be able to change things. I use xdm which doesn't depend on mesa/opengl stuff yet, nor pa, and it's actually possible to get most features that come with gdm, eg. session chooser, working with xdm. Whenever I want to get comfortable, I also try to get in touch with upstream when I think about adding features or have patches already, and I'm pretty much addicted to the additional effort linux is asking from me. I hope I won't stop learning new stuff soon, I might just go and buy such a pro audio card for teh arghs to patch the hell out of pa. Okay, I'm not *that* bored... :) cheers! mar77i

On 29 January 2012 18:44, Ralf Mardorf wrote:

[snip] When I've got a set up and I'll upgrade it, it's ok if things get borked, because of a new sound server. But if a group of people file bug reports, than it's ignorant not to fix the new sound server, but instead to demand that it must become dependency for more and more software even if it has nothing to do with audio.

- Ralf

GDM has to do with audio. It supports everything gnome wants to support. Which means it needs audio to either play a sound when you input a wrong password or to read the usernames aloud in case the user has visibility problems. It might work without pulseaudio (dummy package), sure, but it might not work as intended. The guys at the Gnome project decided they want pulseaudio. Now you can either try and convince them to drop support or convince the PulseAudio team to fix it's problems. -- Thanasis Georgiou

Am Sun, 29 Jan 2012 18:35:07 +0100 schrieb Jelle van der Waa :

Indeed, this should be the thing the complainers _should_ be doing. Archlinux ships vanilla upstream, so you're really barking at the wrong tree here. Please consider asking either PA for help or ditch it.

I don't think this is the totally wrong place, maybe not the very best, but not the worst. Because even if this mailing list is generally distribution specific and the Arch Linux devs try their best to keep PA optional, it's not quite unlikely that other people read this mailing list. Sometimes important changes come from downstream to upstream. Tom also mentioned that regarding the FHS. He told me - I'm not sure anymore if he did this on the list or in a private e-mail - that the new directory structures are first tested in the distros and then will be worked into the new FHS. So those new directory structures are first discussed in the distro specific mailing lists, too, like it has been done on this list with the discussion about /var/run and /run recently. So I think those discussions don't necessarily need to, but can be quite important. If nobody opens his mouth no matter where, nothing will change. Heiko

On Sun, Jan 29, 2012 at 11:52 AM, Martti Kühne wrote:

On Sun, Jan 29, 2012 at 05:44:46PM +0100, Ralf Mardorf wrote:

...

On Sun, 2012-01-29 at 16:57 +0100, Martti Kühne wrote:

...

it's actually possible to get most features that come with gdm, eg. session chooser, working with xdm.

This was the same for GDM. What would you do if the next upgrade will make XDM depend to PA? Of cause, you'll simply install another login manager. But what will you do if really important applications get such an unneeded dependency and it will break your work flow completely?

Umm, I'd focus efforts and patch it already out there. Or maybe I'd write my own display manager. XDM is, as the name implies, intended as a sane default, if you don't like it you're invited to replace it with something more fitting for your purposes.

Actually a recurring trend in the linux world is the origin of software right out of this kind of flamewar-fermented discussions, and new solutions pop up where software that has reached a certain age gets feature bloated and unfitting for your particular purpose. So, you're the guy to change that and write a new display manager for X? I'd happily help you.

However this is a downstream mailing list that does not benefit of this discussion, because the only thing I've been reading for two days now is that there are ppl pissed with dumb upstream decisions... and it's still not an arch problem. You cannot expect us, as users of this distro to solve the issues you create yourself through unflexible decision making and this non-coder's attitude. You want to focus on more important things, then do that already. I really expected you'd guess that some time.

^^^^ i second that emotion!

...

That's the point. Again and again and again, it's no problem as long as it is for PA only and you've the knowledge to build a dummy package.

Great. So the patches for the actual problem - GDM - are out next week? Leave a message if you need any help with that. You would naturally start with

$ cd ~/abs; cp /var/abs/extra/gdm .; cd gdm; makepkg -o; cd src/*/

^^^^ indeed!

...

Fortunately some packaging things for Arch are completely different to some old major distros. So, in this case it seems to be an issue cause upstream, but the more people understand what's the problem is, the better WE can inform upstream.

Yup. I did have trouble with opencbm, and sorting it out I used sed, source diving and reading about make/workingset magic for a few hours. Oh I do read stuff and have no idea about Xlib, and I still manage to set up a more or less crappy desktop environment based on st, dwm, and sandy - incidentally all low-sloc suckless apps which are small enough so I am actually able to debug my self-induced problems. Can't tell how much time I spent on reading xlib manuals to get to a solution more by accident... don't care, either, because it's fun.

^^^^ hooray!

...

When I've got a set up and I'll upgrade it, it's ok if things get borked, because of a new sound server. But if a group of people file bug reports, than it's ignorant not to fix the new sound server, but instead to demand that it must become dependency for more and more software even if it has nothing to do with audio.

yeah, if you'do not have a linus (in the software sense) and rms (in an ideologic sense) sitting on some dictatorship form of running things around here (is it godwin time yet?), all the other wannabes would fork linux to death. I do support the freedom of choice, but I do not feel obliged to patch gdm for you, because it's just not currently my problem.

^^^^ down with big brother! kill the beast! ... soooo, how about an `arch-offtopic` list? then at least we'd have somewhere to send these tangents, under pain of DEATH (er, temp ban perhaps), vs. begging and pleading for them to die ... since there is an obvious refusal to take them to the forum, or a blog, or a diary under the pillow. (it would be cool if you could re-assign a Message-ID to a specific list ...) who's with me? my phone is crying wolf so often i miss stuff i actually *do* want to read ... i like this list and would rather hang around. i still fail to see any concrete problems ... and ftw, the OP's question was answered on message #8, and concluded with "[...] no problem at all. i just like to understand whats going on [...]". ... a true champion! -- C Anthony

On Mon, Jan 30, 2012 at 4:17 PM, Martti Kühne wrote:

On Sun, Jan 29, 2012 at 12:08:27PM -0600, C Anthony Risinger wrote:

...

... soooo, how about an `arch-offtopic` list? then at least we'd have somewhere to send these tangents, under pain of DEATH (er, temp ban perhaps), vs. begging and pleading for them to die ... since there is an obvious refusal to take them to the forum, or a blog, or a diary under the pillow. (it would be cool if you could re-assign a Message-ID to a specific list ...)

who's with me?

+1, wondering why no one picked that up yet.

It's easy enough for me to mute the threads I don't want to listen to - no matter what ML.

On Mon, Jan 30, 2012 at 4:34 PM, SanskritFritz wrote:

On Mon, Jan 30, 2012 at 4:28 PM, Karol Blazewicz wrote:

...

It's easy enough for me to mute the threads I don't want to listen to - no matter what ML.

How do you do that?

I'm using gmail and it's under the 'more' button / list (first one on the right when you select or read / reply to a message).

On Mon, Jan 30, 2012 at 4:37 PM, Karol Blazewicz wrote:

On Mon, Jan 30, 2012 at 4:34 PM, SanskritFritz wrote:

...

On Mon, Jan 30, 2012 at 4:28 PM, Karol Blazewicz wrote:

...

It's easy enough for me to mute the threads I don't want to listen to - no matter what ML.

How do you do that?

I'm using gmail and it's under the 'more' button / list (first one on the right when you select or read / reply to a message).

Ah, so you are using Filter messages. I hoped there was a really easy way, like a 'mute' button that is thread aware :) Anyway, thanks for the advice.

2012/1/30 Karol Blazewicz :

On Mon, Jan 30, 2012 at 4:43 PM, SanskritFritz wrote:

...

On Mon, Jan 30, 2012 at 4:37 PM, Karol Blazewicz

...

I'm using gmail and it's under the 'more' button / list (first one on the right when you select or read / reply to a message).

Ah, so you are using Filter messages. I hoped there was a really easy way, like a 'mute' button that is thread aware :) Anyway, thanks for the advice.

Not sure if we are on the same page, because there's another option too: 'Filter messages like these', but I haven't tried it yet. It's enough that the whole thread (based on the title I guess) is moved out of my sight, but I still can access it, if I want.

I'm not sure if I want an advanced AI filtering of my messages  ;P

The major off-topics that see discussion here all have their own mailing lists, why not discuss it there? gnome lists: http://mail.gnome.org/mailman/listinfo/ pulse audio's discussion list: http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

On 01/30/12 at 04:43pm, SanskritFritz wrote:

On Mon, Jan 30, 2012 at 4:37 PM, Karol Blazewicz wrote:

...

On Mon, Jan 30, 2012 at 4:34 PM, SanskritFritz wrote:

...

On Mon, Jan 30, 2012 at 4:28 PM, Karol Blazewicz wrote:

...

It's easy enough for me to mute the threads I don't want to listen to - no matter what ML.

How do you do that?

I'm using gmail and it's under the 'more' button / list (first one on the right when you select or read / reply to a message).

Ah, so you are using Filter messages. I hoped there was a really easy way, like a 'mute' button that is thread aware :) Anyway, thanks for the advice.

No, it's as you say -- under the More button, there is a 'Mute' button that will simply mute the thread. This is built into gmail. Tim

Am Mon, 30 Jan 2012 16:17:48 +0100 schrieb Martti Kühne :

On Sun, Jan 29, 2012 at 12:08:27PM -0600, C Anthony Risinger wrote:

...

... soooo, how about an `arch-offtopic` list? then at least we'd have somewhere to send these tangents, under pain of DEATH (er, temp ban perhaps), vs. begging and pleading for them to die ... since there is an obvious refusal to take them to the forum, or a blog, or a diary under the pillow. (it would be cool if you could re-assign a Message-ID to a specific list ...)

who's with me?

+1, wondering why no one picked that up yet.

This wouldn't change much. The original topic was Arch related. The discussion about PA etc. evolved from this. So such a discussion wouldn't be switched to another mailing list. Same for any other similar discussions. See my try to change the subject from mount to PA. The discussion about PA has mostly been continued under the original subject. And there's another disadvantage. This arch-offtopic list would most likely not read by so many people and probably not by the "right" people whatever that might mean. A new mailing-list arch-offtopic would only be used for discussions which are originally be totally offtopic. And probably not even then, if someone isn't aware that his topic is offtopic. So if such a discussion would indeed be moved to an arch-offtopic list this would mean people can directly shut their mouth. So almost no chance for changes. People who are not interested in a thread can either ignore this thread, just filter it out or move its e-mails to /dev/null with their e-mail clients. Heiko

Am Mon, 30 Jan 2012 12:14:01 -0600 schrieb C Anthony Risinger :

not always, and i use a mobile 70%+ of the time. i don't want to create a new filter for every long-winded thread to nowhere. maybe i can create a label -> trash, and flag multiple conversations ... maybe i can't. why should i?

Because you don't want to see those e-mails. What do you think to how many mailing lists I am subscribed and in how many threads I'm not interested even on arch-general, aur-general etc. You know what I do with those threads? What anyone else would do. I just ignore them and delete those e-mails, because they may be important and interesting to other people, maybe to the devs, but not to me. Do I tell the people to shut up and not discuss their Nvidia problems because I have an ATI card and am not affected by Nvidia issues? For me discussions about Nvidia are not necessary, for Nvidia users they likely are. For you discussions about PA may be unnecessary, for pro-audio users they are important. Or what do you mean, why there came so much feedback from so many people incl. pro-audio users and why this thread got that long? If your mobile is not capable to handle such e-mail filters, just don't use your mobile for reading such mailing lists or buy a more capable one.

... you know what's way cooler? believing others are capable of respecting each other's time, and the reason others join a list in the first place (ie. the expected boundaries).

Oh, you mean because I should respect your time I should shut up and suspend my judgement? You really mean I should let myself censored because of your time? What about respecting other people's opinion? If such a discussion is unimportant to you and you're not interested in it, just ignore it. I think such a discussions like this one about PA is important, even if it's on an Arch related mailing list. But the problem with PA e.g. resp. this ongoing dependency hell is a general one and Arch is part of the "general" Linux community. And probably such a discussion is read by other more "important" people and then brought to the "right" place, etc. And again, this discussion about PA has evolved from an Arch related topic. So should this discussion just be stopped, because it gets off-topic somehow and you are not interested in it? I guess you should think about that. Heiko

On Sun, 2012-01-29 at 18:52 +0100, Martti Kühne wrote:

Great. So the patches for the actual problem - GDM - are out next week? Leave a message if you need any help with that. You would naturally start with

Why do you diss me? It's not the problem. If it would be GDM only than simply use this: https://aur.archlinux.org/packages.php?ID=48718 Why is there no chance to talk seriously about a problem? ./configure --disable-pulse when compiling gnome-settings-daemon should do this for this and some other situations, but that was not what we try to explain as the problem.

but I do not feel obliged to patch gdm for you, because it's just not currently my problem.

And I don't need your help regarding to this issue, because this isn't the issue. There's no patch needed, it's just a thing of configuring gnome-settings-daemon, IF THIS THREAD WOULD BE ABOUT GDM AND PA, but it isn't. Btw. haven't you noticed that I was quiet for the last mails? Now everybody knows you are an expert, able to patch GDM and I'm an idiot unable to patch GDM :D. There's no need for a patch and such a contest is wasting time. It's not important what I'm unable or able to do. This isn't a competition. Everybody and I understand that the problem is upstream and any request here is useless. No need to diss anybody. Regards, Ralf

On Sun, Jan 29, 2012 at 7:47 PM, Martti Kühne wrote:

On Sun, Jan 29, 2012 at 07:28:31PM +0100, Ralf Mardorf wrote:

...

./configure --disable-pulse when compiling gnome-settings-daemon should do this for this and some other situations, but that was not what we try to explain as the problem.

Awesome, is this in aur yet? :D

cheers! mar77i

On Sun, Jan 29, 2012 at 7:28 PM, Ralf Mardorf wrote:

It's not the problem. If it would be GDM only than simply use this: https://aur.archlinux.org/packages.php?ID=48718

-- Kwpolska http://kwpolska.tk stop html mail      | always bottom-post www.asciiribbon.org | www.netmeister.org/news/learn2quote.html GPG KEY: 5EAAEA16   | Arch Linux x86_64, zsh, mutt, vim. # vim:set textwidth=70:

Hi :) the real issue isn't solved, but here are two hints how to get rid of PA for current Arch Linux, to stop the never ending, useless discussion. On Sun, 2012-01-29 at 13:23 -0600, Leonid Isaev wrote:

Just get your job done and in the evening rebuild the package.

I'm using this package since I'm using audio with Arch Linux $ ls /usr/src/pulseaudio-dummy -l Dec 23 18:10 PKGBUILD Jan 15 01:43 pulseaudio-dummy-1.0-1-any.pkg.tar.xz I'm in no hurry ;). Anyway those solutions might be helpful for others: gnome-settings-daemon-nopulse 3.2.2-1 is available at https://aur.archlinux.org/packages.php?ID=48718 I'm using a pulseaudio-dummy package. $ cat /usr/src/pulseaudio-dummy/PKGBUILD pkgname=pulseaudio-dummy pkgver=1.0 pkgrel=1 pkgdesc="A dummy package that pretends to provide pulseaudio." arch=('any') url="" license=('BSD') provides=('pulseaudio') conflicts=('pulseaudio') source=() Both posted several times before. Btw. somebody from this list explained me how to build dummy-packages for Arch Linux, by this example, since I'm new to Arch. A dummy-package IMO is the best way to go, since it protect against installing PA, what ever I do. So I can install what ever GNOME or KDE app I like and if I should install GNOME3, I could upgrade gnome-settings-daemon from extra, without taking care about PA. Perhaps this could damage an app, but I never experienced this for another Linux install I used. This are just workarounds that don't solve the essence of that issue. Ok, the essence has to be clarified with upstream.

Do you have to pay for PA/gnome?

I'm using XFCE. The sub-thread was about issues caused by the policy of PA, not about my personal problems I might or might not have. :) Ralf PS: I suspect [solved] is for "silence", regarding to the S/N ratio.

On Sun, 29 Jan 2012 21:27:46 +0100 Ralf Mardorf wrote:

I know today, but dependency hell still is an issue, even for Arch.

Gnome was going to depend on Linux, precluding it from the BSDs and I guess custom kernels. Blanket dependencies have been regarded as one of the biggest problems with Linux for years, once said to be getting better finally and yet it appears to be getting worse. Should I be able to use Dolphin on xfce without installing hundreds of megabytes that then need to be updated. P.s. Pulse audio doesn't work with grsecurity kernels without pax marking (feature diabling). Alsa works fine. Please include that if you join the gnome mailing list. -- Kc

On Sun, Jan 29, 2012 at 4:03 PM, Norbert Zeh wrote:

Things I observed (on Ubuntu, Mint, openSUSE, Arch...so it's not distro-specific) were way too low input (mic) and output volumes even when setting the volume controls to 100%.  I really wanted to use PA because it offers something ALSA does not: simultaneous audio streams from different applications (i.e., when firing up Windows in a VirtualBox, it does not hog my audio).  So I googled for hours, read through forum posts, etc. and all I could find were hacks that either didn't work at all or resulted in the right volume but at completely unacceptable distortion levels.

So, I'm almost certain that I am doing something wrong with configuring my audio setup using PA,

This sounds like a good, old-fashioned bug, I don't think you did anything wrong in your setup. Most likely your sound driver (ALSA) is exporting the wrong dB information to PulseAudio which means that PA's volume calculations will be nonsense. Please file a bug against ALSA. Cheers, Tom

On Sun, Jan 29, 2012 at 11:04 PM, Ralf Mardorf wrote:

Since the sound device is ok when using ALSA only, the +4dBu vs -10dBV information or any ratio dB to fader position or what ever you mean, must be somewhere provided correctly by ALSA. If such a dB issue should be the cause, than I suspect PA pulls this information from the wrong place. What happens, when using Arts or any other sound server?

ALSA is not using this information in the same way (if at all). It is a well known problem that PA will act crazy if the dB values from ALSA are wrong, but ALSA itself mostly does not care (because the user is setting all the mixer level themselves, unlike in PA where there are heuristics doing clever stuff). To learn more, run test and find the correct values that can be reported to ALSA, see: http://pulseaudio.org/wiki/BadDecibel.

In case of doubt file a bug report to ALSA and PA.

Sure, but do the test above first. It will save some time.

IIRC the sound device works correctly since years for ALSA, just when using PA there's distortion. Is it reasonable to assume that there's a bug for ALSA?

In this case, this is a well known class of bugs, so yes that's reasonable (but not certain).

Perhaps an user error? If the device should support +4dBu and -10dBV, than the user perhaps missed to choose the correct level. Nor ALSA neither PA does know what equipment is connected to the audio IOs.

The user should not need to know about dB levels when using PA, so this is a software bug (somewhere). -t

On Sun, 2012-01-29 at 23:11 +0000, Fons Adriaensen wrote:

A trained audio engineer knows how to find out such things and get them right, but the average user is completely lost if there is more than one control that affects volume.

So I have translated the text correctly. Comparing two 1s sinus signals at what frequency ever, in a chain of faders, one sinus signal after the other, by listening, for calibrating. Good luck! I wonder about the magic workaround mentioned on the website. Cheers, Ralf

On Sun, 2012-01-29 at 23:33 +0100, Tom Gundersen wrote:

On Sun, Jan 29, 2012 at 11:04 PM, Ralf Mardorf wrote:

...

Since the sound device is ok when using ALSA only, the +4dBu vs -10dBV information or any ratio dB to fader position or what ever you mean, must be somewhere provided correctly by ALSA. If such a dB issue should be the cause, than I suspect PA pulls this information from the wrong place. What happens, when using Arts or any other sound server?

ALSA is not using this information in the same way (if at all). It is a well known problem that PA will act crazy if the dB values from ALSA are wrong, but ALSA itself mostly does not care (because the user is setting all the mixer level themselves, unlike in PA where there are heuristics doing clever stuff).

To learn more, run test and find the correct values that can be reported to ALSA, see: http://pulseaudio.org/wiki/BadDecibel.

...

In case of doubt file a bug report to ALSA and PA.

Sure, but do the test above first. It will save some time.

...

IIRC the sound device works correctly since years for ALSA, just when using PA there's distortion. Is it reasonable to assume that there's a bug for ALSA?

In this case, this is a well known class of bugs, so yes that's reasonable (but not certain).

...

Perhaps an user error? If the device should support +4dBu and -10dBV, than the user perhaps missed to choose the correct level. Nor ALSA neither PA does know what equipment is connected to the audio IOs.

The user should not need to know about dB levels when using PA, so this is a software bug (somewhere).

The +4dBu and -10dBV issue is related to the analog IOs and the connected audio equipment, so it's impossible for any software to know what dB to choose, since they can't detect the connected analog gear. This is another issue: "If (when flat volumes are enabled in PulseAudio) the playback volume of one stream changes whenever another stream is played, this is most likely caused be incorrect dB attenuation data exposed by the ALSA kernel driver. [snip] There's a temporary workaround to make PA skip the invalid dB data. But ha! I won't write down how that works here, to make sure that you really file that bug. Muahaha. Mauahahahahah! " I'm not sure if I translated the complete text correctly. Especially this is hard to understand: "If the third and fourth parameter to dbverify are ommited, the tool will test the loudest volume setting against the softest one. If those arguments are specified the tool will compare these two discrete volumes. It is advisable to play around with these values to compare multiple volume steps of the hardware. It is especially wise to pick your own values if the lowest hw volume setting is too silent to be audible. That said it might make sense to omit these arguments when starting your testing. This will then also show you the available volume step range of your card and you can then pick other values to tes from that range. The tool will play a 1s sine wave twice and in a loop, and attenuate it once in software and once in hardware. The effect should be that the wave should have the same volume both times if the dB information is reliable. If the dB data is not correct, then they will have different volumes. [snip] If this listening test reveals that the dB information of your driver is not correct" What I'm able to translate is very strange.

On Sun, Jan 29, 2012 at 11:50 PM, Norbert Zeh wrote:

Thanks, Tom.  Now that I know where to look next, I'll play with this next time I have some spare time for this kind of stuff.

I recommend going to #systemd on freenode if you have data/questions, they are very friendly and helpful. Cheers, Tom

On Sun, 2012-01-29 at 11:07 +0000, Mauro Santos wrote:

On 29-01-2012 10:50, Ralf Mardorf wrote:

...

I just ask that upgrades don't break a working machine, caused by unneeded dependencies. If a studio used GNOME, than an upgrade shouldn't add PA and break the machine.

Deploying untested updates/upgrades on production machines is asking for trouble, regardless of what is getting updated/upgraded.

Just my 2 cents.

wrote:

...

...

...

I'm sure all Linux installs MUST be ready to use out of the box for

Full ACK! For a production machine everybody should make backups, real snapshots, that means not sync the backup, but to keep several backups. Upgrades never should be done during a production. But backups have to be done sometimes and then they shouldn't break a machine, caused by forcing to add dependencies, that shouldn't be dependencies. On Sun, 2012-01-29 at 11:58 +0100, Tom Gundersen wrote: On Sun, Jan 29, 2012 at 11:50 AM, Ralf Mardorf professional audio

...

...

...

users. after all, the same is true for the other operating systems.

I just ask that upgrades don't break a working machine, caused by unneeded dependencies. If a studio used GNOME, than an upgrade shouldn't add PA and break the machine. Only add dependencies if they are needed. PA isn't needed, it's optional. If upstream add it, it might be allowed to explain, why it isn't good to do so.

Sounds like possibly valid concerns. But this is not something to discuss here. Please contact gnome and/or pulseaudio if you have issues. We just package their software, we don't decide their priorities or policies.

And I think this discussion has gone on for way too long...

Passing from pillar to post. A community should think about marginalized groups too. Where ever WE try to explain the problem, it ends like this, or more worse with assumptions similar to those from Oon-Ee Ng. If anybody should have diss somebody named Lennart, it's not fair to put the blame on me. I switched to Arch, because the distros I used before already become hard to use. Talking about PA here, is to prevent Arch to become hard to use too. From that standpoint it belongs to a discussion at some Arch mailing list. If Arch-"general" isn't the right place, it would be nice to add a list Arch-"discussion", Arch-"sandbox" or what ever. 0,02€, Ralf PS: I tried to be quiet, but since others continued with claims that are wrong, I couldn't. Audio users tried to explain that WE experienced "things" as borked and people who never have done audio productions send links and claimed that we don't know the facts. Our experiences aren't experiences, but hearsay only. Is enlightenment unwanted?

On Sat, Jan 28, 2012 at 06:46:20PM +0100, Tom Gundersen wrote:

There has been a lot of changes lately, this is true. However, a lot of effort has been put into reaching consensus between the distros and the relevant upstream projects. Much more so now than before.

It is my impression that a majority of the ideas have originated in Debian and Fedora, but I don't really care who came up with what idea as long as we end up with the best ideas in the end (and possibly more importantly, that we all end up with the same ideas). As far as I can tell the different changes are receiving a lot of scrutiny within the different distros before being adopted (as one would expect); and overall we are all moving in the same direction.

One consequence of all these changes is dependency creep. Just one example: emacs depends (via gconf) on consolekit. I've been using emacs for > 15 years or so, and I've never seen it depend on PAM or Kerberos, SSH authentication subsystems, etc. It has no reason to depend on consolekit. And if it does by transitivity that should make its maintainers think twice. Allowing such a dependeny to exist is *bad engineering*. If this trend continues it will end with everything depending on everything. Which means there is no more choice. I know it's not and Arch thing, but still this is cause for concern. Ciao, -- FA Vor uns liegt ein weites Tal, die Sonne scheint - ein Glitzerstrahl.

On Sat, 28 Jan 2012 22:37:37 +0100 Ralf Mardorf wrote:

On Sat, 2012-01-28 at 20:40 +0000, Fons Adriaensen wrote:

...

One consequence of all these changes is dependency creep. Just one example: emacs depends (via gconf) on consolekit. I've been using emacs for > 15 years or so, and I've never seen it depend on PAM or Kerberos, SSH authentication subsystems, etc. It has no reason to depend on consolekit. And if it does by transitivity that should make its maintainers think twice.

Allowing such a dependeny to exist is *bad engineering*. If this trend continues it will end with everything depending on everything. Which means there is no more choice. I know it's not and Arch thing, but still this is cause for concern.

And this becomes a fashion. Pulseaudio is an unneeded dependency for several software.

4 years ago: https://bugs.launchpad.net/consolekit/+bug/148454/+activity

Today: [spinymouse@archlinux ~]$ ps -Lf -C console-kit-daemon UID PID PPID LWP C NLWP STIME TTY TIME CMD root 861 1 861 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 862 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 863 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 864 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 865 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 866 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 867 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 868 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 869 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 870 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 871 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 872 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 873 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 874 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 875 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 876 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 877 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 878 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 879 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 880 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 881 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 882 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 883 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 884 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 885 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 886 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 887 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 888 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 889 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 890 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 891 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 892 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 893 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 894 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 895 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 896 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 897 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 898 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 899 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 900 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 901 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 902 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 903 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 904 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 905 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 906 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 907 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 908 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 909 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 910 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 911 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 912 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 913 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 914 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 915 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 916 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 917 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 918 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 919 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 920 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 921 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 922 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 923 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 925 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 926 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon

Yeah, about CK: https://www.libreoffice.org/bugzilla/show_bug.cgi?id=17720 -- Leonid Isaev GnuPG key ID: 164B5A6D Key fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D

On Sat, 28 Jan 2012 20:40:51 +0000 Fons Adriaensen wrote:

On Sat, Jan 28, 2012 at 06:46:20PM +0100, Tom Gundersen wrote:

...

There has been a lot of changes lately, this is true. However, a lot of effort has been put into reaching consensus between the distros and the relevant upstream projects. Much more so now than before.

It is my impression that a majority of the ideas have originated in Debian and Fedora, but I don't really care who came up with what idea as long as we end up with the best ideas in the end (and possibly more importantly, that we all end up with the same ideas). As far as I can tell the different changes are receiving a lot of scrutiny within the different distros before being adopted (as one would expect); and overall we are all moving in the same direction.

One consequence of all these changes is dependency creep. Just one example: emacs depends (via gconf) on consolekit. I've been using emacs for > 15 years or so, and I've never seen it depend on PAM or Kerberos, SSH authentication subsystems, etc. It has no reason to depend on consolekit. And if it does by transitivity that should make its maintainers think twice.

http://www.gnu.org/software/emacs/NEWS.23.2 Care to file a bug?

Allowing such a dependeny to exist is *bad engineering*. If this trend continues it will end with everything depending on everything. Which means there is no more choice. I know it's not and Arch thing, but still this is cause for concern.

Ciao,

-- Leonid Isaev GnuPG key ID: 164B5A6D Key fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D

It would be nice to have a sandbox, a list to discuss things like this. I guess non of those is the right place: http://mailman.archlinux.org/mailman/listinfo So a last note by me, then I'll be quiet. On Sat, 2012-01-28 at 17:29 +0100, Heiko Baums wrote:

Am Sat, 28 Jan 2012 15:09:30 +0100 schrieb Tom Gundersen :

...

Have you tried after this fix was released: http://git.alsa-project.org/?p=alsa-lib.git;a=commitdiff;h=d3906a93072171e5b...?

Like I've written in another e-mail in this thread:

And, no, artificially crippling a (semi-)professional audio card down to stereo with a strange ALSA configuration is not a solution for this. And, no, it's not ALSA's fault like Lennart Poettering says, it's PulseAudio's fault.

When Suse switched to PA years ago, they blamed users for not understanding Linux, the audio experts from Suse forums didn't know how to fix it, but they were sure, stupid users like me must have broken their Suse, because stupid users like me are to stupid to install Suse from DVD. They called me a troll. This is how I fixed Suse a long time ago and this solution wasn't from any Suse experts, this and other hints are from the Linux "pro-"audio community. [root@archlinux spinymouse]# mount /dev/sda7 /mnt/suse11.2 [root@archlinux spinymouse]# cat /mnt/suse11.2/usr/share/alsa/cards/ICE1712.conf [snip] confdir:pcm/front.conf ICE1712.pcm.front.0 { @args [ CARD ] @args.CARD { type string } type route ttable.0.0 1 ttable.1.1 1 slave.pcm { type hw card $CARD } #### fix PA issue #### slave.format S32_LE slave.channels 10 ###################### } [snip] IMO it make no sense to discuss the PA issue, especially not when the thread is about "mount". I wonder why distros not simply provide dummy packages to replace the PA packages, if users prefer not to install PA. It's not secure to think that some distro doesn't force users to install PA, e.g. for Debian GNOME2 didn't force you to install it, but with the upgrade to GNOME3, they introduced it. And there's absolutely no reason to do it. GNOME3 on Debian did run and audio wasn't broken, when I replaced PA by a self-build dummy package. Yes, I already wrote this in another thread. So arguing a user should use another DE, if he doesn't like PA, isn't a solution. Btw. here on Arch I wish to be free to use GDM even if my DE is XFCE. I installed a dummy for PA here too. I really wonder why DM needs PA ;). As I mentioned before, most users and developers praise PA, even some pro-audio developers aren't against PA, so we should learn to live with it. More OT: We should pray not to get tons of sub-versions for different versions of jack ;) [root@archlinux spinymouse]# pacman -Ss jack2 | grep / community/jack2 1.9.8-1 [installed] community/jack2-dbus 1.9.8-1 multilib/jack2-dbus-multilib 1.9.8-1 multilib/jack2-multilib 1.9.8-1 kxstudio-free/jack2-dbus-ladish 1.9.7-3 kxstudio-free/jack2-ladish 1.9.7-3 fortunately we're still free to use packages for a classic "jack", build to connect and not to refuse connections.

This is what is done by this fix. But those (semi-)professional audio cards with an ice1712 chip aren't SoundBlaster like stereo sound cards for playing some games. They work completely different, because they have several separate channels which can be mixed however you want (of course to normal stereo, too, but not only). Look at the only working mixer for this card, envy24control in alsa-tools (or alsa-tools-ice1712 from AUR), to get a clue. [snip]

On Sat, Jan 28, 2012 at 12:56 AM, Fons Adriaensen wrote:

On Sat, Jan 28, 2012 at 12:50:09AM +0100, Tom Gundersen wrote:

...

On Sat, Jan 28, 2012 at 12:35 AM, G. Schlisio wrote:

...

Am 28.01.2012 00:26, schrieb G. Schlisio:

...

Hi all, i used to keep a folder in /media to serve as mountpoint if some manual mountis was needed. since some days, this folder disappeared, even if created again. is there any change in filesystems, kernel or whatsoever changing behavior there, is it intended (if so, why?) or a bug? every hint appreciated.

If you are using initscripts this should not happen.

If you are using systemd it should. The justification being that /media is meant for ephemeral mount points (i.e. stuff created by udisks et al.).

Wouldn't most users associate /media with cd, dvd etc. ? Seems like on odd name for what systemd uses it for.

cd, dvd, usb sticks, etc are examples of the kind of temporary mount points created by udisks under /media. They are created on insertion and deleted on removal. Hence, there is no need to preserve the contents of /media and having it on tmpfs makes sense. That said, it seems to be agreement among the upstream devs that /media is a broken concept and systemd/udisks will likely introduce a user specific replacement, which will no longer be in the root fs. -t

Am 28.01.2012 00:46, schrieb Leonid Isaev:

On Sat, 28 Jan 2012 00:26:38 +0100 "G. Schlisio" wrote:

...

Hi all, i used to keep a folder in /media to serve as mountpoint if some manual mountis was needed. since some days, this folder disappeared, even if created again. is there any change in filesystems, kernel or whatsoever changing behavior there, is it intended (if so, why?) or a bug? every hint appreciated. georg That is what /mnt is for... Do you have systemd?

jipp, just switched to systemd. so thats why… sometimes i need more than 1 mountpoint, but still you are right. thanks and sorry for the noise.

Am 28.01.2012 01:02, schrieb Leonid Isaev:

On Sat, 28 Jan 2012 00:49:03 +0100 "G. Schlisio" wrote:

...

Am 28.01.2012 00:46, schrieb Leonid Isaev:

...

On Sat, 28 Jan 2012 00:26:38 +0100 "G. Schlisio" wrote:

...

Hi all, i used to keep a folder in /media to serve as mountpoint if some manual mountis was needed. since some days, this folder disappeared, even if created again. is there any change in filesystems, kernel or whatsoever changing behavior there, is it intended (if so, why?) or a bug? every hint appreciated. georg That is what /mnt is for... Do you have systemd?

jipp, just switched to systemd. so thats why… sometimes i need more than 1 mountpoint, but still you are right. thanks and sorry for the noise. But why can't you create the same dir structure under /mnt? i can (an will) of course. until now /media was the place. no problem at all. i just like to understand whats going on, you know…