Re: [arch-general] change in mount behaviour?
On 28-01-12 17:29, Heiko Baums wrote: Am Sat, 28 Jan 2012 15:09:30 +0100 schrieb Tom Gundersent...@jklm.no: Apologies for the late reply, but the length of the thread kept me off for a while. [...] 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? There is actually a *HUGE* difference, but there is also some history involved in this. I don't have links handy, but i'm sure google can help you out here. Also, this is just my understanding of it, so YMMV. First: harddisk were considered fixed. If they were there when the system started up, one could mostly assume they would stay there. Besides those always there blockdevices, there were also CD-ROMs with their removable media. Since the *device* would probably stay where it was, it was easy to create an entry in /etc/fstab for those so users could use them and rely on where they would show up. Some distro's chose to use /mnt as a mountpoint for CD-Roms, some others created subdirectories below /mnt. Despite these small differences, the general behavior was well understood and workable. Then came USB (and other removable) storage and the trouble began. Now there were *devices* that would appear and disappear while the system was still running. I think that there were a couple of solutions to handle this situation, but no real standard. I'm not sure how the standardization went, but it ended up with the current /media hierarchy. No more fixed entries in /etc/fstab to allow users to mount and use those devices, but dynamically created mountpoints and possibly also auto-mounting. This way the system doesn't need any info on possible storage media beforehand, but everything is created on the fly, when needed. Quite a nice and elegant solution, if you ask me. With this in mind, the FHS decisions seem fairly logical: - /mnt is used in different ways, so it's best to steer away from it - /media is where we mount removable storage. It has not (much) tradition behind it, so it's easy to create a new standard with it. Hope that helps. mvg, Guus
Re: [arch-general] change in mount behaviour?
On Sun, 2012-01-29 at 07:22 +0800, Oon-Ee Ng wrote: On Jan 29, 2012 3:29 AM, Tom Gundersen t...@jklm.no wrote: On Sat, Jan 28, 2012 at 7:59 PM, Ralf Mardorf ralf.mard...@alice-dsl.net 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. 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
Re: [arch-general] change in mount behaviour?
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 t...@jklm.no wrote: On Sat, Jan 28, 2012 at 7:59 PM, Ralf Mardorf ralf.mard...@alice-dsl.net 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
Re: [arch-general] change in mount behaviour?
On Jan 29, 2012 5:46 PM, Ralf Mardorf ralf.mard...@alice-dsl.net wrote: On Sun, 2012-01-29 at 07:22 +0800, Oon-Ee Ng wrote: On Jan 29, 2012 3:29 AM, Tom Gundersen t...@jklm.no wrote: On Sat, Jan 28, 2012 at 7:59 PM, Ralf Mardorf ralf.mard...@alice-dsl.net 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. 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
Re: [arch-general] change in mount behaviour?
On Sun, 2012-01-29 at 18:13 +0800, Oon-Ee Ng wrote: On Jan 29, 2012 5:46 PM, Ralf Mardorf ralf.mard...@alice-dsl.net wrote: On Sun, 2012-01-29 at 07:22 +0800, Oon-Ee Ng wrote: On Jan 29, 2012 3:29 AM, Tom Gundersen t...@jklm.no wrote: On Sat, Jan 28, 2012 at 7:59 PM, Ralf Mardorf ralf.mard...@alice-dsl.net 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. 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
Re: [arch-general] change in mount behaviour?
On Sun, 2012-01-29 at 18:13 +0800, Oon-Ee Ng wrote: Yes, why not generalize when a specific example is debunked? About what kind of generalization are you talking? I'm serious, I don't understand what you are talking about. 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. I don't ask for a Linux that works OOTB. My arguments where about PA that doesn't work with professional RME cards, since I'm using a RME card. Without Jack and with PA such a card doesn't work. FWIW it's the same with Envy24 cards, the most used audio cards, when using software like Ardour, Qtractor etc., since RME cards are very expensive. A classic Jack also doesn't work when PA is installed and there are reasons to use a classic Jack. Why do you think it's packaged? Your assumptions are strange. Why are you doing this? Could you please become objective? Regards, Ralf
Re: [arch-general] change in mount behaviour?
On Sun, Jan 29, 2012 at 11:50 AM, Ralf Mardorf ralf.mard...@alice-dsl.net 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
Re: [arch-general] change in mount behaviour?
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. -- Mauro Santos
Re: [arch-general] change in mount behaviour?
On Sun, 2012-01-29 at 11:07 +, 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. 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 ralf.mard...@alice-dsl.net 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... 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?
Re: [arch-general] change in mount behaviour?
Am Sun, 29 Jan 2012 11:58:31 +0100 schrieb Tom Gundersen t...@jklm.no: 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. Heiko
Re: [arch-general] change in mount behaviour?
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.
Re: [arch-general] change in mount behaviour?
Heiko Baums [2012.01.29 1446 +0100]: Am Sun, 29 Jan 2012 11:58:31 +0100 schrieb Tom Gundersen t...@jklm.no: 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
Re: [arch-general] change in mount behaviour?
Fons Adriaensen [2012.01.29 1442 +]: 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
Re: [arch-general] change in mount behaviour?
On Sun, 2012-01-29 at 11:06 -0400, Norbert Zeh wrote: Fons Adriaensen [2012.01.29 1442 +]: 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 :(.
Re: [arch-general] change in mount behaviour?
On 29-01-2012 15:03, Norbert Zeh wrote: 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. Currently I am also a happy pa user and I haven't experienced any of the most common problems that affected pa users, but before I had to use ossv4 because plain alsa would output crappy sound until some major driver rework landed on the kernel. I've seen a small part of both worlds and I know how frustrating it is when things don't work when and how they should, but as with most things, usually the blame isn't on one side only. I know that alsa devs and pa dev(s) already did their fair share of blame throwing, it might be a case of pa missing some important features/support or doing something that doesn't make sense but I wouldn't discard the possibility of bugs in drivers for less common cards or many workarounds/fixes still missing in drivers for really cheap and sometimes broken cards/chips/hardware implementations. Take as an example the recent problem with KDE (I think it was KDE) and open source graphics drivers. Drivers advertised support for some modernish opengl features, KDE tried to used them, but as they were never really widely used and tested there were lots of problems and in some cases the advertised support wasn't even implemented in the drivers, the only thing that was missing was software to expose the problems. Any problems and feature requests should be reported upstream, at least let the blame brainstorming happen at a level where it might do some good, even if the respective devs don't want to acknowledge the problems they might silently fix things or make them work better :p -- Mauro Santos
Re: [arch-general] change in mount behaviour?
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
Re: [arch-general] change in mount behaviour?
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? 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. 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. Reading the last mails, there are a lot of misunderstandings, e.g. simply use jackdbus etc.. Btw. for other distros software sometimes is picked to pieces, e.g. libjack and jackd and all the times there were issues related to this. Regarding to this Jack isn't issue for any distro I know today, but dependency hell still is an issue, even for Arch. On Sun, 2012-01-29 at 15:52 +, Mauro Santos wrote: I know that alsa devs and pa dev(s) already did their fair share of blame throwing, it might be a case of pa missing some important features/support or doing something that doesn't make sense but I wouldn't discard the possibility of bugs in drivers for less common cards What are less common audio cards? Envy24 is a very common microchip used by tons of audio cards, not only for audio production. RME are the only good supported, professional cards for Linux, that's why they are not exotic for audio production. Those cards have drivers that work. 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
Re: [arch-general] change in mount behaviour?
On 29 January 2012 18:44, Ralf Mardorf ralf.mard...@alice-dsl.net 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
Re: [arch-general] change in mount behaviour?
On Sun, Jan 29, 2012 at 5:52 PM, Thanasis Georgiou sakisd...@gmail.comwrote: On 29 January 2012 18:44, Ralf Mardorf ralf.mard...@alice-dsl.net 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. 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. -- Thanasis Georgiou -- Jelle van der Waa
Re: [arch-general] change in mount behaviour?
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. 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/*/ 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. 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. cheers! mar77i
Re: [arch-general] change in mount behaviour?
On Sun, Jan 29, 2012 at 11:52 AM, Martti Kühne mysat...@gmail.com 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! ... s, 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
Re: [arch-general] change in mount behaviour?
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
Re: [arch-general] change in mount behaviour?
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
Re: [arch-general] change in mount behaviour?
On Sun, Jan 29, 2012 at 7:47 PM, Martti Kühne mysat...@gmail.com 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 ralf.mard...@alice-dsl.net 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:
Re: [arch-general] change in mount behaviour?
On Sun, 29 Jan 2012 17:44:46 +0100 Ralf Mardorf ralf.mard...@alice-dsl.net 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? 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. So how exactly does an unwanted dep break your workflow? So XDM depends on PA -- big deal -- noone forces you to actually use PA. Just get your job done and in the evening rebuild the package. What are less common audio cards? Envy24 is a very common microchip used by tons of audio cards, not only for audio production. RME are the only good supported, professional cards for Linux, that's why they are not exotic for audio production. Those cards have drivers that work. 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. PA, gnome, consolekit are essentially redhat things and are very closely tight to fedora. These people are trying to produce a great OS. They don't have to care about other linuxes. Do you have to pay for PA/gnome? If you are so unhappy with PA -- fork it and develop it the way you like. - Ralf -- Leonid Isaev GnuPG key ID: 164B5A6D Key fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D signature.asc Description: PGP signature
Re: [arch-general] change in mount behaviour?
Am Sun, 29 Jan 2012 14:42:33 + schrieb Fons Adriaensen f...@linuxaudio.org: They *DO* know and understand the difference between consumer and 'pro' audio. I have another impression. 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. Heiko
Re: [arch-general] change in mount behaviour?
Am Sun, 29 Jan 2012 18:35:07 +0100 schrieb Jelle van der Waa je...@vdwaa.nl: 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
Re: [arch-general] change in mount behaviour?
Am Sun, 29 Jan 2012 11:03:13 -0400 schrieb Norbert Zeh n...@cs.dal.ca: 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%. That's not the point with pro-audio hardware. The problem with ice1712 chips is that those chips aren't stereo or surround sound chips. Those cards have instead separate lines for in- and output. They can of course be mixed as normal stereo, but they can mixed however you want. Those cards don't have a master volume control or an amplifier, they only have attenuators. So those cards can't be handled like those consumer sound cards, and they need a special mixer and patch bay. ALSA delivers one in the package alsa-tools called envy24control. PA just knows pure stereo and maybe surround sound. PA wants to have a master volume control. PA doesn't have a mixer and patch bay for those cards. And the PA developers blame ALSA for this and just think crippling down those cards to pure stereo cards with an ominous ALSA configuration. Of course, this is a very dirty workaround to get those cards somehow working with PA, but with this configuration you disable all the other functionality of those cards. That is the problem. Well, it's not a problem as long as PA stays just optional so that people who like the features of PA and just use a consumer sound card can use PA and the pro-audio users don't need to use it. So the problem is that PA is made more and more as a standard by several up- and downstreams. That is what worries me. 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). Simultaneous audio streams from different applications are mixed together by ALSA's dmix which is activated by default since years. I haven't tested sound from VirtualBox, yet. Heiko
Re: [arch-general] change in mount behaviour?
On Sun, Jan 29, 2012 at 4:03 PM, Norbert Zeh n...@cs.dal.ca 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
Re: [arch-general] change in mount behaviour?
On Sun, Jan 29, 2012 at 10:02:25PM +0100, Heiko Baums wrote: Am Sun, 29 Jan 2012 14:42:33 + schrieb Fons Adriaensen f...@linuxaudio.org: 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.
Re: [arch-general] change in mount behaviour?
On Sun, 2012-01-29 at 22:41 +0100, Tom Gundersen wrote: On Sun, Jan 29, 2012 at 4:03 PM, Norbert Zeh n...@cs.dal.ca 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. 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? In case of doubt file a bug report to ALSA and PA. 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? 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.
Re: [arch-general] change in mount behaviour?
Am Sun, 29 Jan 2012 21:55:28 + schrieb Fons Adriaensen f...@linuxaudio.org: Could be. My impression is based on talking with LP face to face. And yours ? 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. 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. OK, looks like there is a working workaround, but not a real solution. The solution would be a better engineering. Heiko
Re: [arch-general] change in mount behaviour?
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.
Re: [arch-general] change in mount behaviour?
On Sun, Jan 29, 2012 at 11:04 PM, Ralf Mardorf ralf.mard...@alice-dsl.net 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
Re: [arch-general] change in mount behaviour?
Tom Gundersen [2012.01.29 2241 +0100]: On Sun, Jan 29, 2012 at 4:03 PM, Norbert Zeh n...@cs.dal.ca 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. 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. Cheers, Norbert
Re: [arch-general] change in mount behaviour?
On Sun, Jan 29, 2012 at 11:50 PM, Norbert Zeh n...@cs.dal.ca 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
Re: [arch-general] change in mount behaviour?
On Sun, Jan 29, 2012 at 11:33:34PM +0100, Tom Gundersen wrote: 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). There is *no* way PA or anything could ever guess the correct electrical levels (e.g. setting a -10dB/+4dB switch that some soundcards offer) because that depends on what the user has connected to his/her card. The whole mixer control issue is a complete mess, and it's neither ALSA's or PA's fault. The blame has to go to the manufacturers of the audio HW. In some cases the 'normal' setting for a mixer gain is the maximum one, in others it's way below that because the HW is designed to provide a way to boost PCM levels that are too low. And there's no way to find out - in both cases the maximum will be labeled '0dB'. And that's only *one* control, in most cases there are at least two. 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. All PA should be doing is to provide sensible digital (pcm) levels. The rest, like it or not, has to be done by the user. Another blame has to go to most apps that provide 'desktop' sounds, in almost all cases the level is way too high. Even if I would want a beep or 'plioung' at some times I don't expect it to be as loud as the music. Yet most such apps output near to maximum level. Ciao, -- FA Vor uns liegt ein weites Tal, die Sonne scheint - ein Glitzerstrahl.
Re: [arch-general] change in mount behaviour?
On Sun, 2012-01-29 at 23:33 +0100, Tom Gundersen wrote: On Sun, Jan 29, 2012 at 11:04 PM, Ralf Mardorf ralf.mard...@alice-dsl.net 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.
Re: [arch-general] change in mount behaviour?
On Sun, 2012-01-29 at 23:11 +, 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
Re: [arch-general] change in mount behaviour?
On Mon, Jan 30, 2012 at 12:28:00AM +0100, Ralf Mardorf wrote: On Sun, 2012-01-29 at 23:11 +, 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! Yes, it's nonsense, there's no good solution for this. And, correcting myself, in a sense it's ALSA's fault. On Windows almost every soundcard has its own specific driver and mixer app. So things can be initialised to defaults that work. ALSA tries to have as much common code as possible. It makes sense from a SW engineering point of view, but it is completely out of touch with reality. Besides all that: Ralf, it would probably enhance your 'street value' on the Arch list if you could restrain yourself a bit. Ciao, -- FA Vor uns liegt ein weites Tal, die Sonne scheint - ein Glitzerstrahl.
Re: [arch-general] change in mount behaviour?
On Sun, Jan 29, 2012 at 10:02 PM, Heiko Baums li...@baums-on-web.de wrote: 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. You seem to possess the misconception that the existence of PA on a system is somehow in conflict with pro-audio software.
Re: [arch-general] change in mount behaviour?
On Sun, Jan 29, 2012 at 4:12 PM, Jan Steffens jan.steff...@gmail.com 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.
Re: [arch-general] change in mount behaviour?
^^^battery life
Re: [arch-general] change in mount behaviour?
On Sat, Jan 28, 2012 at 12:56 AM, Fons Adriaensen f...@linuxaudio.org 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 g.schli...@gmx.de 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
Re: [arch-general] change in mount behaviour?
Heiko, 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). On Sat, Jan 28, 2012 at 3:39 AM, Heiko Baums li...@baums-on-web.de wrote: 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. 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. 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. Whatever the difference [...] may be, this should give you a hint that there is something you are missing... http://www.pathname.com/fhs/pub/fhs-2.3.html#MEDIAMOUNTPOINT 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. 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 if a software doesn't follow those FHS you should file a bug report to upstream. This is a waste of time. The upstream developers are well aware of the FHS. If their apps violate it, it is intentional. -t
Re: [arch-general] change in mount behaviour?
Am Fri, 27 Jan 2012 21:21:01 -0600 schrieb C Anthony Risinger anth...@xtfx.me: 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 ... s, they seem to work OK ;-) Do I really need to repeat it? PulseAudio and ice1712? 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 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. And, no, it's not ALSA's fault like Lennart Poettering says, it's PulseAudios fault. And why should I trust other software by Lennart Poettering if he isn't able to get this one software working perfectly. And, yes, he tried to declare this PulseAudio crap as a standard. Heiko
Re: [arch-general] change in mount behaviour?
Am Sat, 28 Jan 2012 11:24:47 +0100 schrieb Tom Gundersen t...@jklm.no: 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
Re: [arch-general] change in mount behaviour?
On Sat, Jan 28, 2012 at 2:14 PM, Heiko Baums li...@baums-on-web.de wrote: 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. Have you tried after this fix was released: http://git.alsa-project.org/?p=alsa-lib.git;a=commitdiff;h=d3906a93072171e5b5f4000d4a228af4eb8fa253? 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? Dunno. Depends on the bug. Point me at it and I'll fix it wherever it is. 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. The different usecases of /media and /mnt are explained in the FHS link you provided. 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! 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. What about first rewriting the FHS first to make it up-to-date again and only then using this new FHS? 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. Until then the FHS should be fully respected. If you say so... Come on, if this was really true then the FHS would have already been rewritten by those guys. So this is nonesense. It is: http://lists.linuxfoundation.org/pipermail/fhs-discuss/2011-May/01.html. Note how they hope to be finished by July 1, but conveniently forget to mention what year ;-) But fear not, they have almost agreed on the color of the bikeshed, the rest is expected to follow shortly. And, btw., I don't see any point in which the FHS doesn't work anymore. But maybe you can explain this, too. I'm sure Google will point you at plenty of discussions on this subject. 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. I meant that it is intentional by the software developers, not by the FHS committee. But don't take my word for it, try to file your bugs upstream and see what happens. -t
Re: [arch-general] change in mount behaviour?
OT: PulseAudio On Sat, 2012-01-28 at 14:02 +0100, Heiko Baums wrote: Am Fri, 27 Jan 2012 21:21:01 -0600 schrieb C Anthony Risinger anth...@xtfx.me: 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 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
Re: [arch-general] change in mount behaviour?
Am Sat, 28 Jan 2012 15:09:30 +0100 schrieb Tom Gundersen t...@jklm.no: Have you tried after this fix was released: http://git.alsa-project.org/?p=alsa-lib.git;a=commitdiff;h=d3906a93072171e5b5f4000d4a228af4eb8fa253? 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
Re: [arch-general] change in mount behaviour?
On Sat, Jan 28, 2012 at 05:29:51PM +0100, Heiko Baums wrote: 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. If you would call it the designer of an average car's fault that you can't transport a grand piano in it. 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. If you use such cards you probably have Jack running, and if you really want PA you can configure it as a Jack client. Ciao, -- FA Vor uns liegt ein weites Tal, die Sonne scheint - ein Glitzerstrahl.
Re: [arch-general] change in mount behaviour?
On Sat, Jan 28, 2012 at 6:05 PM, Fons Adriaensen f...@linuxaudio.org 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
Re: [arch-general] change in mount behaviour?
On Sat, Jan 28, 2012 at 5:29 PM, Heiko Baums li...@baums-on-web.de wrote: 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. 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. -t
Re: [arch-general] change in mount behaviour?
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 t...@jklm.no:
Have you tried after this fix was released:
http://git.alsa-project.org/?p=alsa-lib.git;a=commitdiff;h=d3906a93072171e5b5f4000d4a228af4eb8fa253?
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]
Re: [arch-general] change in mount behaviour?
On Sat, 2012-01-28 at 18:30 +0100, Tom Gundersen wrote: On Sat, Jan 28, 2012 at 6:05 PM, Fons Adriaensen f...@linuxaudio.org 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
Re: [arch-general] change in mount behaviour?
On Sat, Jan 28, 2012 at 7:59 PM, Ralf Mardorf ralf.mard...@alice-dsl.net 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
Re: [arch-general] change in mount behaviour?
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.
Re: [arch-general] change in mount behaviour?
On Sat, 2012-01-28 at 20:40 +, 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 UIDPID 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
Re: [arch-general] change in mount behaviour?
On Sat, 28 Jan 2012 20:40:51 + Fons Adriaensen f...@linuxaudio.org 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 signature.asc Description: PGP signature
Re: [arch-general] change in mount behaviour?
On Sat, 28 Jan 2012 22:37:37 +0100 Ralf Mardorf ralf.mard...@alice-dsl.net wrote: On Sat, 2012-01-28 at 20:40 +, 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 UIDPID 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
Re: [arch-general] change in mount behaviour?
On Sat, Jan 28, 2012 at 03:41:06PM -0600, Leonid Isaev wrote: http://www.gnu.org/software/emacs/NEWS.23.2 This doesn't provide any reason why emacs should depend on consolekit for its functionality. It only says it depends on gconf to find out a 'default font', and that you can opt out at compile time. I may depend on my local garage to keep my car in order, but that doesn't mean I have to depend on it for anything else. I don't have to buy my carrots where the mechanic gets them. Things like gconf impose an 'all or nothing' dependency and that is where it all goes wrong, and why no app should have a compiled-in dependency on them. It's easy enough to make this a run-time choice. Ciao, -- FA Vor uns liegt ein weites Tal, die Sonne scheint - ein Glitzerstrahl.
Re: [arch-general] change in mount behaviour?
On Sat, Jan 28, 2012 at 10:37 PM, Ralf Mardorf ralf.mard...@alice-dsl.net wrote: On Sat, 2012-01-28 at 20:40 +, 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 ?
Re: [arch-general] change in mount behaviour?
On Jan 29, 2012 3:29 AM, Tom Gundersen t...@jklm.no wrote: On Sat, Jan 28, 2012 at 7:59 PM, Ralf Mardorf ralf.mard...@alice-dsl.net 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
Re: [arch-general] change in mount behaviour?
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. georg # mount tmpfs on /media type tmpfs (rw,nosuid,nodev,noexec,relatime,mode=755) ok, but thats one half only…
Re: [arch-general] change in mount behaviour?
On Sat, 28 Jan 2012 00:26:38 +0100 G. Schlisio g.schli...@gmx.de 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? -- Leonid Isaev GnuPG key ID: 164B5A6D Key fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D signature.asc Description: PGP signature
Re: [arch-general] change in mount behaviour?
Am 28.01.2012 00:46, schrieb Leonid Isaev: On Sat, 28 Jan 2012 00:26:38 +0100 G. Schlisiog.schli...@gmx.de 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.
Re: [arch-general] change in mount behaviour?
On Sat, Jan 28, 2012 at 12:35 AM, G. Schlisio g.schli...@gmx.de 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
Re: [arch-general] change in mount behaviour?
On Sat, Jan 28, 2012 at 12:50:09AM +0100, Tom Gundersen wrote: On Sat, Jan 28, 2012 at 12:35 AM, G. Schlisio g.schli...@gmx.de 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. Ciao, -- FA Vor uns liegt ein weites Tal, die Sonne scheint - ein Glitzerstrahl.
Re: [arch-general] change in mount behaviour?
On Sat, 28 Jan 2012 00:49:03 +0100 G. Schlisio g.schli...@gmx.de wrote: Am 28.01.2012 00:46, schrieb Leonid Isaev: On Sat, 28 Jan 2012 00:26:38 +0100 G. Schlisiog.schli...@gmx.de 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? -- Leonid Isaev GnuPG key ID: 164B5A6D Key fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D signature.asc Description: PGP signature
Re: [arch-general] change in mount behaviour?
Am 28.01.2012 01:02, schrieb Leonid Isaev: On Sat, 28 Jan 2012 00:49:03 +0100 G. Schlisiog.schli...@gmx.de wrote: Am 28.01.2012 00:46, schrieb Leonid Isaev: On Sat, 28 Jan 2012 00:26:38 +0100 G. Schlisiog.schli...@gmx.de 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…
Re: [arch-general] change in mount behaviour?
On Fri, Jan 27, 2012 at 5:56 PM, Fons Adriaensen f...@linuxaudio.org 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
Re: [arch-general] change in mount behaviour?
Am Fri, 27 Jan 2012 19:41:54 -0600 schrieb C Anthony Risinger anth...@xtfx.me: On Fri, Jan 27, 2012 at 5:56 PM, Fons Adriaensen f...@linuxaudio.org 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. under systemd, /media is a tmpfs. The same for systemd. 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 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. 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. Heiko
Re: [arch-general] change in mount behaviour?
On Fri, Jan 27, 2012 at 8:39 PM, Heiko Baums li...@baums-on-web.de wrote: Am Fri, 27 Jan 2012 19:41:54 -0600 schrieb C Anthony Risinger anth...@xtfx.me: On Fri, Jan 27, 2012 at 5:56 PM, Fons Adriaensen f...@linuxaudio.org 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 ... s, 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
