Re: [arch-general] [arch-announce] netcfg-2.8.9 drops initscripts compatibility
On 08/11/2012 11:28 PM, David Hunter wrote:
On Sat, Aug 11, 2012 at 1:01 PM, Arch Linux: Recent news updates:
URL:
http://www.archlinux.org/news/netcfg-289-drops-initscripts-compatibility/
The title of this article seems like it's going to cause a lot of
confusion and anger. [..]
Should be better now, thanks.
--
Florian Pritz -- {flo,bluewind}@server-speed.net
signature.asc
Description: OpenPGP digital signature
Re: [arch-general] What can be deleted, when not using systemd - was: polkit package upgrade patch
On 11 August 2012 23:05, Baho Utot baho-u...@columbus.rr.com wrote: systemd is one source distributed package arch split the package into the multiples you see here. It is one source package, but it provides multiple small utilities. The coreutils are distributed as one source package that provides many small utilities, too. It doesn't run on my android device nor would it be needed or required. That doesn't mean it cannot be used as such. Lukas
Re: [arch-general] OT: [arch-dev-public] polkit package upgrade patch
On 12 August 2012 02:47, Tom Gundersen t...@jklm.no wrote: On Sun, Aug 12, 2012 at 2:05 AM, Fons Adriaensen f...@linuxaudio.org wrote: This is completely sick. Any audio engineer trying to use a mixer that way would (and should) be fired for gross incompetence - immediately. Argument by authority, nice. Care to elaborate? (Sorry to anyone who is sick of PA, but for once I'm seeing the chance to learn something from one of these threads ;-)). If the problem is too complex to explain in layman terms, that's understandable. However, is the problem one that would be unacceptable in a professional setting (e.g. a recording studio, ...) as it would cause subtle issues. Or is it a problem that I should be able to observe on my crappy speakers at home? If so, what am I listening for? How would I go about reproducing it? Cheers, Tom One of my friends is an amateur musician. He told me about some problems that makes PA unusable for his work. First, it is having unpredictable latencies and size of buffers. And the second one was similar to the question – it was having one master channels instead of many mixers provided by card. I don't remember the exact reasons why it was bad though. I think it has something to do with small changes in the audio signal that may be raised by the connected equipment. Lukas
Re: [arch-general] What can be deleted, when not using systemd - was: polkit package upgrade patch
I suspect upstream folks are living in an ivory tower. Nouveau, PA, systemd, GNOME3, GIMP etc. and regarding to GIMP somebody posted those links. It's worth to read it, since it's not about GIMP only, but about the communication between users and upstream. Forwarded Message To: Debian User You might enjoy this three-part thread... http://lists.fedoraproject.org/pipermail/test/2012-April/107586.html http://lists.fedoraproject.org/pipermail/test/2012-April/107603.html http://lists.fedoraproject.org/pipermail/test/2012-May/107697.html
Re: [arch-general] OT: [arch-dev-public] polkit package upgrade patch
On Sun, Aug 12, 2012 at 02:47:59AM +0200, Tom Gundersen wrote: Argument by authority, nice. Care to elaborate? (Sorry to anyone who is sick of PA, but for once I'm seeing the chance to learn something from one of these threads ;-)). No authority needed here, it's just extremely clumsy to use a mixer that way, you'd need ten hands. For it means that whenever you want to adjust a single channnel you may have to adjust *all* others and the master at the same time. If the problem is too complex to explain in layman terms, that's understandable. However, is the problem one that would be unacceptable in a professional setting (e.g. a recording studio, ...) as it would cause subtle issues. Or is it a problem that I should be able to observe on my crappy speakers at home? If so, what am I listening for? How would I go about reproducing it? [1] The first and sufficient argument is that is completely *unnecessary* to do such things. Assume you have two or more apps producing sound, and one of them (A) has its volume set to max, so PA will set the master fader to max. Assume things are OK that way (which will probably be the case). Things will still work well when (A) happens to contribute nothing (i.e. while it outputs silence). So things will still work well when (A) isn't there at all. *There is no need to change anything at all* when (A) goes away, even if all others have their volume set to lower values. [2] As to technical arguments, I can try. First thing to know is that you shouldn't confuse 'level' (a property of signal), and 'gain' (the ratio of two levels, or difference if you think in dB). Both are usually expressed in dB, but that doesn't make them the same thing. Compare it to time: a instant (epoch) and a duration are both expressed in the same units but they are different things. For example the sum of two epochs doesn't have any meaning, while the sum of two durations has. And if some activity has a duration of 40 minutes, that doesn't mean it has to finish at 00:40. Similarly, if an apps has its gain set to -10 dB, that should not be taken to imply that it can't output more than -10 dB. On 'real' mixers (digital or analog) you normally have considerable 'headroom'. Setting your master fader to -20 dB does not mean you can't output more than -20 dB. For digital ones that means that they use internally a wider format (more bits) than on the external interfaces. So you can actually trade off input gains and master gain to some extent. Soundcard mixers are different. The PCM input to the mixer (i.e. the samples the SW provides) usually has the same format as the AD converter, e.g. 16 or 24 bits. That means that if the master is set to e.g. -20 dB, the card can't output any signal that is larger than -20 dB (w.r.t. its normal maximum level). Which is wrong. Assume you have two or more apps, all of them have their volume set to -20 dB. So PA will set the master output to -20 dB. Now even if all of these apps are limited to contributing -20 dB (but there is no reason why that should be), the sum of them can be higher, but your soundcard can't handle that. It all amounts to this: unless the user is using the soundcard's 'master' as his global volume control (similar to a volume knob on an external amplifier) it should be left at 0 dB. No software layer should ever touch it. [3] On many soundcards the master fader also controls the level of things that PA or any software layer doesn't know about, e.g. and external mic input. Which you'd use for karaoke, or to hear yourself in your headphones while skyping. That level must not depend on how other apps set their volume controls. Again the software should not touch the master gain. [4] You can't apply a soundcard mixer gain change at some exact point in a sample stream. So you can't change the master gain and change your internal scaling to compensate at exactly the same time. There will always be a glitch. -- FA A world of exhaustive, reliable metadata would be an utopia. It's also a pipe-dream, founded on self-delusion, nerd hubris and hysterically inflated market opportunities. (Cory Doctorow)
Re: [arch-general] OT: [arch-dev-public] polkit package upgrade patch
On Sun, 2012-08-12 at 13:07 +, Fons Adriaensen wrote: [4] You can't apply a soundcard mixer gain change at some exact point in a sample stream. So you can't change the master gain and change your internal scaling to compensate at exactly the same time. There will always be a glitch. That's the important point. And because look ahead for a realtime livestream is impossible without a time machine, you need to lower the level with a guess about the needed headroom, before you increase the other level, assumed we are near at margin of full scale.
Re: [arch-general] OT: [arch-dev-public] polkit package upgrade patch
On Sun, 2012-08-12 at 15:27 +0200, Ralf Mardorf wrote: On Sun, 2012-08-12 at 13:07 +, Fons Adriaensen wrote: [4] You can't apply a soundcard mixer gain change at some exact point in a sample stream. So you can't change the master gain and change your internal scaling to compensate at exactly the same time. There will always be a glitch. That's the important point. And because look ahead for a realtime livestream is impossible without a time machine, you need to lower the level with a guess about the needed headroom, before you increase the other level, assumed we are near at margin of full scale. Or is it possible for software to be that fast, that it doesn't matter? Perhaps a look ahead is possible?
Re: [arch-general] OT: [arch-dev-public] polkit package upgrade patch
On Sun, 2012-08-12 at 15:31 +0200, Ralf Mardorf wrote: On Sun, 2012-08-12 at 15:27 +0200, Ralf Mardorf wrote: On Sun, 2012-08-12 at 13:07 +, Fons Adriaensen wrote: [4] You can't apply a soundcard mixer gain change at some exact point in a sample stream. So you can't change the master gain and change your internal scaling to compensate at exactly the same time. There will always be a glitch. That's the important point. And because look ahead for a realtime livestream is impossible without a time machine, you need to lower the level with a guess about the needed headroom, before you increase the other level, assumed we are near at margin of full scale. Or is it possible for software to be that fast, that it doesn't matter? Perhaps a look ahead is possible? I know it anyway would cause a glitch, but perhaps that the volume can't be set at an exact point is for consumer usage quasi inaudible?
Re: [arch-general] OT: [arch-dev-public] polkit package upgrade patch
On Sun, Aug 12, 2012 at 3:07 PM, Fons Adriaensen f...@linuxaudio.org wrote: it's just extremely clumsy to use a mixer that way, you'd need ten hands. For it means that whenever you want to adjust a single channnel you may have to adjust *all* others and the master at the same time. Unlike humans, computers does not have a limited number of hands. This is not a priori a problem. [1] The first and sufficient argument is that is completely *unnecessary* to do such things. Assume you have two or more apps producing sound, and one of them (A) has its volume set to max, so PA will set the master fader to max. Assume things are OK that way (which will probably be the case). Things will still work well when (A) happens to contribute nothing (i.e. while it outputs silence). So things will still work well when (A) isn't there at all. *There is no need to change anything at all* when (A) goes away, even if all others have their volume set to lower values. You have showed that it is unnecessary in one particular (very simple) case. However, you have not showed that it is unnecessary in all cases, so this is not really relevant (had we been talking about a human doing this, you'd have a point of course). [2] As to technical arguments, I can try. First thing to know is that you shouldn't confuse 'level' (a property of signal), and 'gain' (the ratio of two levels, or difference if you think in dB). Both are usually expressed in dB, but that doesn't make them the same thing. Compare it to time: a instant (epoch) and a duration are both expressed in the same units but they are different things. For example the sum of two epochs doesn't have any meaning, while the sum of two durations has. And if some activity has a duration of 40 minutes, that doesn't mean it has to finish at 00:40. Similarly, if an apps has its gain set to -10 dB, that should not be taken to imply that it can't output more than -10 dB. On 'real' mixers (digital or analog) you normally have considerable 'headroom'. Setting your master fader to -20 dB does not mean you can't output more than -20 dB. For digital ones that means that they use internally a wider format (more bits) than on the external interfaces. So you can actually trade off input gains and master gain to some extent. Soundcard mixers are different. The PCM input to the mixer (i.e. the samples the SW provides) usually has the same format as the AD converter, e.g. 16 or 24 bits. That means that if the master is set to e.g. -20 dB, the card can't output any signal that is larger than -20 dB (w.r.t. its normal maximum level). Which is wrong. Assume you have two or more apps, all of them have their volume set to -20 dB. This all makes sense. Thanks. So PA will set the master output to -20 dB. Now even if all of these apps are limited to contributing -20 dB (but there is no reason why that should be), the sum of them can be higher, but your soundcard can't handle that. That clearly would not work. Surely PA would need to adjust the master output to compensate for the number of channels? I don't know these implementation details, but I don't see how your arguments shows that this is impossible in general, just that the algorithm you outlined does not work. [3] On many soundcards the master fader also controls the level of things that PA or any software layer doesn't know about, e.g. and external mic input. Which you'd use for karaoke, or to hear yourself in your headphones while skyping. That level must not depend on how other apps set their volume controls. Again the software should not touch the master gain. On soundcards where this is the case, then clearly this must be taken into account. However, that is not impossible. Either the information is given by ALSA, or a quirks table is needed. That does not mean that the general approach cannot work. [4] You can't apply a soundcard mixer gain change at some exact point in a sample stream. So you can't change the master gain and change your internal scaling to compensate at exactly the same time. There will always be a glitch. Ok. This is what I was wondering about. I will try to listen for glitches then (I have not noticed any during my years of using PA, but I'll pay more attention). If it is true that a noticeable glitch is produced, then obviously you have a point, however if the glitch is not noticeable then I don't see the problem you have with PA. Clearly, PA is not meant for professional audio work. And it might be that for a professional all the PA logic is both unnecessary and maybe even detrimental (so you'd use jack or pure ALSA instead, that should not be a problem). However, that does not mean that PA is not a huge gain for the casual desktop user (assuming there are no bugs!). Thanks for the information. Tom
Re: [arch-general] OT: [arch-dev-public] polkit package upgrade patch
On Sun, 2012-08-12 at 16:00 +0200, Tom Gundersen wrote: Ok. This is what I was wondering about. I will try to listen for glitches then (I have not noticed any during my years of using PA, but I'll pay more attention). If it is true that a noticeable glitch is produced, then obviously you have a point, however if the glitch is not noticeable then I don't see the problem you have with PA. Clearly, PA is not meant for professional audio work. And it might be that for a professional all the PA logic is both unnecessary and maybe even detrimental (so you'd use jack or pure ALSA instead, that should not be a problem). However, that does not mean that PA is not a huge gain for the casual desktop user (assuming there are no bugs!). Thanks for the information. I was a pro analog audio engineer, working for an important company. I tried some stupid guesses, regarding to nowadays digital. IMO it's imaginable, even if some of my thoughts should be absolutely wrong, that for consumer usage, there quasi aren't audible steps. Anyway, PA isn't needed, so it should be an optional dependency. And it might work or not, the way it's done is insane. Analog audio engineers only have got two hands + flying faders :D, anyway, Fon's claim that it's sick, not sane or what ever he said is correct. There is a logical way to do such stuff with two hands only, without flying faders. Why should software not use this better style too? 2 cents, Ralf
Re: [arch-general] What can be deleted, when not using systemd - was: polkit package upgrade patch
On 12 Aug 2012 20:51, Ralf Mardorf ralf.mard...@alice-dsl.net wrote: I suspect upstream folks are living in an ivory tower. Nouveau, PA, systemd, GNOME3, GIMP etc. and regarding to GIMP somebody posted those links. It's worth to read it, since it's not about GIMP only, but about the communication between users and upstream. I suspect that some users have a huge sense of entitlement. Thoroughly undeserved. The users are not the most important component of an open source project, not even close. And any neutral party reading the gimp mailing list currently would identify the majority of the complaints to be unreasonable since they amount to this change sucks, change it back or we'll stop using this software.
Re: [arch-general] OT: [arch-dev-public] polkit package upgrade patch
On Sun, Aug 12, 2012 at 04:00:47PM +0200, Tom Gundersen wrote: On Sun, Aug 12, 2012 at 3:07 PM, Fons Adriaensen f...@linuxaudio.org wrote: it's just extremely clumsy to use a mixer that way, you'd need ten hands. For it means that whenever you want to adjust a single channnel you may have to adjust *all* others and the master at the same time. Unlike humans, computers does not have a limited number of hands. This is not a priori a problem. It's still like trying to start a 10-ton truck in 5th gear. If you do that on your first day on the job you'll be fired, not because your boss likes to show his authority but because you have shown your incompetence. And if a computerized system tries to do that (and maybe it could if it has very fine control over the engine and clutch) then there's clearly something wrong with it. Things will still work well when (A) happens to contribute nothing (i.e. while it outputs silence). So things will still work well when (A) isn't there at all. *There is no need to change anything at all* when (A) goes away, even if all others have their volume set to lower values. You have showed that it is unnecessary in one particular (very simple) case. However, you have not showed that it is unnecessary in all cases, so this is not really relevant (had we been talking about a human doing this, you'd have a point of course). It is never necessary. It it were that would imply that a sound card without any gain controls (equivalent to a fixed 0 dB gain) would fail in some cases. It doesn't. In fact many PRO cards are just like that. If you have apps A, B, C with volumes a, b, c you can always set the HW gain to unity gain (0dB), and send s = a * A + b * B + c * C (1) to the soundcard. What would be the advantage of doing what PA does, which is * m = maximum of a, b, c) * Set the master to m, * send s = a/m * A + b/m * B + c/m * C(2) ??? It can only generate trouble, basically you forfeit any headroom the system would have. So PA will set the master output to -20 dB. Now even if all of these apps are limited to contributing -20 dB (but there is no reason why that should be), the sum of them can be higher, but your soundcard can't handle that. That clearly would not work. Surely PA would need to adjust the master output to compensate for the number of channels? I don't know these implementation details, but I don't see how your arguments shows that this is impossible in general, just that the algorithm you outlined does not work. PA could leave some headroom and even adjust that in function of the number of sources. But it could also just leave the master gain alone, and compute (1) above instead of (2). Any advantage you or any user have from using PA 'things just work' would remain the same. But it's a lot simpler and doesn't have the problems (2) has. -- FA A world of exhaustive, reliable metadata would be an utopia. It's also a pipe-dream, founded on self-delusion, nerd hubris and hysterically inflated market opportunities. (Cory Doctorow)
Re: [arch-general] OT: [arch-dev-public] polkit package upgrade patch
On Sun, Aug 12, 2012 at 04:00:47PM +0200, Tom Gundersen wrote: You have showed that it is unnecessary in one particular (very simple) case. However, you have not showed that it is unnecessary in all cases, so this is not really relevant (had we been talking about a human doing this, you'd have a point of course). I suspect that mathematical thinking is not your thing - no problem. For otherwise it would be clear that the 'simple' example I provided covers the general case. Let me try again. I write a PA-aware sound app X that * always sets its volume to 0 dB (max). * always outputs silence (zero valued samples). As soon as that app runs, PA will set the master gain to 0 dB and use software scaling on all other apps. Now there are two possibilities: * Either everything is OK (it will be), and we have shown that you can always leave the master gain at 0 dB, * or everything is not OK, and we have shown that PA fails. Ciao, -- FA A world of exhaustive, reliable metadata would be an utopia. It's also a pipe-dream, founded on self-delusion, nerd hubris and hysterically inflated market opportunities. (Cory Doctorow)
Re: [arch-general] OT: [arch-dev-public] polkit package upgrade patch
On Sun, 12 Aug 2012 15:01:06 + Fons Adriaensen f...@linuxaudio.org wrote: On Sun, Aug 12, 2012 at 04:00:47PM +0200, Tom Gundersen wrote: On Sun, Aug 12, 2012 at 3:07 PM, Fons Adriaensen f...@linuxaudio.org wrote: it's just extremely clumsy to use a mixer that way, you'd need ten hands. For it means that whenever you want to adjust a single channnel you may have to adjust *all* others and the master at the same time. Unlike humans, computers does not have a limited number of hands. This is not a priori a problem. It's still like trying to start a 10-ton truck in 5th gear. If you do that on your first day on the job you'll be fired, not because your boss likes to show his authority but because you have shown your incompetence. And if a computerized system tries to do that (and maybe it could if it has very fine control over the engine and clutch) then there's clearly something wrong with it. Things will still work well when (A) happens to contribute nothing (i.e. while it outputs silence). So things will still work well when (A) isn't there at all. *There is no need to change anything at all* when (A) goes away, even if all others have their volume set to lower values. You have showed that it is unnecessary in one particular (very simple) case. However, you have not showed that it is unnecessary in all cases, so this is not really relevant (had we been talking about a human doing this, you'd have a point of course). It is never necessary. It it were that would imply that a sound card without any gain controls (equivalent to a fixed 0 dB gain) would fail in some cases. It doesn't. In fact many PRO cards are just like that. If you have apps A, B, C with volumes a, b, c you can always set the HW gain to unity gain (0dB), and send s = a * A + b * B + c * C (1) Let me see if I understand. Capital A, B and C are bare intensities (in watts or logarithmic scale) sent from an app? If those are arbitrarily large, how do you make sure your speaker is not going to blow up? to the soundcard. What would be the advantage of doing what PA does, which is * m = maximum of a, b, c) * Set the master to m, * send s = a/m * A + b/m * B + c/m * C(2) ??? It can only generate trouble, basically you forfeit any headroom the system would have. So, the intention is to normalize to the loudest app? So PA will set the master output to -20 dB. Now even if all of these apps are limited to contributing -20 dB (but there is no reason why that should be), the sum of them can be higher, but your soundcard can't handle that. That clearly would not work. Surely PA would need to adjust the master output to compensate for the number of channels? I don't know these implementation details, but I don't see how your arguments shows that this is impossible in general, just that the algorithm you outlined does not work. PA could leave some headroom and even adjust that in function of the number of sources. But it could also just leave the master gain alone, and compute (1) above instead of (2). Any advantage you or any user have from using PA 'things just work' would remain the same. But it's a lot simpler and doesn't have the problems (2) has. -- Leonid Isaev GnuPG key: 0x164B5A6D Fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D signature.asc Description: PGP signature
Re: [arch-general] OT: [arch-dev-public] polkit package upgrade patch
On Sun, Aug 12, 2012 at 5:27 PM, Fons Adriaensen f...@linuxaudio.org wrote: On Sun, Aug 12, 2012 at 04:00:47PM +0200, Tom Gundersen wrote: You have showed that it is unnecessary in one particular (very simple) case. However, you have not showed that it is unnecessary in all cases, so this is not really relevant (had we been talking about a human doing this, you'd have a point of course). I suspect that mathematical thinking is not your thing - no problem. For otherwise it would be clear that the 'simple' example I provided covers the general case. Let me try again. I write a PA-aware sound app X that * always sets its volume to 0 dB (max). * always outputs silence (zero valued samples). As soon as that app runs, PA will set the master gain to 0 dB and use software scaling on all other apps. Now there are two possibilities: * Either everything is OK (it will be), and we have shown that you can always leave the master gain at 0 dB, * or everything is not OK, and we have shown that PA fails. Your argument was clear (I'm ok with maths :) ). I was just pointing out that the case where the hardware can always be set to 0dB is not the interesting one. You clearly want to avoid setting the hardware to 0dB if possible, but sometimes it is not possible (because you can't hear anything ;) ) so you have to have an algorithm to do it in the best way. Imagine you have two streams (A) which needs no software nor hardware gain, had it been played alone, and (B) which forces the hardware gain to be 0dB (and (A) to be scaled down in sw). If (B) goes away you clearly want to set the hw volume back to 0 and (A) to stop being scaled in sw. The second case, where the total gain should be 0dB, I would have thought intuitively that doing this purely in software (especially on very faint signals) would be less ideal than doing it in hw (you'd be throwing away the resolution, wouldn't you?), but I'll admit that I don't have the experience to talk about that with any authority. -t
Re: [arch-general] OT: [arch-dev-public] polkit package upgrade patch
On Sun, 12 Aug 2012 13:07:32 + Fons Adriaensen f...@linuxaudio.org wrote: On Sun, Aug 12, 2012 at 02:47:59AM +0200, Tom Gundersen wrote: Argument by authority, nice. Care to elaborate? (Sorry to anyone who is sick of PA, but for once I'm seeing the chance to learn something from one of these threads ;-)). No authority needed here, it's just extremely clumsy to use a mixer that way, you'd need ten hands. For it means that whenever you want to adjust a single channnel you may have to adjust *all* others and the master at the same time. If the problem is too complex to explain in layman terms, that's understandable. However, is the problem one that would be unacceptable in a professional setting (e.g. a recording studio, ...) as it would cause subtle issues. Or is it a problem that I should be able to observe on my crappy speakers at home? If so, what am I listening for? How would I go about reproducing it? [1] The first and sufficient argument is that is completely *unnecessary* to do such things. Assume you have two or more apps producing sound, and one of them (A) has its volume set to max, so PA will set the master fader to max. Assume things are OK that way (which will probably be the case). Things will still work well when (A) happens to contribute nothing (i.e. while it outputs silence). So things will still work well when (A) isn't there at all. *There is no need to change anything at all* when (A) goes away, even if all others have their volume set to lower values. [2] As to technical arguments, I can try. First thing to know is that you shouldn't confuse 'level' (a property of signal), and 'gain' (the ratio of two levels, or difference if you think in dB). Both are usually expressed in dB, but that doesn't make them the same thing. Compare it to time: a instant (epoch) and a duration are both expressed in the same units but they are different things. For example the sum of two epochs doesn't have any meaning, while the sum of two durations has. And if some activity has a duration of 40 minutes, that doesn't mean it has to finish at 00:40. Similarly, if an apps has its gain set to -10 dB, that should not be taken to imply that it can't output more than -10 dB. On 'real' mixers (digital or analog) you normally have considerable 'headroom'. Setting your master fader to -20 dB does not mean you can't output more than -20 dB. For digital ones that means that they use internally a wider format (more bits) than on the external interfaces. So you can actually trade off input gains and master gain to some extent. Soundcard mixers are different. The PCM input to the mixer (i.e. the samples the SW provides) usually has the same format as the AD converter, e.g. 16 or 24 bits. That means that if the master is set to e.g. -20 dB, the card can't output any signal that is larger than -20 dB (w.r.t. its normal maximum level). Which is wrong. Assume you have two or more apps, all of them have their volume set to -20 dB. So PA will set the master output to -20 dB. Now even if all of these apps are limited to contributing -20 dB (but there is no reason why that should be), the sum of them can be higher, but your soundcard can't handle that. It all amounts to this: unless the user is using the soundcard's 'master' as his global volume control (similar to a volume knob on an external amplifier) it should be left at 0 dB. No software layer should ever touch it. So... on my intel AD I have PCM and Master knobs (in alsa). Are you saying that I should set Master to max (-0dB) and control volume through PCM only? [3] On many soundcards the master fader also controls the level of things that PA or any software layer doesn't know about, e.g. and external mic input. Which you'd use for karaoke, or to hear yourself in your headphones while skyping. That level must not depend on how other apps set their volume controls. Again the software should not touch the master gain. [4] You can't apply a soundcard mixer gain change at some exact point in a sample stream. So you can't change the master gain and change your internal scaling to compensate at exactly the same time. There will always be a glitch. -- Leonid Isaev GnuPG key: 0x164B5A6D Fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D signature.asc Description: PGP signature
Re: [arch-general] OT: [arch-dev-public] polkit package upgrade patch
On Sun, Aug 12, 2012 at 5:01 PM, Fons Adriaensen f...@linuxaudio.org wrote: If you have apps A, B, C with volumes a, b, c you can always set the HW gain to unity gain (0dB), and send s = a * A + b * B + c * C (1) to the soundcard. What would be the advantage of doing what PA does, which is * m = maximum of a, b, c) * Set the master to m, * send s = a/m * A + b/m * B + c/m * C(2) Take a=0.1 (or some other sufficiently small number), b=2*a and c=3*a. You then risk that with (1) you have s=0 due to rounding errors, whilst with (2) s0. How big a problem this is in practice, I don't know. I'm a mathematician, and not a sound engineer. -t
Re: [arch-general] OT: [arch-dev-public] polkit package upgrade patch
On Sun, 12 Aug 2012 18:02:59 +0200 Tom Gundersen t...@jklm.no wrote: On Sun, Aug 12, 2012 at 5:27 PM, Fons Adriaensen f...@linuxaudio.org wrote: On Sun, Aug 12, 2012 at 04:00:47PM +0200, Tom Gundersen wrote: You have showed that it is unnecessary in one particular (very simple) case. However, you have not showed that it is unnecessary in all cases, so this is not really relevant (had we been talking about a human doing this, you'd have a point of course). I suspect that mathematical thinking is not your thing - no problem. For otherwise it would be clear that the 'simple' example I provided covers the general case. Let me try again. I write a PA-aware sound app X that * always sets its volume to 0 dB (max). * always outputs silence (zero valued samples). As soon as that app runs, PA will set the master gain to 0 dB and use software scaling on all other apps. Now there are two possibilities: * Either everything is OK (it will be), and we have shown that you can always leave the master gain at 0 dB, * or everything is not OK, and we have shown that PA fails. Your argument was clear (I'm ok with maths :) ). I was just pointing out that the case where the hardware can always be set to 0dB is not the interesting one. You clearly want to avoid setting the hardware to 0dB if possible, Correct me if I'm wrong but I don't think that's possible, because dB is normalized to max power (in watts = intensity). but sometimes it is not possible (because you can't hear anything ;) ) so you have to have an algorithm to do it in the best way. Imagine you have two streams (A) which needs no software nor hardware gain, had it been played alone, and (B) which forces the hardware gain to be 0dB (and (A) to be scaled down in sw). If (B) goes away you clearly want to set the hw volume back to 0 and (A) to stop being scaled in sw. The second case, where the total gain should be 0dB, I would have thought intuitively that doing this purely in software (especially on very faint signals) would be less ideal than doing it in hw (you'd be throwing away the resolution, wouldn't you?), but I'll admit that I don't have the experience to talk about that with any authority. -t -- Leonid Isaev GnuPG key: 0x164B5A6D Fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D signature.asc Description: PGP signature
Re: [arch-general] OT: [arch-dev-public] polkit package upgrade patch
On Sun, Aug 12, 2012 at 6:07 PM, Leonid Isaev lis...@umail.iu.edu wrote: So... on my intel AD I have PCM and Master knobs (in alsa). Are you saying that I should set Master to max (-0dB) and control volume through PCM only? FWIW, on my intel soundcard I have Master, PCM and Front. When I change the system volume with PA it adjusts mainly Master, and keeps PCM and Front around 0dB (only adjusting them a bit to get higher resolution on the volume slider than what Master can provide). -t
Re: [arch-general] OT: [arch-dev-public] polkit package upgrade patch
On Sun, Aug 12, 2012 at 6:10 PM, Leonid Isaev lis...@umail.iu.edu wrote: Correct me if I'm wrong but I don't think that's possible, because dB is normalized to max power (in watts = intensity). If I understand correctly, 0dB is don't apply any gain. On some chips, that's indeed the same as max, but I have had several laptops where that is not the case. -t
Re: [arch-general] OT: [arch-dev-public] polkit package upgrade patch
On Sun, 2012-08-12 at 18:02 +0200, Tom Gundersen wrote: The second case, where the total gain should be 0dB, I would have thought intuitively that doing this purely in software (especially on very faint signals) would be less ideal than doing it in hw (you'd be throwing away the resolution, wouldn't you?), but I'll admit that I don't have the experience to talk about that with any authority. It's a common misconception that keeping the level lower than 0dB would lead to less resolution. It depends to the sampling rate and bit depth and less to the level control.
Re: [arch-general] OT: [arch-dev-public] polkit package upgrade patch
On Sun, 2012-08-12 at 18:15 +0200, Ralf Mardorf wrote: On Sun, 2012-08-12 at 11:10 -0500, Leonid Isaev wrote: Correct me if I'm wrong but I don't think that's possible, because dB is normalized to max power (in watts = intensity). You can boost a signal. ... 0dB for the result of an analog signal, you also can boost a digital signal, just the result needs to be = 0dBFS for digital. For digital there's dB full-scale square wave and dB full-scale sine wave. http://en.wikipedia.org/wiki/DBFS
Re: [arch-general] OT: [arch-dev-public] polkit package upgrade patch
On 08/12/2012 10:00 AM, Tom Gundersen wrote: [putolin] Clearly, PA is not meant for professional audio work. And it might be that for a professional all the PA logic is both unnecessary and maybe even detrimental (so you'd use jack or pure ALSA instead, that should not be a problem). However, that does not mean that PA is not a huge gain for the casual desktop user (assuming there are no bugs!). Thanks for the information. Tom What is pulse audio suppose to do? I still don't know what problem it was trying to solve as just plain alsa works for me.
Re: [arch-general] OT: [arch-dev-public] polkit package upgrade patch
On Sun, 2012-08-12 at 12:43 -0400, Baho Utot wrote: On 08/12/2012 10:00 AM, Tom Gundersen wrote: [putolin] Clearly, PA is not meant for professional audio work. And it might be that for a professional all the PA logic is both unnecessary and maybe even detrimental (so you'd use jack or pure ALSA instead, that should not be a problem). However, that does not mean that PA is not a huge gain for the casual desktop user (assuming there are no bugs!). Thanks for the information. Tom What is pulse audio suppose to do? It automatically should handle audio streams for your desktop. Polypaudio should grab everything :(.
Re: [arch-general] OT: [arch-dev-public] polkit package upgrade patch
On 12-08-2012 17:11, Ralf Mardorf wrote: On Sun, 2012-08-12 at 18:02 +0200, Tom Gundersen wrote: The second case, where the total gain should be 0dB, I would have thought intuitively that doing this purely in software (especially on very faint signals) would be less ideal than doing it in hw (you'd be throwing away the resolution, wouldn't you?), but I'll admit that I don't have the experience to talk about that with any authority. It's a common misconception that keeping the level lower than 0dB would lead to less resolution. It depends to the sampling rate and bit depth and less to the level control. Sampling rate would not matter to level discussions since it limits only the maximum frequency that can be properly sampled or reproduced. For the same bit depth a lower playback output level will yield a lower signal-to-noise or signal-to noise + distortion ratio, thus leading to the same effect of having a DAC of less resolution playing at full scale, so in a way you can say that for lower output levels you have less resolution. -- Mauro Santos
Re: [arch-general] OT: [arch-dev-public] polkit package upgrade patch
Fons Adriaensen wrote: It is never necessary. It it were that would imply that a sound card without any gain controls (equivalent to a fixed 0 dB gain) would fail in some cases. It doesn't. In fact many PRO cards are just like that. If you have apps A, B, C with volumes a, b, c you can always set the HW gain to unity gain (0dB), and send s = a * A + b * B + c * C (1) to the soundcard. What would be the advantage of doing what PA does, which is * m = maximum of a, b, c) * Set the master to m, * send s = a/m * A + b/m * B + c/m * C(2) ??? It can only generate trouble, basically you forfeit any headroom the system would have. Actually, that's one point where PA is right (even though it's wrong on a lot of other points): doing it like (2) avoids amplifying the quantification noise if the sound card applies the master gain in analog (or uses higher bit depths internally before the DACs as some do). When cascading amplifiers, it is always better to put the highest possible gain on the first stages (always leaving enough headroom to avoid clipping/distortion) so that later stages will not amplify the noise from the first stages (or so that they will reduce it along with the signal). The only case when this rule does not hold is when doing digital processing in floating point (because then the quantification noise is defined as a proportion of the actual signal instead of its potential maximum). Jerome -- mailto:jeber...@free.fr http://jeberger.free.fr Jabber: jeber...@jabber.fr signature.asc Description: OpenPGP digital signature
Re: [arch-general] OT: [arch-dev-public] polkit package upgrade patch
On Sun, 2012-08-12 at 18:09 +0100, Mauro Santos wrote: On 12-08-2012 17:11, Ralf Mardorf wrote: On Sun, 2012-08-12 at 18:02 +0200, Tom Gundersen wrote: The second case, where the total gain should be 0dB, I would have thought intuitively that doing this purely in software (especially on very faint signals) would be less ideal than doing it in hw (you'd be throwing away the resolution, wouldn't you?), but I'll admit that I don't have the experience to talk about that with any authority. It's a common misconception that keeping the level lower than 0dB would lead to less resolution. It depends to the sampling rate and bit depth and less to the level control. Sampling rate would not matter to level discussions since it limits only the maximum frequency that can be properly sampled or reproduced. Agree, but it is also resolution. For the same bit depth a lower playback output level will yield a lower signal-to-noise or signal-to noise + distortion ratio, thus leading to the same effect of having a DAC of less resolution playing at full scale, so in a way you can say that for lower output levels you have less resolution. But the lower resolution doesn't become audible that easy, if the bit depth is high enough. It's better to keep the level within reason instead of 0dbFS. Even at 48 KHz 16 bit, headroom is better than maximum level. And if you use totally low bit sampling e.g. 2bit for the C64, you need to play with the level. Higher level doesn't mean better sound quality per se.
Re: [arch-general] OT: [arch-dev-public] polkit package upgrade patch
On Sun, 2012-08-12 at 19:38 +0200, Jérôme M. Berger wrote: Fons Adriaensen wrote: It is never necessary. It it were that would imply that a sound card without any gain controls (equivalent to a fixed 0 dB gain) would fail in some cases. It doesn't. In fact many PRO cards are just like that. If you have apps A, B, C with volumes a, b, c you can always set the HW gain to unity gain (0dB), and send s = a * A + b * B + c * C (1) to the soundcard. What would be the advantage of doing what PA does, which is * m = maximum of a, b, c) * Set the master to m, * send s = a/m * A + b/m * B + c/m * C(2) ??? It can only generate trouble, basically you forfeit any headroom the system would have. Actually, that's one point where PA is right (even though it's wrong on a lot of other points): doing it like (2) avoids amplifying the quantification noise if the sound card applies the master gain in analog (or uses higher bit depths internally before the DACs as some do). When cascading amplifiers, it is always better to put the highest possible gain on the first stages (always leaving enough headroom to avoid clipping/distortion) so that later stages will not amplify the noise from the first stages (or so that they will reduce it along with the signal). The only case when this rule does not hold is when doing digital processing in floating point (because then the quantification noise is defined as a proportion of the actual signal instead of its potential maximum). Jerome If you do a mix you should keep the first stages within a good level that fits to the operating points of the op-amps, when ever possible, but you do the mix at that point, followed by sub groups followed by the master, the earlier the stage, the more you'll work with levels, you do less work for the sub groups and the most less work for for the master. You won't readjust the master continuous, especially not for a live stream. Regards, Ralf
Re: [arch-general] OT: [arch-dev-public] polkit package upgrade patch
On Sun, Aug 12, 2012 at 11:10:10AM -0500, Leonid Isaev wrote: Correct me if I'm wrong but I don't think that's possible, because dB is normalized to max power (in watts = intensity). [ Tom Leonid ] Lots of questions... I'll try to answer them, but not all at a time (I need to eat/sleep/etc) as well, and it may amount to crash course in audio engineering... Decibels. What '0 dB' means depends on the context, and usually for someone 'knowing the art' it is clear from the context. For gains it is just a ratio epxressed on a logarithmic scale. For signal levels it depends on the physics. For example, for electrical signals a common 'reference level' corresponding to '0dB' would be 0.775 volt RMS. That is usually notated just 'dB' or 'dBm' (the origin of this is that it represents 1 mW in a load of 600 Ohm). Or you could see dBV, which means 0 dB = 1 V RMS. For sound pressure levels, the reference is 2e-5 Pa (Pascal), which is around the hearing threshold at medium frequencies. So e.g. 90 dB SPL means a sound that is 1e9 times (a billion for the Americans) stronger (in power) than the hearing threshold. The large ratios are why a logarithmics scale is used in the first place. In a digital context, '0dB' usually means the RMS value of the highest sine wave amplitude that can be represented, unless you're talking about peak sample levels, where it means the highest possible sample value. This can be confusing. Resolution Assume you have a simple 16-bit consumer card, and forget about gain controls etc. for a moment, the samples produced by your app (e.g. a player) arrive unmodified at the DA converter. 16 bit means that there are 2^16 possible values for a sample. So the signal is quantised to the nearest level. Except in some special cases, the error (a rounding error) is random and appears as noise. For a 16-bit card, that noise will have a level that is 98 dB lower than the maximum amplitude sine wave it can produce. Let's assume the card is not really 'perfect' and you actually have 95 dB of dynamic range. OK, play back some music that has an high average level (i.e. using all bits most of the time), connect your card to and amp and speakers and adjust the volume on the amp so it is as loud as you would ever want it. Let's assume you now have something like 100 dB average sound pressure level. That is quite loud (your neighbours will complain) and more than enough to cause permanent hearing damage. Let's say that 100 dB average level corresponds to a peak level of 110 dB. Now stop the music. Assuming the sound card is the weakest part in the chain, you will now get a noise level of 110 - 95 = 15 dB. This is well below the ambient noise level in most places, so you won't hear it unless you stick your ears in the speakers. What does this mean ? It means that the dynamic range of 95 dB is more than enough. And if it isn't (as in a music studio where you'd want higher peak levels and the ambient noise level is lower) you just need a few more bits, maybe 20. You can reproduce sound at any level (below the maximum you set) without having to bother about 'resolution', by just scaling the samples you send to the soundcard, and without having to adjust any HW levels. Even if the signal is weak and doesn't use all bits there is no loss of quality - as the error (the noise) is well below the ambient level. If you don't believe this then ask yourself why speakers having an integrated amplifier and a digital input are so popular in professional circles. There is no 'volume' control on those (at least not one you'd normally use) the only way to play at low levels is by not using all the bits. All for now. -- FA A world of exhaustive, reliable metadata would be an utopia. It's also a pipe-dream, founded on self-delusion, nerd hubris and hysterically inflated market opportunities. (Cory Doctorow)
Re: [arch-general] OT: [arch-dev-public] polkit package upgrade patch
On Sun, 2012-08-12 at 18:29 +, Fons Adriaensen wrote: What does this mean ? It means that the dynamic range of 95 dB is more than enough. And if it isn't (as in a music studio where you'd want higher peak levels and the ambient noise level is lower) you just need a few more bits, maybe 20. You can reproduce sound at any level (below the maximum you set) without having to bother about 'resolution' I agree, wrote something similar already before. Btw. some oldish Sony recorders are at 16 bit and for the sound quality it's more important if the mixer is a Neve or Behringer ;), than how many bits are used for the sampling. E.g. http://www2.ak.tu-berlin.de/wwwlogic/Bilder2/24Spur.jpg 16bit AD and 18 bit DA.
Re: [arch-general] SSL I/O error with gmail
On Mon, Aug 13, 2012 at 1:18 AM, Arno Gaboury arnaud.gabo...@gmail.comwrote: On 12/08/12||20:26, jsteel wrote: On 2 August 2012 16:40, Aurko Roy roy.au...@gmail.com wrote: I am trying to get my gmail to work with mutt but keep getting this error: SSL failed: I/O error. Does anybody have a clue what could be the problem? What does your muttrc look like? This works for me: set imap_user=your-username set imap_pass=your-password set folder=imaps://imap.gmail.com/ set spoolfile = +INBOX mailboxes = +INBOX set header_cache = ~/.mutt/hcache set postponed = +[Gmail]/Drafts unset imap_passive set imap_keepalive = 300 set mail_check = 120 set sort=threads jsteel Are you sure to use the correct certificate? Gmail ask for a specific certificate to allow connection, and this should be specified in one of your config file with the cert_fingerprint variable. I have the Thawte's certificates (Thawte_Premium_Server_CA.pem, Thawte_Server_CA.pem) in my /etc/ssl/certs/. Do I need some other certificates to connect? I am not aware of the cert_fingerprint variable in the config file. Could you elaborate more on that? Thanks. -- Aurko Roy GPG key: 0x20C5BC31 Fingerprint:76B4 9677 15BE 731D 1949 85BA 2A31 B442 20C5 BC31
Re: [arch-general] OT: [arch-dev-public] polkit package upgrade patch
On Sun, Aug 12, 2012 at 07:38:58PM +0200, Jérôme M. Berger wrote: Actually, that's one point where PA is right (even though it's wrong on a lot of other points): doing it like (2) avoids amplifying the quantification noise if the sound card applies the master gain in analog (or uses higher bit depths internally before the DACs as some do). True, if the master is after the DAC, but even then irrelevant. Quantisation noise for a typical 20-bit (or even 16-bit) DA is low enough so it doesn't matter. See previous post. When cascading amplifiers, it is always better to put the highest possible gain on the first stages (always leaving enough headroom to avoid clipping/distortion) so that later stages will not amplify the noise from the first stages (or so that they will reduce it along with the signal). The only case when this rule does not hold is when doing digital processing in floating point (because then the quantification noise is defined as a proportion of the actual signal instead of its potential maximum). Correct again. But there's not reason why a software mixer shouldn't use floating point, or a fixed point format (e.g. 32 bit integers) that provides enough room above and below. Please don't tell me that PA is using 16-bit for its internal operations - that would really prove it's complete crap. Ciao, -- FA A world of exhaustive, reliable metadata would be an utopia. It's also a pipe-dream, founded on self-delusion, nerd hubris and hysterically inflated market opportunities. (Cory Doctorow)
Re: [arch-general] SSL I/O error with gmail
On 13/08/12||01:28, Aurko Roy wrote: On Mon, Aug 13, 2012 at 1:18 AM, Arno Gaboury [1]arnaud.gabo...@gmail.com wrote: On 12/08/12||20:26, jsteel wrote: On 2 August 2012 16:40, Aurko Roy [2]roy.au...@gmail.com wrote: I am trying to get my gmail to work with mutt but keep getting this error: SSL failed: I/O error. Does anybody have a clue what could be the problem? What does your muttrc look like? This works for me: set imap_user=your-username set imap_pass=your-password set folder=imaps://[3]imap.gmail.com/ set spoolfile = +INBOX mailboxes = +INBOX set header_cache = ~/.mutt/hcache set postponed = +[Gmail]/Drafts unset imap_passive set imap_keepalive = 300 set mail_check = 120 set sort=threads jsteel Are you sure to use the correct certificate? Gmail ask for a specific certificate to allow connection, and this should be specified in one of your config file with the cert_fingerprint variable. I have the Thawte's certificates (Thawte_Premium_Server_CA.pem, Thawte_Server_CA.pem) in my /etc/ssl/certs/. Do I need some other certificates to connect? I am not aware of the cert_fingerprint variable in the config file. Could you elaborate more on that? Thanks. -- Aurko Roy GPG key: 0x20C5BC31 Fingerprint:76B4 9677 15BE 731D 1949 85BA 2A31 B442 20C5 BC31 References 1. mailto:arnaud.gabo...@gmail.com 2. mailto:roy.au...@gmail.com 3. http://imap.gmail.com/ I use offlineimap to fetch my mails from the gmail account. In its ~/offlineimaprc, I need to set this variable: cert_fingerprint=here is your Thawte_Server fingerprint. Not sure this is needed if you use Mutt IMAP built-in facilities.
Re: [arch-general] OT: [arch-dev-public] polkit package upgrade patch
On 12-08-2012 20:57, Ralf Mardorf wrote: Is it really possible to know exactly, every time, at what level the sum of the audio streams are? IIRC float point does avoid some issues. However, do you think it's smart to adjust at least two following instances within the same audio chain at the same time? If talking about adding two signals, whatever they are, if you know how the sum is made, you can know what the worst case sum will be and if that will cause any problems. By knowing the inputs and the process, the sum in this case, I don't see why it would be a problem to change several things at the same time, you just need to be careful not to get problems. -- Mauro Santos
Re: [arch-general] OT: [arch-dev-public] polkit package upgrade patch
On Sun, 2012-08-12 at 22:17 +0100, Mauro Santos wrote: On 12-08-2012 20:57, Ralf Mardorf wrote: Is it really possible to know exactly, every time, at what level the sum of the audio streams are? IIRC float point does avoid some issues. However, do you think it's smart to adjust at least two following instances within the same audio chain at the same time? If talking about adding two signals, whatever they are, if you know how the sum is made, you can know what the worst case sum will be and if that will cause any problems. Ok, I believe this without verifying it. So I still don't know, but I buy it as truth for this moment. By knowing the inputs and the process, the sum in this case, I don't see why it would be a problem to change several things at the same time, you just need to be careful not to get problems. Hardware steps vs software steps? I Don't believe that it's possible to automate it. Assumed the ALSA driver does come with everything PA needs, I still don't believe that it's smart to do it that way. Careful vs straight, but careful implies a delay. Analog forgives little mistakes, digital doesn't. Not everybody wishes to be the sun of a gun. I prefer to be careful, when using/consuming audio. Regards, Ralf
Re: [arch-general] What can be deleted, when not using systemd - was: polkit package upgrade patch
On Sun, 12 Aug 2012 14:49:29 +0200 Ralf Mardorf ralf.mard...@alice-dsl.net wrote: I suspect upstream folks are living in an ivory tower. Nouveau, PA, systemd, GNOME3, GIMP etc. and regarding to GIMP somebody posted those links. It's worth to read it, since it's not about GIMP only, but about the communication between users and upstream. FWIW, Nouveau has gotten really good for low latency audio lately, I have a machine with a 8600gts running kde with kwin compositing and the kernel latency peaks at about 0.3ms with nouveau, as opposed to nvidia that manages just above 1ms. Of course my hd3000 on sandy bridge manages well under 0.1ms :) I also don't quite understand the PA discussion. I am not thrilled to have libpulse pulled in as a dependency, but on the other hand I have never seen it cause a problem in arch. Of course I have no intention of installing, nor of starting pulseaudio itself on my system... I was however sad to see old dependable friends like ifconfig and route being deprecated last year. Sad to see rc.conf more or less being deprecated too. Seeing the new man page made me see the writing on the wall though, and I have reduced it to an array listing the daemons I wanna start. Think I'm gonna feel like a complete noob next time I wanna install arch somewhere. IMO even if not logical, having a big part of the system config in rc.conf was convenient and reminded me of systems i ran many years ago... Oh well, let's hope the future is so bright that we gotta wear shades :) --- Joakim
Re: [arch-general] What can be deleted, when not using systemd - was: polkit package upgrade patch
On Sun, 12 Aug 2012 23:43:08 +0200 Joakim Hernberg j...@alchemy.lu wrote: Sad to see rc.conf more or less being deprecated too. Seeing the new man page made me see the writing on the wall though, and I have reduced it to an array listing the daemons I wanna start. Better retract this :) Don't know where I got that from, must have been from reading the mailing list. In any case I've taken the big step away from rc.conf by now. --- Joakim
Re: [arch-general] What can be deleted, when not using systemd - was: polkit package upgrade patch
On Sun, Aug 12, 2012 at 11:43:08PM +0200, Joakim Hernberg wrote: I was however sad to see old dependable friends like ifconfig and route being deprecated last year. I had the same initial response to that. But spending an evening reading the ip manpage and doing a lot of 'exercises' using it changed that, now I can type ip commands as fluently as I could do before using ifconfig and route. The most important 'mental adjustmemt' I needed to make was getting used to the idea that a single interface can have many IP adresses. It's probably irrelevant to most users, but still just a fact. Sad to see rc.conf more or less being deprecated too. Yes, it was very convenient to have almost all essential configuration available in a single file. And it's sad that this is being abandoned not because that brings any benefit to the user but because 'upstream has decided'. Oh well, let's hope the future is so bright that we gotta wear shades :) Che serà serà... Ciao, -- FA A world of exhaustive, reliable metadata would be an utopia. It's also a pipe-dream, founded on self-delusion, nerd hubris and hysterically inflated market opportunities. (Cory Doctorow)
Re: [arch-general] What can be deleted, when not using systemd - was: polkit package upgrade patch
On Mon, Aug 13, 2012 at 12:06 AM, Fons Adriaensen f...@linuxaudio.org wrote: Sad to see rc.conf more or less being deprecated too. Yes, it was very convenient to have almost all essential configuration available in a single file. And it's sad that this is being abandoned not because that brings any benefit to the user but because 'upstream has decided'. I do not agree with this. The change does give more features, makes things more reliable in the long run and reduces the maintenance burden. If we did not agree with upstream, we would not have to do this. -t
Re: [arch-general] What can be deleted, when not using systemd - was: polkit package upgrade patch
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/12/2012 02:43 PM, Joakim Hernberg wrote: I also don't quite understand the PA discussion. I am not thrilled to have libpulse pulled in as a dependency, but on the other hand I have never seen it cause a problem in arch. Of course I have no intention of installing, nor of starting pulseaudio itself on my system... - From what I've seen, libpulse doesn't cause problems (other than occupying space). I'm not thrilled about it either. But it seems possible to have it on the system without drawing in the rest of the pulseaudio toolchain that is clearly problematic. Great discussion, by the way. I don't fully understand it either, but given the problems I've had with pulseaudio, I appreciate what seems to be confirmation that I'm losing nothing by leaving it out. - -- David Benfell benf...@parts-unknown.org -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJQKCyXAAoJELT202JKF+xpoogP/1OhYbccpiagZd7Ja3ohZGvs 9rExCkq2/ioUW25ta/aihc7NwEPT1C1dbvMJuNEiO7b8QDBznt6Zq+YoSebSOaQb p1573c3SZlNXGHT3nazL7lXX4vLq2CO7ZHrmLZdI7zFDL4A5J/lVa28wmf7RkmsZ J8UNit+QIfXrePAAmMeSVl33F9YQhB2kzcbJnrH3onSBP8Vblgj2b2hZFMXimuSk FKkk2PFdkg6mdag3xdl5G06cm/tLkfuC5g8wzJceI4TSTrJTRIqsERGz0RZTTA/A SF7uj/NUFjGecCHRVX9r0kFxVZataNuDO61VSV1R0vmaYGvTSII88xaWWj5gI3Go 8kLm0whIa26CauPp2X+/ozqzgkIklOUb+9gIxdEuYiMPmL6L67knFH/O2AtA7Gcp e0FoG8G+CFPLLizkBAdaYA1Lh9WRQ70p64iPBlw04mdIdV7zhtC5jpWOyI+G2Ato 1hyrvprwVvJsJRwZYsx4XW8yzyQdQ3+5pckG5seHKO1WIB7tgoEM0bPKyJH8H6ql 2U15m1U7GkXCyyhBG6IvOGcmkoVgx5kUT2XGLZRiIc6/mDbTJS76NEFCnDLn1zgG jb5eujWPd16TThdEma3qDOnjTFtd1cbJ30ECUSqiDYe32qYvaP32uVpsbrkvF9kL N/R9RqO4jI0ofPatnOQU =8+pa -END PGP SIGNATURE-
Re: [arch-general] What can be deleted, when not using systemd - was: polkit package upgrade patch
On Mon, Aug 13, 2012 at 12:12:56AM +0200, Tom Gundersen wrote: On Mon, Aug 13, 2012 at 12:06 AM, Fons Adriaensen f...@linuxaudio.org wrote: Sad to see rc.conf more or less being deprecated too. Yes, it was very convenient to have almost all essential configuration available in a single file. And it's sad that this is being abandoned not because that brings any benefit to the user but because 'upstream has decided'. I do not agree with this. The change does give more features, makes things more reliable in the long run and reduces the maintenance burden. If we did not agree with upstream, we would not have to do this. And I don't blame you for it ... Ciao, -- FA A world of exhaustive, reliable metadata would be an utopia. It's also a pipe-dream, founded on self-delusion, nerd hubris and hysterically inflated market opportunities. (Cory Doctorow)
Re: [arch-general] What can be deleted, when not using systemd - was: polkit package upgrade patch
On Sun, 2012-08-12 at 15:22 -0700, David Benfell wrote: Great discussion It isn't. Engineering facts are unimportant. Just the benefit is important. Some people benefit from PA and for other people it's a PITA. The essence of it still is the question, why can't PA be optional? PA isn't needed. PA can be an advantage for some usages. PA can completely break some Linux.
Re: [arch-general] What can be deleted, when not using systemd - was: polkit package upgrade patch
On Mon, Aug 13, 2012 at 12:33 AM, Ralf Mardorf ralf.mard...@alice-dsl.net wrote: The essence of it still is the question, why can't PA be optional? I don't do gnome stuff, so I don't know the answer to this (I think I do, but haven't taken the time to check). I'm sure the answer can be found if you were to do $ git clone git://git.gnome.org/gnome-settings-daemon $ git grep -i pulse HTH, Tom
Re: [arch-general] What can be deleted, when not using systemd - was: polkit package upgrade patch
On Mon, 13 Aug 2012 00:33:17 +0200 Ralf Mardorf ralf.mard...@alice-dsl.net wrote: The essence of it still is the question, why can't PA be optional? PA isn't needed. PA can be an advantage for some usages. PA can completely break some Linux. What specific problem do you have with programs being linked to libpulse, so far I haven't encountered any in Arch. OK, I also know from supporting software that some other distributions have a long standing tradition of trampling Jack under their feet and being more or less permanently useless for years already. One reason I'm very happy to be using Archlinux...! --- Joakim
Re: [arch-general] What can be deleted, when not using systemd - was: polkit package upgrade patch
On Mon, 2012-08-13 at 00:44 +0200, Ralf Mardorf wrote: On Sun, 2012-08-12 at 15:22 -0700, David Benfell wrote: On 08/12/2012 02:43 PM, Joakim Hernberg wrote: I also don't quite understand the PA discussion. I am not thrilled to have libpulse pulled in as a dependency, but on the other hand I have never seen it cause a problem in arch. Of course I have no intention of installing, nor of starting pulseaudio itself on my system... From what I've seen, libpulse doesn't cause problems (other than occupying space). I'm not thrilled about it either. But it seems possible to have it on the system without drawing in the rest of the pulseaudio toolchain that is clearly problematic. Great discussion, by the way. I don't fully understand it either, but given the problems I've had with pulseaudio, I appreciate what seems to be confirmation that I'm losing nothing by leaving it out. libpulse is ok :), I don't care about some bytes more or less. A desktop picture nowadays needs more RAM/ROM than a complete workstation needs 2 decades ago. The issue was/is/will be, that PA is a dependency, even if it's not needed. Ooops, but it can brake some usages. Apologize.
Re: [arch-general] What can be deleted, when not using systemd - was: polkit package upgrade patch
On Mon, 13 Aug 2012 04:14:07 +0530, Ralf Mardorf ralf.mard...@alice-dsl.net wrote: On Sun, 2012-08-12 at 15:22 -0700, David Benfell wrote: On 08/12/2012 02:43 PM, Joakim Hernberg wrote: I also don't quite understand the PA discussion. I am not thrilled to have libpulse pulled in as a dependency, but on the other hand I have never seen it cause a problem in arch. Of course I have no intention of installing, nor of starting pulseaudio itself on my system... From what I've seen, libpulse doesn't cause problems (other than occupying space). I'm not thrilled about it either. But it seems possible to have it on the system without drawing in the rest of the pulseaudio toolchain that is clearly problematic. Great discussion, by the way. I don't fully understand it either, but given the problems I've had with pulseaudio, I appreciate what seems to be confirmation that I'm losing nothing by leaving it out. libpulse is ok :), I don't care about some bytes more or less. A desktop picture nowadays needs more RAM/ROM than a complete workstation needs 2 decades ago. The issue was/is/will be, that PA is a dependency, even if it's not needed. Regards, Ralf OT: this is the first discussion of PA, systemd, etc., in my limited experience that didn't lead to ad hominem attacks, stays on topic, and actually provides useful information. great! -- phani.
Re: [arch-general] What can be deleted, when not using systemd - was: polkit package upgrade patch
On Sun, Aug 12, 2012 at 5:12 PM, Tom Gundersen t...@jklm.no wrote: On Mon, Aug 13, 2012 at 12:06 AM, Fons Adriaensen f...@linuxaudio.org wrote: Sad to see rc.conf more or less being deprecated too. Yes, it was very convenient to have almost all essential configuration available in a single file. And it's sad that this is being abandoned not because that brings any benefit to the user but because 'upstream has decided'. I do not agree with this. The change does give more features, makes things more reliable in the long run and reduces the maintenance burden. If we did not agree with upstream, we would not have to do this. -t Tom: I agree with ya'll that it will be better in the long run for Arch in general. However I've had to back away from using systemd. There are simply too many changes going on for me to keep up with and currently I find it much easier to deal with the old style init scripts ( please don't take this a complaint as life and age have slowed some of the processes ). To All: That being said, I think it time for all to quit yer bitchin and decide to fish or cut bait. Right now both ways are supported and that gives everyone time to decide which way they want to go. Less noise about it all would give the devs more time to concentrate on making everything work right instead of either ignoring these debates or tearing their hair out trying to impart some knowledge and understanding to everyone. These are the battles that have spawned many a new linux distro and there's always LFS. It's been said before and I'll reiterate it, If you don't like it work to fix it. Myra -- Life's fun when your sick and psychotic!
Re: [arch-general] What can be deleted, when not using systemd - was: polkit package upgrade patch
On Sun, 2012-08-12 at 15:22 -0700, David Benfell wrote: On 08/12/2012 02:43 PM, Joakim Hernberg wrote: I also don't quite understand the PA discussion. I am not thrilled to have libpulse pulled in as a dependency, but on the other hand I have never seen it cause a problem in arch. Of course I have no intention of installing, nor of starting pulseaudio itself on my system... From what I've seen, libpulse doesn't cause problems (other than occupying space). I'm not thrilled about it either. But it seems possible to have it on the system without drawing in the rest of the pulseaudio toolchain that is clearly problematic. Great discussion, by the way. I don't fully understand it either, but given the problems I've had with pulseaudio, I appreciate what seems to be confirmation that I'm losing nothing by leaving it out. libpulse is ok :), I don't care about some bytes more or less. A desktop picture nowadays needs more RAM/ROM than a complete workstation needs 2 decades ago. The issue was/is/will be, that PA is a dependency, even if it's not needed. Regards, Ralf
Re: [arch-general] [arch-announce] netcfg-2.8.9 drops initscripts compatibility
On Sun, Aug 12, 2012 at 2:43 AM, Florian Pritz bluew...@xinu.at wrote:
On 08/11/2012 11:28 PM, David Hunter wrote:
On Sat, Aug 11, 2012 at 1:01 PM, Arch Linux: Recent news updates:
URL:
http://www.archlinux.org/news/netcfg-289-drops-initscripts-compatibility/
The title of this article seems like it's going to cause a lot of
confusion and anger. [..]
Should be better now, thanks.
--
Florian Pritz -- {flo,bluewind}@server-speed.net
Florian:
Don't scare me like that. I had to read all the posts over three times to
keep from having a heart attack.
Myra
--
Life's fun when your sick and psychotic!
Re: [arch-general] What can be deleted, when not using systemd - was: polkit package upgrade patch
On Mon, 2012-08-13 at 00:36 +0200, Tom Gundersen wrote: On Mon, Aug 13, 2012 at 12:33 AM, Ralf Mardorf ralf.mard...@alice-dsl.net wrote: The essence of it still is the question, why can't PA be optional? I don't do gnome stuff, so I don't know the answer to this (I think I do, but haven't taken the time to check). I'm sure the answer can be found if you were to do $ git clone git://git.gnome.org/gnome-settings-daemon $ git grep -i pulse HTH, Tom Fair play, I don't need GDM and for Arch Linux on my computer only GDM depends indirectly to pulaseaudio. I simply fear that PA and other software that could brake some usages, will spread, without any need. There will alway be a way (at least with help from the community) to get rid of such annoying software. But IMO the simplest way is to stop making odd dependencies. Regards, Ralf
Re: [arch-general] What can be deleted, when not using systemd - was: polkit package upgrade patch
On Mon, 2012-08-13 at 00:41 +0200, Joakim Hernberg wrote: On Mon, 13 Aug 2012 00:33:17 +0200 Ralf Mardorf ralf.mard...@alice-dsl.net wrote: The essence of it still is the question, why can't PA be optional? PA isn't needed. PA can be an advantage for some usages. PA can completely break some Linux. What specific problem do you have with programs being linked to libpulse, so far I haven't encountered any in Arch. A dependency to libpulse is ok, a dependency to pulseaudio is the showstopper. Until now even this isn't an issue, since AFAIK only GNOME for Arch insists on pulseaudio. But this might change. People for good reasons chose some distro. However, IMO it's important to see which way the wind is blowing. I much to often read one name (Poe...), when simply reading just for entertainment some Linux ezines. Paranoia ;), but for god reasons ;).
Re: [arch-general] What can be deleted, when not using systemd - was: polkit package upgrade patch
On Mon, 13 Aug 2012 01:05:25 +0200 Ralf Mardorf ralf.mard...@alice-dsl.net wrote: Until now even this isn't an issue, since AFAIK only GNOME for Arch insists on pulseaudio. But this might change. People for good reasons chose some distro. I think if Gnome has a hard dependency on PA, there isn't anything Arch can do about it... Patching upstream sources isn't the Archway... Otherwise it ought to be an optdepend, but making it optional it it's needed by a package would probably be a bad idea... Seems to me that either you need to stop using Gnome, or write the needed patches to make PA optional. I guess a 3:rd option would be to fix what is broken in PA...:) Let's hope Arch stays the way it was, where more or less everything is optional and you can design your own system exactly as you want it! --- Joakim
Re: [arch-general] What can be deleted, when not using systemd - was: polkit package upgrade patch
On Mon, 2012-08-13 at 01:17 +0200, Joakim Hernberg wrote: On Mon, 13 Aug 2012 01:05:25 +0200 Ralf Mardorf ralf.mard...@alice-dsl.net wrote: Until now even this isn't an issue, since AFAIK only GNOME for Arch insists on pulseaudio. But this might change. People for good reasons chose some distro. I think if Gnome has a hard dependency on PA, there isn't anything Arch can do about it... Patching upstream sources isn't the Archway... Otherwise it ought to be an optdepend, but making it optional it it's needed by a package would probably be a bad idea... Seems to me that either you need to stop using Gnome, or write the needed patches to make PA optional. I guess a 3:rd option would be to fix what is broken in PA...:) Let's hope Arch stays the way it was, where more or less everything is optional and you can design your own system exactly as you want it! When GNOME2 switched to 3 I stopped using GNOME. Hats off! Somebody maintained https://aur.archlinux.org/packages.php?ID=48718 for a long time! Btw. I suspect that I benefit of systemd side effects. Could it be that now, each time a new kernel or kernel-rt is installed, the vbox modules are build, regarding to a side effect of systemd? Or has this nothing to do with systemd? I wish to be allowed to be a dummy using Linux. If I would like to be an expert, I could chose any other obscure OS. Linux shouldn't become non-transparent, even not for noobs. At the moment pulseaudio seems no issue for any distro, as long as we avoid to use GNOME or GDM. For systemd it might be different, perhaps there aren't issues, but without systemd there aren't issues for me. So, if I read systemd is from Mr. X, as pulseaudio is too, I'm horrified. Getting rid of PA is easy, once you know what to do, but it also was easy to get PA (like a disease) without a warning, just by upgrading GNOME for one and the other distro. It's no fun, when that happens at the most bad possible moment. I don't want my Linux PC become as faulty as my iThingy.
Re: [arch-general] OT: [arch-dev-public] polkit package upgrade patch
On 13 Aug 2012 04:31, Fons Adriaensen f...@linuxaudio.org wrote: Please don't tell me that PA is using 16-bit for its internal operations - that would really prove it's complete crap. As far as I can recall from discussion on their list, it's floating point. And thanks for the explanations fons, I've always been impressed by your audio knowledge on this and other lists.
Re: [arch-general] OT: [arch-dev-public] polkit package upgrade patch
I think you are forgetting that linux-based OS market usage is 1.0%. So by the same logic, why do so many people prefer NOT to use these OSs, because they are so good? Are those people all idiots? Sometimes numbers don't mean much... I guess you mean Linux-based desktop OS market usage. Linux runs on many more computer chips than windows and even Microsoft uses linux web servers. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) ___
Re: [arch-general] What can be deleted, when not using systemd - was: polkit package upgrade patch
Then you should really ask yourself why they take that position. AFAICS, there is no solid technical argument for it. I believe they just don't think about anything other than the main and so do the least possible rather than taking the extra steps (or have too much to think about or on the todo list already). Take firefox it has a compilation option of no dbus but if dbus fails it refuses to even start (dbus being a possible route to escape chroot). I had sorted that by just closing off the dbus after start-up but since upgrading now get a general DBUS error message. It was said the linux user space package dependency issue was getting better but I think it's relapsed and perhaps far worse or more lazy in some cases. Now udev has been merged with systemd, and one can wonder why. According to the authors, it is 'because they share some common code'. A rather weak argument, that would be true for almost any two subsystems you can imagine. This is a misrepresentation. Udev and systemd were merged I think mainly because they belong together, but also because they had cyclic build dependencies as they are very tightly integrated. It's no misrepresantation, but an almost literal quote from one of the authors. Yes, systemd and udev are supposed to work closely together, that makes perfect sense. The solution preferred by grown-up programmers in such cases is to define stable interfaces on both sides allowing them to do that, not to merge them. I've been wondering lately whether there is a good reason why even udev violates the one thing and do it well principle set forth by the co worker of the designer of C and Unix as it not only dynamically creates devices like mdev does but also hotplugging like hotplugd on OpenBSD. Hopefully there is a config option or you would need an alternative if you want static dev files and hotplugging. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) ___
Re: [arch-general] OT: [arch-dev-public] polkit package upgrade patch
If it is true that a noticeable glitch is produced, then obviously you have a point, however if the glitch is not noticeable then I don't see the problem you have with PA. In the pro audio world the spinning of a cd has been noted to introduce errors as well as the windows volume control which is often bypassed by pro audio cards. This isn't necessarily something you can hear especially on a casual system. Of course bullshit is also rife and quite amusing sometimes. The same pro audio world sells £10,000 gold power cables as thick as your arm and then plugs them into a standard copper wall socket. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) ___
Re: [arch-general] What can be deleted, when not using systemd - was: polkit package upgrade patch
I would be surprised if a systemd-based system requires more resources than a sysvinit-based one, but that is of course something one would have to measure for each particular use-case. How about an init script that creates proc and sys, two devices via mknod and runs one server or a shell such as in any embedded basic example. My favourite init is still OpenBSDs single /etc/rc script that utilises the minimum number of easily followed, edited (though discouraged) and understood inclusions to make administration practical. There are lots of systemd-based embedded systems cropping up (the embedded world seems more excited about sysntemd than the desktop world). The aim of systemd is to work on anything from embedded, via desktop to servers. You are actually talking about a fraction of embedded, which is the mobile phone world. In truly embedded cheap instant on devices, udev/mdev (dynamic dev) even can be seen as something that slows down the boot and makes it less reliable than using mknod in a short init script. To reiterate an example some people hope linux will run on a cheap toaster. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) ___
