Re: [arch-general] OT: [arch-dev-public] polkit package upgrade patch
Ralf Mardorf wrote: Or much better self responsibility, sorry, I couldn't resist. Use jackd, read the ff manual and control audio streams yourself. Automation always tends to fail. How I agree that manual control will give better results assuming one knows what he is doing, but... Tell me, have you calibrated your monitor? Most people are quite happy with good enough for things outside their main domains of activity/interest. You, as a sound engineer, will want more from your sound setup. People working in video or photography will want more from their displays. Others will be happy so long as their computer just works(tm). To each his own. 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 08/14/2012 03:17 AM, Tom Rand wrote: On Tue, Aug 14, 2012 at 08:59:07AM +0200, Lukas Jirkovsky wrote: On 13 August 2012 21:36, Ralf Mardorf ralf.mard...@alice-dsl.net wrote: On Mon, 2012-08-13 at 21:26 +0200, Ralf Mardorf wrote: Some chips work better at e.g. 96KHz, it doesn't depend to the KHz, simply to the chip. I always thought that these high sampling frequencies are used to avoid aliasing without need for a low-pass filter. Is that true, or am I completely wrong? Lukas Sorry to the Arch hivemind that this first post on mine in this list has a negative tone. OK OK thanks for all the great knowledge being shared about audio, BUT aside from adding OT into the subject this discussion has gone so far off topic it does not even pertain to ARCHLINUX at all! So can i ask you all to please drop this stop filling up my mailbox with unrelevant chit chat or take this to a more relevant place, you all have each others email address' so make your own personal thread. t0m5k1 Why do I care if your mailbox is filling up ?
Re: [arch-general] OT: [arch-dev-public] polkit package upgrade patch
You are either trolling or don't understand that you are not one man group. We have guidelines: He asked politely; be respectful back but also for others here. On Aug 14, 2012, at 7:10 AM, Baho Utot baho-u...@columbus.rr.com wrote: On 08/14/2012 03:17 AM, Tom Rand wrote: On Tue, Aug 14, 2012 at 08:59:07AM +0200, Lukas Jirkovsky wrote: On 13 August 2012 21:36, Ralf Mardorf ralf.mard...@alice-dsl.net wrote: On Mon, 2012-08-13 at 21:26 +0200, Ralf Mardorf wrote: Some chips work better at e.g. 96KHz, it doesn't depend to the KHz, simply to the chip. I always thought that these high sampling frequencies are used to avoid aliasing without need for a low-pass filter. Is that true, or am I completely wrong? Lukas Sorry to the Arch hivemind that this first post on mine in this list has a negative tone. OK OK thanks for all the great knowledge being shared about audio, BUT aside from adding OT into the subject this discussion has gone so far off topic it does not even pertain to ARCHLINUX at all! So can i ask you all to please drop this stop filling up my mailbox with unrelevant chit chat or take this to a more relevant place, you all have each others email address' so make your own personal thread. t0m5k1 Why do I care if your mailbox is filling up ?
Re: [arch-general] OT: [arch-dev-public] polkit package upgrade patch
On Tue, 2012-08-14 at 08:07 -0400, Alex Belanger wrote: You are either trolling or don't understand that you are not one man group. We have guidelines: He asked politely; be respectful back but also for others here. Top posting isn't nice too ;). However, some shared mails off-list, if a discussion should be continued off list, I recommend that Baho should get CCed mails too, if he wants. Hth, Ralf
Re: [arch-general] OT: [arch-dev-public] polkit package upgrade patch
On Mon, Aug 13, 2012 at 02:08:43AM +0100, Kevin Chadwick wrote: 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. Nobody in the pro audio world falls for that nonsense. What you refer to is the bizarre ecosystem of the 'audiophiles', generally people having too much money and no technical understanding at all. They'll buy whatever is expensive, up to equipment required to periodically flush out the old and tired electrons from their left-twisting-oxygen cables and replace them with young and fresh ones. Not that the pro audio world doesn't have its own share of nonsense, but it's different nonsense. 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 Mon, 2012-08-13 at 02:08 +0100, Kevin Chadwick wrote: 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. No, that are rich consumers. I don't think that all of those consumers are stupid audiophiles, I guess some simply have the money and like the design. Cables used by professionals are not that expensive, but they also aren't stylish.
Re: [arch-general] OT: [arch-dev-public] polkit package upgrade patch
Not that the pro audio world doesn't have its own share of nonsense, but it's different nonsense. Yeah but that stuff is usually just irritating but the audiophile example is a little funny without explanation. -- ___ '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
On Mon, 2012-08-13 at 12:21 +0100, Kevin Chadwick wrote: Not that the pro audio world doesn't have its own share of nonsense, but it's different nonsense. Yeah but that stuff is usually just irritating but the audiophile example is a little funny without explanation. One hand washes the other. Pro audio and video are hard businesses. Sometimes nonsense is just there, to save jobs. Faith can move mountains. IOW nonsense can be a motivation. Emotional beings shouldn't make their world to rational.
Re: [arch-general] OT: [arch-dev-public] polkit package upgrade patch
On 13 August 2012 16:04, Fons Adriaensen f...@linuxaudio.org wrote: On Mon, Aug 13, 2012 at 02:08:43AM +0100, Kevin Chadwick wrote: 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. Nobody in the pro audio world falls for that nonsense. I did fall _over_ a crapload of Monster cables one time in an FOH setup. Was the only time ever in my life I came across those stuff for live sound. Otherwise, we usually make our own cables. Anyway, this thread is pretty amusing itself. From polkit to audiophiles. How did that happen? (rhetoric) -- GPG/PGP ID: C0711BF1
Re: [arch-general] OT: [arch-dev-public] polkit package upgrade patch
On Mon, 2012-08-13 at 23:49 +0800, Rashif Ray Rahman wrote: Otherwise, we usually make our own cables. Private I sometimes buy ready to use cables, I just check if the soldering joints are ok. It's less expensive, since in Germany we've got an online retailer who sells equipment for less money. People from other European countries perhaps know the retailer too ;). For professional usage cables usually have to be self-made. Btw. I once asked if Neutrik plastic cable relief does crumble all over the world after a while at LAU or LAD. Yes, they do. I switched to Rean. Btw. very rational advertising: http://www.rean-connectors.com/website/themes/rean/images/rean_theme.jpg at http://www.rean-connectors.com/
Re: [arch-general] OT: [arch-dev-public] polkit package upgrade patch
On Mon, Aug 13, 2012 at 6:08 PM, Ralf Mardorf ralf.mard...@alice-dsl.net wrote: On Mon, 2012-08-13 at 23:49 +0800, Rashif Ray Rahman wrote: Otherwise, we usually make our own cables. Private I sometimes buy ready to use cables, I just check if the soldering joints are ok. It's less expensive, since in Germany we've got an online retailer who sells equipment for less money. People from other European countries perhaps know the retailer too ;). For professional usage cables usually have to be self-made. Btw. I once asked if Neutrik plastic cable relief does crumble all over the world after a while at LAU or LAD. Yes, they do. I switched to Rean. Btw. very rational advertising: http://www.rean-connectors.com/website/themes/rean/images/rean_theme.jpg at http://www.rean-connectors.com/ This still is Arch ML, so discussion about audio stuff should be taken to Arch-Audio or some place like that.
Re: [arch-general] OT: [arch-dev-public] polkit package upgrade patch
On Mon, 2012-08-13 at 18:20 +0200, Karol Blazewicz wrote: On Mon, Aug 13, 2012 at 6:08 PM, Ralf Mardorf ralf.mard...@alice-dsl.net wrote: On Mon, 2012-08-13 at 23:49 +0800, Rashif Ray Rahman wrote: Otherwise, we usually make our own cables. Private I sometimes buy ready to use cables, I just check if the soldering joints are ok. It's less expensive, since in Germany we've got an online retailer who sells equipment for less money. People from other European countries perhaps know the retailer too ;). For professional usage cables usually have to be self-made. Btw. I once asked if Neutrik plastic cable relief does crumble all over the world after a while at LAU or LAD. Yes, they do. I switched to Rean. Btw. very rational advertising: http://www.rean-connectors.com/website/themes/rean/images/rean_theme.jpg at http://www.rean-connectors.com/ This still is Arch ML, so discussion about audio stuff should be taken to Arch-Audio or some place like that. Ok. Apologize, digression happens, at least we stop to discuss about ... have forgotten the name of this coder. Easing of tension might be not that worse. Am I mistaken? It's marked as OT. However, you are right, but you anyway should be aware how communication works. There isn't rational behavior for emotional beings. I only know this expectations from Linux mailing lists. I hope we are human, emotional beings. Has software nothing to do with the context, usage? Regards, Ralf
Re: [arch-general] OT: [arch-dev-public] polkit package upgrade patch
On Mon, Aug 13, 2012 at 06:08:04PM +0200, Ralf Mardorf wrote: For professional usage cables usually have to be self-made. Btw. I once asked if Neutrik plastic cable relief does crumble all over the world after a while at LAU or LAD. Yes, they do. I switched to Rean. Which is Neutrik made in China :-) Best XLRs are from Switchcraft. 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 Mon, Aug 13, 2012 at 11:20 AM, Karol Blazewicz karol.blazew...@gmail.com wrote: On Mon, Aug 13, 2012 at 6:08 PM, Ralf Mardorf ralf.mard...@alice-dsl.net wrote: On Mon, 2012-08-13 at 23:49 +0800, Rashif Ray Rahman wrote: Otherwise, we usually make our own cables. Private I sometimes buy ready to use cables, I just check if the soldering joints are ok. It's less expensive, since in Germany we've got an online retailer who sells equipment for less money. People from other European countries perhaps know the retailer too ;). For professional usage cables usually have to be self-made. Btw. I once asked if Neutrik plastic cable relief does crumble all over the world after a while at LAU or LAD. Yes, they do. I switched to Rean. Btw. very rational advertising: http://www.rean-connectors.com/website/themes/rean/images/rean_theme.jpg at http://www.rean-connectors.com/ This still is Arch ML, so discussion about audio stuff should be taken to Arch-Audio or some place like that. Right, just marking the subject as [OT] doesn't suddenly give you permission to post anything you like.
Re: [arch-general] OT: [arch-dev-public] polkit package upgrade patch
On Mon, 2012-08-13 at 16:35 +, Fons Adriaensen wrote: On Mon, Aug 13, 2012 at 06:08:04PM +0200, Ralf Mardorf wrote: For professional usage cables usually have to be self-made. Btw. I once asked if Neutrik plastic cable relief does crumble all over the world after a while at LAU or LAD. Yes, they do. I switched to Rean. Which is Neutrik made in China :-) Yes, but they seem to differ positively. Best XLRs are from Switchcraft. I'm not talking just about XLR, however I only heard good about Switchcraft and didn't experience anything bad myself. I always check what is available at thoma... and reiche... first, for less money. I still would buy Neutrik, when they are cheap at the time I do an order.
Re: [arch-general] OT: [arch-dev-public] polkit package upgrade patch
Ralf Mardorf wrote: On Sun, 2012-08-12 at 19:38 +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). 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. Two points: - You don't readjust the master continuously, but you don't add/remove sources on the fly either. You adjust the master in the beginning when you setup your system, but the reason you can do that is because you know exactly what sources you will have and what kinds of levels those sources generate. - Keep the first stages within a good level that fits the operating points of the op-amps. In practice, this is done by using the maximum level that does not produce distortion. When talking digital signals, this means keep the level at 0dB for as long as possible. 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
Fons Adriaensen wrote: 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. Where does that 98dB come from? A factor of 2 is roughly 3dB, so 16 bits should mean 3x16=48dB, no? Taking this figure, your example where the maximum level is set to 110dB will leave 62dB for pure noise, i.e between the level of a TV set and a handheld electric mixer (1) so perfectly audible. BTW, I generated a minimum amplitude signal in audacity and played it with my speaker volume set to max and it was perfectly audible (even with my window open and the birds singing outside). Since quantification noise is half that, it should be audible too. 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. I doubt those use 16 bits input. Even low-end hi-fi digital recorders support 24 bits, which gives -72dB for the noise and starts indeed to be acceptable. But most end-user will simply set their system to CD quality (or leave it at the default which is usually that same 16bits 44kHz, whatever name the app chose to gave it). 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. Well, 16 bits integers should be faster to process. The difference is not important when your computer is doing nothing but audio processing anyway, but we're talking end-user system here and sound mixing is simply a background process that should not take too much time from the real work of the computer, even if this results in less than optimal sound quality. You might argue that the difference in computing requirements is very little, but keep in mind that the real work could be a computer game where every cycle counts. This is especially true in the most common case where there is a single sound source: PA can send the sound directly to the sound card without wasting any time adjusting the gain in software first. Jerome (1) https://en.wikipedia.org/wiki/Sound_pressure#Examples_of_sound_pressure_and_sound_pressure_levels -- 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 Mon, 2012-08-13 at 19:53 +0200, Jérôme M. Berger wrote: Two points: - You don't readjust the master continuously, but you don't add/remove sources on the fly either. You adjust the master in the beginning when you setup your system, but the reason you can do that is because you know exactly what sources you will have and what kinds of levels those sources generate. That's more more or less true. But regarding to PA, PA can't have all this information ;). Yep, it's your argument, that what PA does is correct. You aren't completely wrong. I still vote for headroom and a classical analog style. Or much better self responsibility, sorry, I couldn't resist. Use jackd, read the ff manual and control audio streams yourself. Automation always tends to fail. YMMV! Ralf
Re: [arch-general] OT: [arch-dev-public] polkit package upgrade patch
On Mon, Aug 13, 2012 at 08:33:41PM +0200, Jérôme M. Berger wrote: Fons Adriaensen wrote: 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. Where does that 98dB come from? A factor of 2 is roughly 3dB, so 16 bits should mean 3x16=48dB, no? Taking this figure, your example where the maximum level is set to 110dB will leave 62dB for pure noise, i.e between the level of a TV set and a handheld electric mixer (1) so perfectly audible. Sigh Is it *really* asking to much to look up and understand at least the *very very basics* before you post instead of showing your complete ignorance ??? Sorry if this sound harsh, but if you don't know where that 98 dB comes from your are not in any position to question what I wrote. And I am not providing free education. 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 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] 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] 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] 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] 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] 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] 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] OT: [arch-dev-public] polkit package upgrade patch
Op 11 aug. 2012 03:02 schreef Tom Gundersen t...@jklm.no het volgende: On Sat, Aug 11, 2012 at 2:01 AM, Heiko Baums li...@baums-on-web.de wrote: [...] Like I said before, if you would support systemd, sytemd-tools and everything else related to systemd totally optional, and keep initscripts pure initscripts without any systemd stuff like it was before, I would say nothing. But since you really force the users to install this systemd stuff, you will have to live with such comments, and not only from me, as you should know. It's always funny in this subject how people seem to forget that udev no longer exists on its own. Despite the careful annoucements from Arch. I don't force anyone to do anything. If you see flaws in anything I do, then provide review, patches or bug reports. If you don't like the direction I'm taking initscripts in, then fork it and provide your competing version. To be clear: it has always been my plan to make initscripts and systemd as close to each other as possible and share as much code as possible. I strongly believe this is the right thing to do. If you disagree, then I think your time is better spent at coding a replacement rather than at whining. Just for the record Tom: some of us are very happy with your work on continuening Initscripts. It sometimes looks as if 'everyone' feels they must switch to pure systemd, I for one prefer the predictability of init. Keeper up the good work! Mvg, Guus
Re: [arch-general] OT: [arch-dev-public] polkit package upgrade patch
On 10/08/12 23:38, Heiko Baums wrote: Am Fri, 10 Aug 2012 16:33:39 -0400 schrieb Brandon Watkins bwa...@gmail.com: Systemd and pulseaudio are completely different pieces of software with different purposes. Comparing them like that just because of the author is comparing apples to oranges. Sorry, it is not. I see that PA is totally not complete and doesn't support at least half of the professional use cases. And I see that it's the same with systemd. So what's the difference? They are both developed by the same person who seemingly doesn't have much knowledge about professional computer usage and only cares about some desktop users. With PA it's currently not such a problem since I don't need to use a distro or a desktop environment which forces me to install PA. With systemd it's worse since the init system is a very serious and important piece of the system. And if this doesn't support every professional use case and isn't proved to be really reliable, it just shouldn't be made to a de facto standard. And if I can't trust PA how can I trust an even more important piece of software written by the same person? Btw., look at systemd-cryptsetup. Yes, meanwhile my use case is filed upstream and allegedly and hopefully fixed. But it shows that at least one use case was just forgotten or in other words it was not well enough thought out. The latter is the biggest problem. Like I said before, some of Lennart's ideas may, say, seem to be quite interesting, and maybe sysvinit is also not the perfect init system. But Lennart's software is just not implemented good enough. If somebody doesn't care about the professional users when writing on software, would he really care about the professional users when writing the other software? Sure soon RHEL will switch to systemd with RHEL 7, so the systemd market share will probably continue to grow. Also SUSE seems to switch to systemd. With these major distro's taking up systemd, it's almost impossible that it's not implemented good enough. p.s. it's a bit lame to just blame Poettering since for everything he just iirc the maintainer of systemd. Since there are much more people behind systemd ( Kay sievers, etc. ) signature.asc Description: OpenPGP digital signature
Re: [arch-general] OT: [arch-dev-public] polkit package upgrade patch
On Sat, 2012-08-11 at 09:56 +0200, Jelle van der Waa wrote: Sure soon RHEL will switch to systemd with RHEL 7, so the systemd market share will probably continue to grow. Also SUSE seems to switch to systemd. With these major distro's taking up systemd, it's almost impossible that it's not implemented good enough. Hm? Suse was the first distro I used, for good reasons I'm using other distros for serious work today. However, from time to time I install Suse, currently it's the outdated Suse 11.2. For my needs Suse often is much to unstable. I know an important Linux audio coder who is using Linux for serious work. Perhaps he simply has got more knowledge to set up Suse, different hardware and different needs. p.s. it's a bit lame to just blame Poettering since for everything he just iirc the maintainer of systemd. Since there are much more people behind systemd ( Kay sievers, etc. ) But who does aggressive public relations? Nobody, but Poettering. On Sat, 2012-08-11 at 08:15 +0200, Guus Snijders wrote: Op 11 aug. 2012 03:02 schreef Tom Gundersen t...@jklm.no het volgende: To be clear: it has always been my plan to make initscripts and systemd as close to each other as possible and share as much code as possible. I strongly believe this is the right thing to do. If you disagree, then I think your time is better spent at coding a replacement rather than at whining. Just for the record Tom: some of us are very happy with your work on continuening Initscripts. It sometimes looks as if 'everyone' feels they must switch to pure systemd, I for one prefer the predictability of init. I agree that it's a good work, when he tries to give users the choice. I wonder why it's not wanted that people discuss major changes. On another list some people don't want that the default DE for a distro will become another DE. I like the switch to that other DE, but for me there's no need to rant against those who'll keep the DE that was used in the past. However, some people from that list rant against those people, they want them to stop discussing that on this USER LIST. IMO the best place for a discussion is a USER LIST. If there's a result, it can be reported to the relevant people. We often talk about the most people. Is there anything bad with marginalized groups, people that might not be able to contribute to Linux, but perhaps those contribute to other useful things? I wonder about the definition of the word community. Seemingly people don't read why people have issues and that people e.g. reported issues, since they always ask to report an issue to another place, to contribute, to pay somebody, not to forget at some point people are just stupid, have to much time etc.. Community? Regards, Ralf
Re: [arch-general] OT: [arch-dev-public] polkit package upgrade patch
Am Sat, 11 Aug 2012 03:47:09 +0300 schrieb Thanasis Georgiou sakisd...@gmail.com: So you had a problem but when Tom wrote a patch you were unwilling to help test it? What part of I had no time to set up a VM. and I have only one stable system which needs to be stable and reliable. didn't you get? Heiko
Re: [arch-general] OT: [arch-dev-public] polkit package upgrade patch
On Aug 11, 2012 2:38 PM, Heiko Baums li...@baums-on-web.de wrote: Am Sat, 11 Aug 2012 03:47:09 +0300 schrieb Thanasis Georgiou sakisd...@gmail.com: So you had a problem but when Tom wrote a patch you were unwilling to help test it? What part of I had no time to set up a VM. and I have only one stable system which needs to be stable and reliable. didn't you get? Did you even read my whole email?
Re: [arch-general] OT: [arch-dev-public] polkit package upgrade patch
Am Sat, 11 Aug 2012 03:02:03 +0200 schrieb Tom Gundersen t...@jklm.no: Issues, serious or otherwise, belong in the bug-tracker. We have surprisingly few systemd/pulseaudio bugs open, considering all the noise they create on the ML. Is it really that hard to respect other people's opinions and wishes? Is it really that hard? Sorry, I didn't realise you were being serious. Of course you shouldn't delete them. If you don't use systemd they have no effect, and take hardly no space. But they take space on my harddisk. And even TB harddisks can get full some day. And not everybody is able to afford a new one at once. And I just don't want this systemd stuff on my harddisk. But, hey, it's really hard to respect other people's opinions and wishes. I understand. If other people don't want to have anything to do with a certain software then this software has to be forced onto them because the maintainer is a fanboy of this software and can't respect other people's opinions due to his rose-colored glasses. I don't force anyone to do anything. If you see flaws in anything I do, then provide review, patches or bug reports. If you don't like the direction I'm taking initscripts in, then fork it and provide your competing version. You do force every Arch Linux user to install that systemd stuff. Why else do I have systemd-tools installed on my harddisk? Why else do I have all this systemd stuff in /usr/lib/systemd/system? Why else do I have even this directory /usr/lib/systemd on my harddisk? I tell you, because you force it on me. I never have installed this on my own. To be clear: it has always been my plan to make initscripts and systemd as close to each other as possible and share as much code as possible. I strongly believe this is the right thing to do. If you disagree, then I think your time is better spent at coding a replacement rather than at whining. I don't know what you didn't get. I have already coded the cryptsetup part of initscripts which still works, which works better than this systemd-cryptsetup thing, and which you want to replace by some untrustworthy, and at least incomplete systemd stuff. And, yes, I totally disagree that your plan to make initscripts and systemd as close to each other as possible are good. And I'm not the only one as you should know meanwhile. This, too, is forcing systemd on everbody. Initscripts worked before and would still do this. If you are a systemd fanboy then provide and support systemd optional, but leave initscripts alone and revert it to what it was, before you made all those systemd changes. But, yes, I forgot again, other people's opinions and wishes are dull and all those people don't know anything and have no clue what they are talking about. All those people on the whole wide web. And you are the wisdom in person. Are you really sure that you know what you are talking about? Are you really sure that you know what you are doing with initscripts? And, btw., I would also be interested in some opinions of the other devs and TUs about your activities in forcing this systemd stuff on everybody. You are the only dev who is permanently talking about this and hyping systemd, and meanwhile I know that you are a systemd fanboy. What about the other devs? Have your plans with all their pros and cons and the users' opinions and wishes been discussed before with the other devs? Or are you doing this all on your own? Meanwhile I have the opinion that it's the latter one. And still no word about the other tools which work on top of sysvinit which have recently be mentioned by someone else here on this mailing list. Only this systemd fanboy jabbering. Heiko
Re: [arch-general] OT: [arch-dev-public] polkit package upgrade patch
Am Sat, 11 Aug 2012 09:56:49 +0200 schrieb Jelle van der Waa je...@vdwaa.nl: Sure soon RHEL will switch to systemd with RHEL 7, so the systemd market share will probably continue to grow. Also SUSE seems to switch to systemd. With these major distro's taking up systemd, it's almost impossible that it's not implemented good enough. Then, why are there regularly so many, so long discussions on the web? And most of them are not started by me, and I don't even participate in a lot of them. And why are all those critical comments about PA, systemd, and Lennart Poettering marked green by so many people? Why is Lennart Poettering's software the only software about which there are so many discussions? Really because it's so damn good? I don't know what's going on behind the scenes of all those major distros. So I don't know how big Lennart's or someone else's influence is. But I think it's a mistake to switch to systemd. Well, offering it optionally, would be no problem. Speaking of which, I doubt that the RHEL and SUSE users care this much about the init system and the system internals as Arch Linux users do. p.s. it's a bit lame to just blame Poettering since for everything he just iirc the maintainer of systemd. Since there are much more people behind systemd ( Kay sievers, etc. ) I know that Poettering is not the only one behind systemd and PA, but it was his idea and he still is the maintainer. So it's still his software. Heiko
Re: [arch-general] OT: [arch-dev-public] polkit package upgrade patch
On Sat, 11 Aug 2012 14:16:46 +0200 Heiko Baums li...@baums-on-web.de wrote: Am Sat, 11 Aug 2012 09:56:49 +0200 schrieb Jelle van der Waa je...@vdwaa.nl: Sure soon RHEL will switch to systemd with RHEL 7, so the systemd market share will probably continue to grow. Also SUSE seems to switch to systemd. With these major distro's taking up systemd, it's almost impossible that it's not implemented good enough. Then, why are there regularly so many, so long discussions on the web? And most of them are not started by me, and I don't even participate in a lot of them. And why are all those critical comments about PA, systemd, and Lennart Poettering marked green by so many people? Why is Lennart Poettering's software the only software about which there are so many discussions? Really because it's so damn good? 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 don't know what's going on behind the scenes of all those major distros. So I don't know how big Lennart's or someone else's influence is. But I think it's a mistake to switch to systemd. Well, offering it optionally, would be no problem. Right, all evil in this world comes from Glass, Apples and... LP. BTW, last time I checked, opensuse had pretty vast public dev ML. Speaking of which, I doubt that the RHEL and SUSE users care this much about the init system and the system internals as Arch Linux users do. p.s. it's a bit lame to just blame Poettering since for everything he just iirc the maintainer of systemd. Since there are much more people behind systemd ( Kay sievers, etc. ) I know that Poettering is not the only one behind systemd and PA, but it was his idea and he still is the maintainer. So it's still his software. Heiko -- 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
2012/8/11 Heiko Baums li...@baums-on-web.de: Am Sat, 11 Aug 2012 03:02:03 +0200 schrieb Tom Gundersen t...@jklm.no: Issues, serious or otherwise, belong in the bug-tracker. We have surprisingly few systemd/pulseaudio bugs open, considering all the noise they create on the ML. Also surprising: a few people mentioned alternatives to systemd / sysvinit. AFAIK none of them started a project to implement their idea in Arch... ;) Is it really that hard to respect other people's opinions and wishes? Is it really that hard? Sorry, I didn't realise you were being serious. Of course you shouldn't delete them. If you don't use systemd they have no effect, and take hardly no space. But they take space on my harddisk. And even TB harddisks can get full some day. And not everybody is able to afford a new one at once. And I just don't want this systemd stuff on my harddisk. Well, it should be possible to create a system (even Arch!) completely free of systemd tools. You'd have to rebuild some of the initscripts and, oh yeah, fire up mknod to create all necessary devices. As i'm sure you know, Udev is now a part of systemd. Just my two cents. mvg, Guus
Re: [arch-general] OT: [arch-dev-public] polkit package upgrade patch
2012/8/11 Guus Snijders gsnijd...@gmail.com: 2012/8/11 Heiko Baums li...@baums-on-web.de: [...] And I just don't want this systemd stuff on my harddisk. Well, it should be possible to create a system (even Arch!) completely free of systemd tools. You'd have to rebuild some of the initscripts and, oh yeah, fire up mknod to create all necessary devices. As i'm sure you know, Udev is now a part of systemd. Ok, a quick reply on myself. I just read in an other thread that this last statement isn't entirely true. It seems like it's still possible to use udev stand-alone. Apologies for my ignorance. mvg, Guus
Re: [arch-general] OT: [arch-dev-public] polkit package upgrade patch
*grabs popcorn* On Sat, Aug 11, 2012 at 2:03 PM, Heiko Baums li...@baums-on-web.de wrote: But they take space on my harddisk. And even TB harddisks can get full some day. And not everybody is able to afford a new one at once. [kwpolska@kwpolska-lin ~]% du -sh /usr/lib/systemd 3.6M/usr/lib/systemd Seriously? Are 3.6M so much? So you don’t have any packages for shells other than the one you’re using? So you don’t have more than one terminal emulator? Of course you do! Then why do you care about systemd files? You can always run a rm -rf /usr/lib/systemd, you know. And I just don't want this systemd stuff on my harddisk. And I just don’t want this GNOME 3 stuff on my harddisk. But I don’t go whining on the MLs, I rather go pacman -R gnome. Or whatever you have. (although GNOME 3 sucks and EVERYONE will agree with that.) But, hey, it's really hard to respect other people's opinions and wishes. I understand. If other people don't want to have anything to do with a certain software then this software has to be forced onto them because the maintainer is a fanboy of this software and can't respect other people's opinions due to his rose-colored glasses. Told ya: pacman -R systemd; rm -rf /usr/lib/systemd. Your wishes are granted. You do force every Arch Linux user to install that systemd stuff. Why else do I have systemd-tools installed on my harddisk? Why else do I have all this systemd stuff in /usr/lib/systemd/system? Why else do I have even this directory /usr/lib/systemd on my harddisk? I tell you, because you force it on me. I never have installed this on my own. rm -rf /usr/lib/systemd Also, believe it or not, systemd-tools was not forced on you. systemd-tools = udev + some fancy systemd manpages and files. THAT’S IT! It could be also named udev-plus-fancy-stuff. Or i-like-turtles. Or rainbow-dash-is-best-pony. Although the last one could spawn such OT as this thread by people who aren’t (or even hate) bronies. Initscripts worked before and would still do this. If you are a systemd fanboy then provide and support systemd optional, but leave initscripts alone and revert it to what it was, before you made all those systemd changes. …and initscripts still work and will work for a while… But, yes, I forgot again, other people's opinions and wishes are dull and all those people don't know anything and have no clue what they are talking about. All those people on the whole wide web. And you are the wisdom in person. I told you how to grant your wish at least twice before, so I won’t repeat that. Your opinion? NOBODY CARES! You can still use initscripts! Nobody cares that you don’t like systemd, pulseaudio or Poettering! And if we’re talking about pulseaudio: sure, pulseaudio is a bit more “forced” on you by certain packages. But you can still live without it, I think. If you are doing “pro audio work” and you can afford a $bazillion audio card, then why can’t you afford a $200* OS? Windows will be much better! And if you really want to work like a pro, get a Mac. And if you want to stay on this fancy Linux thing used by ~nobody, and exactly 0 (read: zero) people in the pro area, especially in the pro gamer area (there are -1000 pro gamers on Linux now), and there is no way to escape PulseAudio right now, PATCHES WELCOME! Remember: systemd and pulseaudio are open-source projects. If you want to see something improved, Obligatory disclaimer: I am using three Arch systems: physical/x86_64/systemd/pulse/KDE, VM/x86_64/systemd/pulse/Xfce and VM/i686/initscripts/no-audio-at-all/Xfce. The first VM is used mainly for development under Windows (I’ve yet to see people developing linux-specific tools or even AUR helpers [pkgbuilder] under Windows), while the second one is used for a blog post that was written but isn’t since over a week. Anyways, I was criticizing both pulseaudio and systemd in their earlier stages. But now, my system (mostly) works properly. The only problematic piece of software is VLC, which has some white noise when it starts playing audio. Everyone else is fine. * = €200 from Microsoft, although it should be around €160. I love this fucking currency, especially when it’s forced on me (Steam, anyone?). Please, oh, please, kill it already. It is bloody useless. -- 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] OT: [arch-dev-public] polkit package upgrade patch
And I hadn't had time to set up a VM. not to worry, the whole world of free software developers (including Arch) are here and have all the time to serve your wishes. -- дамјан
Re: [arch-general] OT: [arch-dev-public] polkit package upgrade patch
Am Sat, 11 Aug 2012 22:21:01 +0200 schrieb Damjan gdam...@gmail.com: not to worry, the whole world of free software developers (including Arch) are here and have all the time to serve your wishes. Have you thought about that comment before sending it? Heiko
Re: [arch-general] OT: [arch-dev-public] polkit package upgrade patch
On Fri, Aug 10, 2012 at 12:02:50PM -0400, Baho Utot wrote: With pulse it just takes over the master volume when it try to adjust audio in an application cranking the master volume to full. Without pulse it just works the way I like it to be. So count me as one of the ones who doesn't like pulse audio. :-) Give anyone who's not an audio engineer two volume controls in series and the result will be either noise interference or distortion or both. So imagine the average desktop user who gets five or so of them: - one provided by the application (player or something) - one provided by PA or similar, - probably two by the soundcard mixer, - and finally one on his/her cheap 'multimedia speakers'. The first and second ones will be digital, unless one of them tries to control the soundcard mixer. The soundcard mixer controls could be digital or analog or an undocumented mix of both. The last one is probably analog. The probability of getting any decent sound out of such a mess is smallish. 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, Aug 12, 2012 at 12:03 AM, Fons Adriaensen f...@linuxaudio.org wrote: So imagine the average desktop user who gets five or so of them: - one provided by the application (player or something) - one provided by PA or similar, - probably two by the soundcard mixer, PA combines these three into one. So the non-audio-engineer user should have a lot bigger chance of not messing things up with PA compared to with pure ALSA (where you do have to fiddle with all the mixers and the application mixer on top). Sorry if this was what you were trying to point out. -t
Re: [arch-general] OT: [arch-dev-public] polkit package upgrade patch
On Sun, Aug 12, 2012 at 12:15:14AM +0200, Tom Gundersen wrote: On Sun, Aug 12, 2012 at 12:03 AM, Fons Adriaensen f...@linuxaudio.org wrote: So imagine the average desktop user who gets five or so of them: - one provided by the application (player or something) - one provided by PA or similar, - probably two by the soundcard mixer, PA combines these three into one. So the non-audio-engineer user should have a lot bigger chance of not messing things up with PA compared to with pure ALSA (where you do have to fiddle with all the mixers and the application mixer on top). Sorry if this was what you were trying to point out. Obviously you're not a sound engineer, or you would know that is pure nonsense. First, PA has no visibility on whatever internal volume control an app provides. It just doesn't know about it. All it gets is the output from the app. Second, PA has no way to know how to correctly use the soundcard controls, or even to know what exactly they control and how they do it. On some cards the 'master' is digital scaling before the D/A converter. On some others it controls an analog gain stage after the converter. The correct way to use those is completely different. 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, Aug 12, 2012 at 12:31 AM, Fons Adriaensen f...@linuxaudio.org wrote: First, PA has no visibility on whatever internal volume control an app provides. It just doesn't know about it. All it gets is the output from the app. This is not correct. If the app has proper PA support (such as all KDE apps, and probably all gnome apps), then PA does the app specific mixing, not the app itself. Moreover, if only one app is playing sound then PA does no mixing at all, but passes it all directly to ALSA (and sets ALSA's controls of course). Second, PA has no way to know how to correctly use the soundcard controls, or even to know what exactly they control and how they do it. On some cards the 'master' is digital scaling before the D/A converter. On some others it controls an analog gain stage after the converter. The correct way to use those is completely different. If I understand correctly ALSA provides lots of meta-information about the controllers to PA. Before PA this meta information was ignored, and it is due to bugs in that that PA had a bad reputation in the beginning. PA has heuristics to try to do the best it can with the information provided to it. Are you saying that an unqualified user is likely to get a better result than these heuristics? It seems that what you are saying should mean that ALAS is clearly not good enough, and that we need something more, such as PA to deal with getting the mixing right, as it is too hard for users. -t
Re: [arch-general] OT: [arch-dev-public] polkit package upgrade patch
On Sun, Aug 12, 2012 at 12:41:24AM +0200, Tom Gundersen wrote: On Sun, Aug 12, 2012 at 12:31 AM, Fons Adriaensen f...@linuxaudio.org wrote: First, PA has no visibility on whatever internal volume control an app provides. It just doesn't know about it. All it gets is the output from the app. This is not correct. If the app has proper PA support (such as all KDE apps, and probably all gnome apps), then PA does the app specific mixing, not the app itself. That doesn't stop the app from having its own internal volume control that PA doesn't know about. Moreover, if only one app is playing sound then PA does no mixing at all, but passes it all directly to ALSA (and sets ALSA's controls of course). If that is true it is completely wrong from the start. Because that setup can't be maintained when a second app starts playing which can happen at any time. Suppose that first (single) app has its volume set to some low value, and PA uses the soundcard PCM gain control to achieve that as you claim it does. Now suddenly there's a second app which wants a higher level. The only way to achieve that is to raise the hardware gain - you can't compensate for a low setting there by sending a louder signal, it would just clip. So PA now has to adjust the hardware gain and at the same time start scaling down the output from the first app. It's impossible to do that in any acceptable way. Simple fact is that most soundcards, even if they have a 'mixer', can't mix PCM signals (i.e. signals from the software) - they can mix in a CD player, or an external mic input etc.). So for anything coming from the system there is just one path, which has two controls, the 'PCM' and the 'master'. The only way to correctly use them if there if there is software mixing is to set them once to their correct values (which may depend on what is connected externally), and them leave them alone and do the rest in software. And then we haven't even touched the matter of different sample rates. Second, PA has no way to know how to correctly use the soundcard controls, or even to know what exactly they control and how they do it. On some cards the 'master' is digital scaling before the D/A converter. On some others it controls an analog gain stage after the converter. The correct way to use those is completely different. If I understand correctly ALSA provides lots of meta-information about the controllers to PA. Before PA this meta information was ignored, and it is due to bugs in that that PA had a bad reputation in the beginning. 'A lot of meta-information' LOL. It will provide some usually meaningless and inconsistent names of controls, their min and max values, and if you're extremely lucky maybe some indication mapping control values to dB, which may or may not be correct (and if it isn't that's not ALSA's fault, it just crappy and undocumented harware). All of that is visible in alsamixer. PA has heuristics to try to do the best it can with the information provided to it. Are you saying that an unqualified user is likely to get a better result than these heuristics? Yes, absolutely. It may take the user some time to understand the quirks of his soundcard (such as that it's not capable of outputting full digital level without distortion, no matter how the controls are set, or even crappier shortcomings). But he will usually find a way to get things working. Which is impossible without hearing the result. Maybe PA has some magic powers to do that. 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 11-08-2012 23:33, Baho Utot wrote: On 08/11/2012 06:15 PM, Tom Gundersen wrote: On Sun, Aug 12, 2012 at 12:03 AM, Fons Adriaensen f...@linuxaudio.org wrote: So imagine the average desktop user who gets five or so of them: - one provided by the application (player or something) - one provided by PA or similar, - probably two by the soundcard mixer, PA combines these three into one. So the non-audio-engineer user should have a lot bigger chance of not messing things up with PA compared to with pure ALSA (where you do have to fiddle with all the mixers and the application mixer on top). Sorry if this was what you were trying to point out. -t As a non-audio-engineer trying to adjust the sound level in vlc PA keep messing up my sound level (going to full 100%) any time I tried to adjust it. Just ask my wife for conformation as she didn't like the 100% volume every time I adjusted the sound level in vlc or xmms etc. So try to adjust the volume I did.but wait I'll get it right this timeTurn the damn thing down She screamed. Ok just let me. TURN THE DAMN THING OFF!!! Removed PA and only using ALSA equals working properly. As a bonus there is peace in the house ;) Did you try flat-volumes = no -- Mauro Santos
Re: [arch-general] OT: [arch-dev-public] polkit package upgrade patch
On Sun, Aug 12, 2012 at 1:23 AM, Fons Adriaensen f...@linuxaudio.org wrote: If that is true it is completely wrong from the start. Because that setup can't be maintained when a second app starts playing which can happen at any time. Suppose that first (single) app has its volume set to some low value, and PA uses the soundcard PCM gain control to achieve that as you claim it does. Now suddenly there's a second app which wants a higher level. The only way to achieve that is to raise the hardware gain - you can't compensate for a low setting there by sending a louder signal, it would just clip. So PA now has to adjust the hardware gain and at the same time start scaling down the output from the first app. It's impossible to do that in any acceptable way. Yet that's exactly what it does. And on my system (HDAudio) I have not noticed any changes in the volume of the first stream, even as the Master mixer control jumped levels. Maybe ask the devs for details.
Re: [arch-general] OT: [arch-dev-public] polkit package upgrade patch
On Sun, 2012-08-12 at 00:15 +0200, Tom Gundersen wrote: On Sun, Aug 12, 2012 at 12:03 AM, Fons Adriaensen f...@linuxaudio.org wrote: So imagine the average desktop user who gets five or so of them: - one provided by the application (player or something) - one provided by PA or similar, - probably two by the soundcard mixer, PA combines these three into one. So the non-audio-engineer user should have a lot bigger chance of not messing things up with PA compared to with pure ALSA (where you do have to fiddle with all the mixers and the application mixer on top). Sorry if this was what you were trying to point out. Pff! http://www.freedesktop.org/wiki/Software/PulseAudio/Backends/ALSA/Decibel Muahaha. Mauahahahahah! - Lennart Poettering Regards, Ralf
Re: [arch-general] OT: [arch-dev-public] polkit package upgrade patch
On 12-08-2012 00:41, Baho Utot wrote: On 08/11/2012 07:37 PM, Mauro Santos wrote: On 11-08-2012 23:33, Baho Utot wrote: On 08/11/2012 06:15 PM, Tom Gundersen wrote: On Sun, Aug 12, 2012 at 12:03 AM, Fons Adriaensen f...@linuxaudio.org wrote: So imagine the average desktop user who gets five or so of them: - one provided by the application (player or something) - one provided by PA or similar, - probably two by the soundcard mixer, PA combines these three into one. So the non-audio-engineer user should have a lot bigger chance of not messing things up with PA compared to with pure ALSA (where you do have to fiddle with all the mixers and the application mixer on top). Sorry if this was what you were trying to point out. -t As a non-audio-engineer trying to adjust the sound level in vlc PA keep messing up my sound level (going to full 100%) any time I tried to adjust it. Just ask my wife for conformation as she didn't like the 100% volume every time I adjusted the sound level in vlc or xmms etc. So try to adjust the volume I did.but wait I'll get it right this timeTurn the damn thing down She screamed. Ok just let me. TURN THE DAMN THING OFF!!! Removed PA and only using ALSA equals working properly. As a bonus there is peace in the house ;) Did you try flat-volumes = no No just ripped out PA. That returned me back to what worked for me. That might have solved that particular problem. However it is still odd that the default is to have flat-volumes = yes, which causes system wide jumps in volume every single time any app changes its volume. Not very user friendly for something that aims to be easy to use :p. I don't have any complains with the machine I use now though. -- Mauro Santos
Re: [arch-general] OT: [arch-dev-public] polkit package upgrade patch
On Sun, Aug 12, 2012 at 01:41:01AM +0200, Jan Steffens wrote: On Sun, Aug 12, 2012 at 1:23 AM, Fons Adriaensen f...@linuxaudio.org wrote: If that is true it is completely wrong from the start. Because that setup can't be maintained when a second app starts playing which can happen at any time. Suppose that first (single) app has its volume set to some low value, and PA uses the soundcard PCM gain control to achieve that as you claim it does. Now suddenly there's a second app which wants a higher level. The only way to achieve that is to raise the hardware gain - you can't compensate for a low setting there by sending a louder signal, it would just clip. So PA now has to adjust the hardware gain and at the same time start scaling down the output from the first app. It's impossible to do that in any acceptable way. Yet that's exactly what it does. And on my system (HDAudio) I have not noticed any changes in the volume of the first stream, even as the Master mixer control jumped levels. This is completely sick. Any audio engineer trying to use a mixer that way would (and should) be fired for gross incompetence - immediately. 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, 2012-08-12 at 01:41 +0200, Jan Steffens wrote: On Sun, Aug 12, 2012 at 1:23 AM, Fons Adriaensen f...@linuxaudio.org wrote: If that is true it is completely wrong from the start. Because that setup can't be maintained when a second app starts playing which can happen at any time. Suppose that first (single) app has its volume set to some low value, and PA uses the soundcard PCM gain control to achieve that as you claim it does. Now suddenly there's a second app which wants a higher level. The only way to achieve that is to raise the hardware gain - you can't compensate for a low setting there by sending a louder signal, it would just clip. So PA now has to adjust the hardware gain and at the same time start scaling down the output from the first app. It's impossible to do that in any acceptable way. Yet that's exactly what it does. And on my system (HDAudio) I have not noticed any changes in the volume of the first stream, even as the Master mixer control jumped levels. Maybe ask the devs for details. http://mailman.archlinux.org/pipermail/arch-general/2012-August/029596.html
Re: [arch-general] OT: [arch-dev-public] polkit package upgrade patch
On Sun, Aug 12, 2012 at 1:23 AM, Fons Adriaensen f...@linuxaudio.org wrote: This is not correct. If the app has proper PA support (such as all KDE apps, and probably all gnome apps), then PA does the app specific mixing, not the app itself. That doesn't stop the app from having its own internal volume control that PA doesn't know about. That would not be proper PA support. An app can do all sorts of stupid stuff of course. Moreover, if only one app is playing sound then PA does no mixing at all, but passes it all directly to ALSA (and sets ALSA's controls of course). If that is true it is completely wrong from the start. Because that setup can't be maintained when a second app starts playing which can happen at any time. Suppose that first (single) app has its volume set to some low value, and PA uses the soundcard PCM gain control to achieve that as you claim it does. Now suddenly there's a second app which wants a higher level. The only way to achieve that is to raise the hardware gain - you can't compensate for a low setting there by sending a louder signal, it would just clip. So PA now has to adjust the hardware gain and at the same time start scaling down the output from the first app. It's impossible to do that in any acceptable way. That's how it works. I have not noticed any problems. How would the problems manifest themselves? I'm not an audio expert by any stretch of the imagination, but I think even I would be able to notice skipping, clipping, noise, ... What should I be listening for? Simple fact is that most soundcards, even if they have a 'mixer', can't mix PCM signals (i.e. signals from the software) - they can mix in a CD player, or an external mic input etc.). So for anything coming from the system there is just one path, which has two controls, the 'PCM' and the 'master'. The only way to correctly use them if there if there is software mixing is to set them once to their correct values (which may depend on what is connected externally), and them leave them alone and do the rest in software. So that's apparently not how it is done in PA. Why must it be done in this way? How can I verify that there is a problem? And then we haven't even touched the matter of different sample rates. It is correct that PA does not (cannot) change the sample rate on the fly. You have to pick one and stick to it (so if you pick the wrong one it will resample). 'A lot of meta-information' LOL. It will provide some usually meaningless and inconsistent names of controls, their min and max values, and if you're extremely lucky maybe some indication mapping control values to dB, which may or may not be correct (and if it isn't that's not ALSA's fault, it just crappy and undocumented harware). All of that is visible in alsamixer. Yes, this is exactly what PA uses. ALAS just displays it without using it. Yes, absolutely. It may take the user some time to understand the quirks of his soundcard (such as that it's not capable of outputting full digital level without distortion, no matter how the controls are set, or even crappier shortcomings). But he will usually find a way to get things working. Which is impossible without hearing the result. Maybe PA has some magic powers to do that. It seems to me that PA is much better than this than what I am. I used to struggle with getting my laptop to output the exact volume I wanted without clipping, but now PA does its magic and it just works. I won't claim to know everything about this topic, but I'm interested in hearing more about why you claim that what PA does is impossible. -t
Re: [arch-general] OT: [arch-dev-public] polkit package upgrade patch
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
Re: [arch-general] OT: [arch-dev-public] polkit package upgrade patch
On Sun, 2012-08-12 at 02:43 +0200, Tom Gundersen wrote: On Sun, Aug 12, 2012 at 1:23 AM, Fons Adriaensen f...@linuxaudio.org wrote: If that is true it is completely wrong from the start. Because that setup can't be maintained when a second app starts playing which can happen at any time. Suppose that first (single) app has its volume set to some low value, and PA uses the soundcard PCM gain control to achieve that as you claim it does. Now suddenly there's a second app which wants a higher level. The only way to achieve that is to raise the hardware gain - you can't compensate for a low setting there by sending a louder signal, it would just clip. So PA now has to adjust the hardware gain and at the same time start scaling down the output from the first app. It's impossible to do that in any acceptable way. That's how it works. I have not noticed any problems. How would the problems manifest themselves? I'm not an audio expert by any stretch of the imagination, but I think even I would be able to notice skipping, clipping, noise, ... What should I be listening for? It only can work without clipping, if first the volume is lowered with more headroom than needed, because you can't know how much headroom you exactly need and then the second volume will be raised until an equal level is reached and this step by step. But how does PA know at what step the level is equal, when the audio signal isn't a constant tone? Poettering expect a perfect control values to dB(FS) mapping?! You at least will hear skipping. Or else, Poettering add at the end of the chain a hardcore multi-band compression, which would be very audible and unwanted too. Simple fact is that most soundcards, even if they have a 'mixer', can't mix PCM signals (i.e. signals from the software) - they can mix in a CD player, or an external mic input etc.). So for anything coming from the system there is just one path, which has two controls, the 'PCM' and the 'master'. The only way to correctly use them if there if there is software mixing is to set them once to their correct values (which may depend on what is connected externally), and them leave them alone and do the rest in software. So that's apparently not how it is done in PA. Why must it be done in this way? How can I verify that there is a problem? The analog output level has to fit to the input of your amplifier, to reduce noise and to avoid distortion. 'A lot of meta-information' LOL. It will provide some usually meaningless and inconsistent names of controls, their min and max values, and if you're extremely lucky maybe some indication mapping control values to dB, which may or may not be correct (and if it isn't that's not ALSA's fault, it just crappy and undocumented harware). All of that is visible in alsamixer. Yes, this is exactly what PA uses. ALAS just displays it without using it. So PA does use Voodoo?!
[arch-general] OT: [arch-dev-public] polkit package upgrade patch
On Fri, 2012-08-10 at 08:47 -0400, Baho Utot wrote: On 08/10/2012 08:11 AM, Ralf Mardorf wrote: OT: Btw. it would be nice if everybody has got the choice to use or not to use systemd. IMO there's no need to talk about pros and cons, Poettering again and again. I suspect we use different mail clients, daemons etc. too. Sadly, I don't think in the long run that will be possible, given that systemd has taken over udev and udev is now a part of systemd. In April 2012, udev's source tree was merged into systemd. At the moment it is possible :). Once systemd should work for everybody, it would be ok to switch. I just hope there will be no switch until systemd could cause issues. I'm very pissed about how PA was hammered in Linux. It has broken many working systems and many people testing Linux for the first time, directly throw Linux away, since nobody likes a default install with broken audio. PA until today is pure crap for MOST computer users (including those who try to switch to Linux), I don't like to hear again and again, that it does work for most Linux users, I even DOUBT that very much.
Re: [arch-general] OT: [arch-dev-public] polkit package upgrade patch
On 10 Aug 2012 22:52, Ralf Mardorf ralf.mard...@alice-dsl.net wrote: . PA until today is pure crap for MOST computer users (including those who try to switch to Linux), I don't like to hear again and again, that it does work for most Linux users, I even DOUBT that very much. This again? Let's paraphrase:- Software X sucks for most users, since I've personally read 3 million separate user complaints. Don't tell me I'm wrong because I know I'm not. I don't care that all the biggest distros use software X, their users obviously don't play music. Oh, and very few people actually use simple stereo audio chips, the majority of people use multi channel audio cards to listen to their YouTube. Copy, paste, on all the mailing lists I frequent. Do you have any idea how ridiculous this sounds, after a while?
Re: [arch-general] OT: [arch-dev-public] polkit package upgrade patch
On Fri, 2012-08-10 at 23:50 +0800, Oon-Ee Ng wrote: On 10 Aug 2012 22:52, Ralf Mardorf ralf.mard...@alice-dsl.net wrote: . PA until today is pure crap for MOST computer users (including those who try to switch to Linux), I don't like to hear again and again, that it does work for most Linux users, I even DOUBT that very much. This again? Let's paraphrase:- Software X sucks for most users, since I've personally read 3 million separate user complaints. Don't tell me I'm wrong because I know I'm not. I don't care that all the biggest distros use software X, their users obviously don't play music. Oh, and very few people actually use simple stereo audio chips, the majority of people use multi channel audio cards to listen to their YouTube. Copy, paste, on all the mailing lists I frequent. Do you have any idea how ridiculous this sounds, after a while? I tried to avoid this OT, apologize. I always forget that Linux is the most used OS in the universe and that I'm the only one who isn't fine with some rulings. However, the topic is polkit package upgrade patch. As already reported, both, the version from the repositories + this patched version works with the NM applet on my Xfce, unfortunately the patched version brakes Thunar.
Re: [arch-general] OT: [arch-dev-public] polkit package upgrade patch
On 08/10/2012 11:50 AM, Oon-Ee Ng wrote: On 10 Aug 2012 22:52, Ralf Mardorf ralf.mard...@alice-dsl.net wrote: . PA until today is pure crap for MOST computer users (including those who try to switch to Linux), I don't like to hear again and again, that it does work for most Linux users, I even DOUBT that very much. This again? Let's paraphrase:- Software X sucks for most users, since I've personally read 3 million separate user complaints. Don't tell me I'm wrong because I know I'm not. I don't care that all the biggest distros use software X, their users obviously don't play music. Oh, and very few people actually use simple stereo audio chips, the majority of people use multi channel audio cards to listen to their YouTube. Copy, paste, on all the mailing lists I frequent. Do you have any idea how ridiculous this sounds, after a while? I don't wish to get into that particular disagreement but.. pulse audio doesn't work for me in the two boxen I have it on. It just gets in the way and when it is removed I can set my audio just how I want it. With pulse it just takes over the master volume when it try to adjust audio in an application cranking the master volume to full. Without pulse it just works the way I like it to be. So count me as one of the ones who doesn't like pulse audio.
Re: [arch-general] OT: [arch-dev-public] polkit package upgrade patch
On Aug 10, 2012 5:59 PM, Ralf Mardorf ralf.mard...@alice-dsl.net wrote: As already reported, both, the version from the repositories + this patched version works with the NM applet on my Xfce, unfortunately the patched version brakes Thunar. Thanks. Tom
Re: [arch-general] OT: [arch-dev-public] polkit package upgrade patch
On Fri, 2012-08-10 at 23:50 +0800, Oon-Ee Ng wrote: Oh, and very few people actually use simple stereo audio chips, the majority of people use multi channel audio cards to listen to their YouTube. Puleaudio doesn't work for many people simply using stereo with on-board devices. We are living in the mass media age, so multi channel cards are not that seldom, resp. stereo cards with better sound quality, that are based on microchips such as the Envy24.
Re: [arch-general] OT: [arch-dev-public] polkit package upgrade patch
On Aug 10, 2012 6:09 PM, Ralf Mardorf ralf.mard...@alice-dsl.net wrote: On Fri, 2012-08-10 at 23:50 +0800, Oon-Ee Ng wrote: Oh, and very few people actually use simple stereo audio chips, the majority of people use multi channel audio cards to listen to their YouTube. Puleaudio doesn't work for many people simply using stereo with on-board devices. We are living in the mass media age, so multi channel cards are not that seldom, resp. stereo cards with better sound quality, that are based on microchips such as the Envy24. Please guys, not again... Take your concerns upstream, nothing will come off rehashing them here for the hundredths time. Tom
Re: [arch-general] OT: [arch-dev-public] polkit package upgrade patch
On Fri, 10 Aug 2012 18:04:39 +0200
Tom Gundersen t...@jklm.no wrote:
On Aug 10, 2012 5:59 PM, Ralf Mardorf ralf.mard...@alice-dsl.net wrote:
As already reported, both, the version from the repositories + this
patched version works with the NM applet on my Xfce, unfortunately the
patched version brakes Thunar.
Thanks.
Tom
Except mounting issues, do I correctly understand that polkit 0.107 enables
correct seat/session assigment in conjuction with systemd-logind even without
a login helper (like {G,K}DM)?
Thanks.
--
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 Aug 10, 2012 6:32 PM, Leonid Isaev lis...@umail.iu.edu wrote:
On Fri, 10 Aug 2012 18:04:39 +0200
Tom Gundersen t...@jklm.no wrote:
On Aug 10, 2012 5:59 PM, Ralf Mardorf ralf.mard...@alice-dsl.net
wrote:
As already reported, both, the version from the repositories + this
patched version works with the NM applet on my Xfce, unfortunately the
patched version brakes Thunar.
Thanks.
Tom
Except mounting issues, do I correctly understand that polkit 0.107
enables
correct seat/session assigment in conjuction with systemd-logind even
without
a login helper (like {G,K}DM)?
No. That is a separate problem. The patched version will ask logind for
information about the session, but for that to work, a pam session must
have been set up correctly and be registered with logind. For this a login
manager (our an xinit hack) is needed.
Tom
Re: [arch-general] OT: [arch-dev-public] polkit package upgrade patch
On Fri, 2012-08-10 at 11:31 -0500, Leonid Isaev wrote:
On Fri, 10 Aug 2012 18:04:39 +0200
Tom Gundersen t...@jklm.no wrote:
On Aug 10, 2012 5:59 PM, Ralf Mardorf ralf.mard...@alice-dsl.net wrote:
As already reported, both, the version from the repositories + this
patched version works with the NM applet on my Xfce, unfortunately the
patched version brakes Thunar.
Thanks.
Tom
Except mounting issues, do I correctly understand that polkit 0.107 enables
correct seat/session assigment in conjuction with systemd-logind even without
a login helper (like {G,K}DM)?
Thanks.
No, I'm not using systemd-logind, but
$ pacman -Qi gdm
Name : gdm
Version: 3.4.1-2
$ ls /etc/systemd/logind.conf
ls: cannot access /etc/systemd/logind.conf: No such file or directory
Yes, GDM for starting Xfce, while not using PA, perhaps a strange
combination.
Regards,
Ralf
Re: [arch-general] OT: [arch-dev-public] polkit package upgrade patch
On Fri, 2012-08-10 at 21:43 +0200, Heiko Baums wrote: And run a `ls /usr/lib/systemd/system`. The harddisk is filled up with a bunch of systemd stuff which I don't need and don't want to have. Hm? IIRC console-kit has a replacement when using systemd, so those and perhaps other files perhaps have nothing to do with systemd? spinymouse@precise:~$ ls -hl /mnt/archlinux/usr/lib/systemd/system/console* -rw-r--r-- 1 root root 432 May 27 06:29 /mnt/archlinux/usr/lib/systemd/system/console-kit-daemon.service -rw-r--r-- 1 root root 219 May 27 06:29 /mnt/archlinux/usr/lib/systemd/system/console-kit-log-system-restart.service -rw-r--r-- 1 root root 201 May 27 06:29 /mnt/archlinux/usr/lib/systemd/system/console-kit-log-system-start.service -rw-r--r-- 1 root root 218 May 27 06:29 /mnt/archlinux/usr/lib/systemd/system/console-kit-log-system-stop.service *?*
Re: [arch-general] OT: [arch-dev-public] polkit package upgrade patch
On Fri, 2012-08-10 at 22:04 +0200, Ralf Mardorf wrote: On Fri, 2012-08-10 at 21:43 +0200, Heiko Baums wrote: And run a `ls /usr/lib/systemd/system`. The harddisk is filled up with a bunch of systemd stuff which I don't need and don't want to have. Hm? IIRC console-kit has a replacement when using systemd, so those and perhaps other files perhaps have nothing to do with systemd? spinymouse@precise:~$ ls -hl /mnt/archlinux/usr/lib/systemd/system/console* -rw-r--r-- 1 root root 432 May 27 06:29 /mnt/archlinux/usr/lib/systemd/system/console-kit-daemon.service -rw-r--r-- 1 root root 219 May 27 06:29 /mnt/archlinux/usr/lib/systemd/system/console-kit-log-system-restart.service -rw-r--r-- 1 root root 201 May 27 06:29 /mnt/archlinux/usr/lib/systemd/system/console-kit-log-system-start.service -rw-r--r-- 1 root root 218 May 27 06:29 /mnt/archlinux/usr/lib/systemd/system/console-kit-log-system-stop.service *?* PS: Any explanations are welcome, seemingly those are systemd files. spinymouse@precise:~$ cat /mnt/archlinux/usr/lib/systemd/system/console-kit-log-system-start.service [Unit] Description=Console System Startup Logging DefaultDependencies=no After=sysinit.target Before=shutdown.target [Service] Type=oneshot ExecStart=/usr/sbin/ck-log-system-start RemainAfterExit=yes
Re: [arch-general] OT: [arch-dev-public] polkit package upgrade patch
Systemd and pulseaudio are completely different pieces of software with different purposes. Comparing them like that just because of the author is comparing apples to oranges. On Fri, Aug 10, 2012 at 3:43 PM, Heiko Baums li...@baums-on-web.de wrote: Am Fri, 10 Aug 2012 18:27:33 +0200 schrieb Tom Gundersen t...@jklm.no: Please guys, not again... Take your concerns upstream, nothing will come off rehashing them here for the hundredths time. Those concerns have been reported upstream a long while ago. They are just ignored resp. upstream doesn't have any better to do than to blaming ALSA even if ALSA supports those audio cards perfectly out-of-the-box. Then PA upstream has written an obscure ALSA configuration which crippled those cards down to simple stereo cards and closed the bug report as fixed even if this is not even a dirty workaround. Now, after a lot of discussions on several mailing lists, they suddenly say that PA is only meant for desktop purposes, but not for professional audio. On the other hand they do everything to make it a pseudo standard. And systemd seems to be similar. I also don't like that you want to imprint this systemd stuff everybody even if one doesn't have systemd installed. See systemd-tools and systemd-cryptsetup. Well, I know that you filed the issue about reading the key rawly from a block device to upstream. But they did forgot it. What else did they forget? I have the impression that Lennart only thinks halfway through and doesn't have much knowledge about professional computer and UNIX usage. Maybe his ideas have some good aspects, but he simply can't implement it professionally and in a UNIX style. He seems to only think about desktop users but definitely not about (semi-)professional users. And run a `ls /usr/lib/systemd/system`. The harddisk is filled up with a bunch of systemd stuff which I don't need and don't want to have. But I am forced to have at least half of systemd on my harddisk, even if I don't want to have systemd. Just a few concerns which not only belong to upstream. And, no. The software does not or at least should not ripen at the users, at least not so much as it needs to with Poetterix. Heiko
Re: [arch-general] OT: [arch-dev-public] polkit package upgrade patch
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/10/2012 09:02 AM, Baho Utot wrote: On 08/10/2012 11:50 AM, Oon-Ee Ng wrote: On 10 Aug 2012 22:52, Ralf Mardorf ralf.mard...@alice-dsl.net wrote: . PA until today is pure crap for MOST computer users (including those who try to switch to Linux), I don't like to hear again and again, that it does work for most Linux users, I even DOUBT that very much. This again? Let's paraphrase:- snip Copy, paste, on all the mailing lists I frequent. Perhaps the fact that so many people--myself included--have had problems with PulseAudio that are most easily solved by removing PulseAudio ought to be taken into consideration. But PulseAudio evangelists rarely, if ever, respond meaningfully to this point. That suggests that the attachment to PulseAudio is based in emotion rather than in reason. Emotion is a legitimate basis for decisionmaking. But it is also legitimate for others to choose what works for them. Do you have any idea how ridiculous this sounds, after a while? I don't wish to get into that particular disagreement but.. pulse audio doesn't work for me in the two boxen I have it on. It just gets in the way and when it is removed I can set my audio just how I want it. It's interesting that there is so much evangelism for PulseAudio. If it really worked as advertised, 1) such evangelism would not be necessary, and 2) the topic might not come up so often. But what's really interesting is that the topic appears even here on an Arch mailing list, since Arch--as far as I know--wouldn't foist PulseAudio on anybody unless they wanted it. - -- 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/ iQIcBAEBAgAGBQJQJX3FAAoJELT202JKF+xpLRgP/jA788xHe6kTka8WnDQW6W+e HD/8o3xeIdJA2sSh8wjDS7jqvacd8yp5sHZNa7P1r5AcOfx4paUniitvNaBfLmhC yY2MfsSM/iLIzgTWOWbKZNBSFt8uxPd52oD2JyEgS9l9dRPl13DSlRy9ZC2+94Kt TdAg7sL+23DTtFhLsa2z54rlglwGblo41QaEp8MMPUcy1HpaFKcwpEw9TSVKD71D WPo7JVQZF3y8eOtNEaRzHZKYOaTmoqarn32VR26jp4Dw9Wzr3OWpCgYIkRwR+2eI rjsdYVFasMs+BbKjafl6hTVH9ky1INgmXcYBpDGQrim3qCEWVlLcw3PAyKMnXpet g4SHT4owYqrWfTABVaTcHX+C6BjIVoNMOjdN78gHVBqPcaO4QevdDKp6cFeu90b1 bQ3C/YYHev+A8KLCv02bbwTws0uKtcS/AbaSgBjNXRV45RNZ+myzDDNqMtH5z6DM lZC+ywkNZlHW3mFqsBOfrQq2KjwUW2/F6JoIvvX+7PspFXxP7B+s1djKHL7i2VVU 5t+g/EJFxgn4DxTUxa6qOheJEBntqUUj5whNNVHJ5+XMnba/iVs6HMhrfQKsDZCJ QkClneV14dkuvtS//X+PCJ4qXkcA0096hNwk6QI7bL4gMHZaEjcctK1XRybL1bs7 ppoIXsSYeEWd8kiWkM3T =a0+y -END PGP SIGNATURE-
Re: [arch-general] OT: [arch-dev-public] polkit package upgrade patch
Am Fri, 10 Aug 2012 23:38:15 +0200 schrieb Heiko Baums li...@baums-on-web.de: I really haven't seen so many and so long discussions and so many concerns and very negative opinions about a software than I have seen about Lennart's software. And I'm not only reading this mailing list. See e.g. pro-linux.de or heise.de (both in German). Every time when there's an article about PA or systemd a lot of people are railing against PA, systemd and Lennart. And it's definitely not only me. That said, nearly every comment on heise.de against PA, systemd and Lennart Poettering gets a lot of green, and heise is very well known IT publisher and has a lot of readers. Also such comments on pro-linux.de get regularly a lot of approval and positive feedback. Heiko
Re: [arch-general] OT: [arch-dev-public] polkit package upgrade patch
On Fri, Aug 10, 2012 at 9:43 PM, Heiko Baums li...@baums-on-web.de wrote: [snip: lots of whining about pulse audio] This is not the right mailinglist for this issue. And this certainly is not the right thread for it. And systemd seems to be similar. I also don't like that you want to imprint this systemd stuff everybody even if one doesn't have systemd installed. You are free to reimplement all those tools and ship a competing package. The configuration formats are well-documented, so it should not be hard. See systemd-tools and systemd-cryptsetup. Well, I know that you filed the issue about reading the key rawly from a block device to upstream. But they did forgot it. What are you talking about? No one forgot anything. This is what happened: You pointed out a feature that initsrcipts used to have which systemd-cryptsetup lacked, (on the same day) I posted a patch to implement the feature you requested, and asked for feedback (which you didn't give), one week later I posted the patch upstream and (on the same day) Lennart replied: Applied. The functionality should now be part of systemd 188, which is in testing. What more could you possibly ask for? I have the impression that Lennart only thinks halfway through and doesn't have much knowledge about professional computer and UNIX usage. Maybe his ideas have some good aspects, but he simply can't implement it professionally and in a UNIX style. He seems to only think about desktop users but definitely not about (semi-)professional users. I have the impression that you don't have a clue what you are talking about. And run a `ls /usr/lib/systemd/system`. The harddisk is filled up with a bunch of systemd stuff which I don't need and don't want to have. But I am forced to have at least half of systemd on my harddisk, even if I don't want to have systemd. Why don't you just delete the things you don't want? -t
Re: [arch-general] OT: [arch-dev-public] polkit package upgrade patch
On Fri, Aug 10, 2012 at 11:38 PM, Heiko Baums li...@baums-on-web.de wrote: If you buy a book at Amazon e.g., what do you read? Only the best 5-star reviews or also the 1-star reviews? I tell you something. Not always but a lot of times the fewer 1-star reviews are the better and more realistic ones. I prefer the reviews (good or bad) from someone who has actually read the book. -t
Re: [arch-general] OT: [arch-dev-public] polkit package upgrade patch
On Fri, 10 Aug 2012 23:38:15 +0200 Heiko Baums li...@baums-on-web.de wrote: Am Fri, 10 Aug 2012 16:33:39 -0400 schrieb Brandon Watkins bwa...@gmail.com: Systemd and pulseaudio are completely different pieces of software with different purposes. Comparing them like that just because of the author is comparing apples to oranges. Sorry, it is not. I see that PA is totally not complete and doesn't support at least half of the professional use cases. And I see that it's the same with systemd. So what's the difference? They are both developed by the same person who seemingly doesn't have much knowledge about professional computer usage and only cares about some desktop users. With PA it's currently not such a problem since I don't need to use a distro or a desktop environment which forces me to install PA. With systemd it's worse since the init system is a very serious and important piece of the system. And if this doesn't support every professional use case and isn't proved to be really reliable, it just shouldn't be made to a de facto standard. And if I can't trust PA how can I trust an even more important piece of software written by the same person? Btw., look at systemd-cryptsetup. Yes, meanwhile my use case is filed upstream and allegedly and hopefully fixed. But it shows that at least one use case was just forgotten or in other words it was not well enough thought out. The latter is the biggest problem. Like I said before, some of Lennart's ideas may, say, seem to be quite interesting, and maybe sysvinit is also not the perfect init system. But Lennart's software is just not implemented good enough. And here I thought that there were some SuSE people from udev team behind systemd... Do we always have to get personal? If somebody doesn't care about the professional users when writing on software, would he really care about the professional users when writing the other software? AFAICT professional = constructive: if you find a problem there is no point in admiring yourself and calling everyone else morons, help fixing it instead. Otherwise, please show me a piece of software which is free of bugs. I really haven't seen so many and so long discussions and so many concerns and very negative opinions about a software than I have seen about Lennart's software. And I'm not only reading this mailing list. See e.g. pro-linux.de or heise.de (both in German). Every time when there's an article about PA or systemd a lot of people are railing against PA, systemd and Lennart. And it's definitely not only me. Seems to me that some people have way too much free time... There must be a reason, and the reasons are always mentioned. There are bug reports upstream, but they are just ignored. Lennart mentions all those rants in at least one of his documentations. So he even knows about all those criticisms. What's he doing? He ignores them totally. In the same sentence he just laughs at those people, and call them so to say (not literally) stupid. Is this really a good and trustworthy attitude? I think, not. And all those comments here like oh no, not this again, Please guys, not again... or Take your concerns upstream, ..., is really not helpful. On the contrary this all is also an issue for downstream. See the ongoing infiltration of initscripts by systemd here in Arch Linux. Sorry to say that, but it's really not the best idea. And do you think it's a good idea to spam my inbox? Ah, right, I should unsubscribe. Keep PA and systemd totally optional including every part of it, and everything is Ok. I'm sure nobody would mind. But as long as there are people working on making both software a de facto standard and forcing it on everybody, this discussion will never end. Not only here. Noone is forcing anything on anyone... Just take all those people who have a lot of concerns for some very good reasons serious. Examples welcome... There wouldn't be so many, so long discussions every time PA, systemd or Lennart Poettering is mentioned if this all was such a very good, perfect and professional software. If this was the case then I'm sure that everybody couldn't wait to get it and a lot of people would ask when it will be available. Instead a lot of people on the web rail against them. So think about that, and think long and good. Maybe there are a few use cases for which PA is working and for which PA makes sense. But there are a lot of use cases for which PA does not work. The same for systemd. So think about the use cases for which they don't work. Btw., someone else here on this mailing list has mentioned a lot of software which, as he said, do the same as systemd does allegedly better than sysvinit, but on top of sysvinit and in a more UNIX like way. There came not even one word, one short discussion about those suggestions. It was not considered if those software could be the better alternative. Instead
Re: [arch-general] OT: [arch-dev-public] polkit package upgrade patch
On Sat, 11 Aug 2012 00:59:25 +0200, Leonid Isaev lis...@umail.iu.edu wrote: Do we always have to get personal? Seems to me that some people have way too much free time... And do you think it's a good idea to spam my inbox? Ah, right, I should unsubscribe. I don't read reviews because relevant people you should listen to are too busy to write them. Yes, everybody who mentions cons about system relevant broken software has to much time. Perhaps important, relevant people would have more time too, if they wouldn't use borked, system relevant software ;). This kind of argumentation IMO is more near to spam, then to mention again and again, that pulseaudio is a serious issue and people fear that systemd will become a serious issue too. Some people don't have the time to test and brake their Linux, that doesn't mean that people with enough free time are losers, IMO somebody who doesn't have enough free time should learn to manage the live better. I just wonder why a discussion needs to become that personal. Heiko didn't become personal. Writing about somebody who does hardcore public relations is something completely different, than defamation of people who might have too much free time, just because they have another opinion or read the book reviews of people that aren't that smart, as the people you would listen too. Why not simply stopping that discussion, instead of feeding it with such a defamation? :) Ralf
Re: [arch-general] OT: [arch-dev-public] polkit package upgrade patch
Am Sat, 11 Aug 2012 00:57:46 +0200 schrieb Tom Gundersen t...@jklm.no: I prefer the reviews (good or bad) from someone who has actually read the book. You can usually assume that everybody who writes a review has actually read the book. Heiko
Re: [arch-general] OT: [arch-dev-public] polkit package upgrade patch
Am Sat, 11 Aug 2012 00:56:33 +0200 schrieb Tom Gundersen t...@jklm.no: This is not the right mailinglist for this issue. And this certainly is not the right thread for it. This is the right mailing list for this issue, because downstream is also affected by this. And it is also downstream's decision whether to ship systemd or not. And you do it by forcing all that systemd stuff like systemd-tools and all those service files on every user if he wants to have systemd on his system or not. So this IS the right mailing list. You are free to reimplement all those tools and ship a competing package. The configuration formats are well-documented, so it should not be hard. Why would I? There are tools which are working. Systemd is still not working. For cryptsetup there was and currently still is a working code in initscripts. So principally no need to use some systemd-tools for this. And this code covered a lot more use cases than systemd-cryptsetup originally. And I know this code, because I have written at least most part of this code. The syntax could indeed a bit more clearer, but that could have been done without systemd-cryptsetup. What about all the already existing tools, someone else recently mentioned here on the list? Still no word about them. Still no discussion it they are sufficient or probably better than systemd. What are you talking about? No one forgot anything. This is what happened: You pointed out a feature that initsrcipts used to have which systemd-cryptsetup lacked, (on the same day) I posted a patch to implement the feature you requested, and asked for feedback (which you didn't give), one week later I posted the patch upstream and (on the same day) Lennart replied: Applied. The functionality should now be part of systemd 188, which is in testing. What more could you possibly ask for? Just simple. I ask for first thinking about use cases and about reliability before writing such a tool and before trying to make it a de facto standard. I ask for thinking about professional users and their usage. And I ask for firstly learning about professional computer usage and about UNIX and the UNIX principle. And first of all I mean Lennart Poettering in this case. That's only one point. I, btw., also mentioned that you filed a bug report about this particular issue to upstream and that it is hopefully fixed. But nevertheless it shows that systemd was not complete, and that the systemd developer didn't think enough before releasing it, exactly like PulseAudio. I have the impression that you don't have a clue what you are talking about. And all those people who criticise PA, systemd and Lennart Poettering, too, have also no clue about what they are talking? All those people who mark those comments in several other forums totally green and who send comments in which they agree have also no clue? They are all stupid? And only you have the necessary knowledge? And only you are the wisdom in person? Is this what you want to say? I have the impression that you are one of those systemd fanboys, and just don't want to hear that systemd and PA have a lot of serious issues. And like I said in another thread, we're not talking about some fancy stuff like installing a GTK theme or the like. We're talking about serious and important, system relevant stuff. Btw., still no word about the reasons, why there are regularly so many and so long discussions about PA, systemd and Lennart Poettering, and not only here on this mailing list, but everywhere on the web. Still no word why those many, long discussions only appear about PA, systemd and Lennart Poettering and not about any other piece of software. You really should start thinking about this. And you should start soon. You really should take off your rose-colored glasses. Why don't you just delete the things you don't want? Why are those things, which I don't need and want, installed? Why am I forced to have this systemd stuff installed? And what, if I delete them manually? Shall I always delete them again and again after every system update? Sorry, that's not the way to go. Like I said before, if you would support systemd, sytemd-tools and everything else related to systemd totally optional, and keep initscripts pure initscripts without any systemd stuff like it was before, I would say nothing. But since you really force the users to install this systemd stuff, you will have to live with such comments, and not only from me, as you should know. Heiko
Re: [arch-general] OT: [arch-dev-public] polkit package upgrade patch
Am Sat, 11 Aug 2012 00:56:33 +0200 schrieb Tom Gundersen t...@jklm.no: You pointed out a feature that initsrcipts used to have which systemd-cryptsetup lacked, (on the same day) I posted a patch to implement the feature you requested, and asked for feedback (which you didn't give) Just to mention, you've also written that this patch you've written should not be used or tested in stable, productive environments. I only have one PC which needs to run stably and reliably. I can't run into danger that my data gets accidentally corrupted. And I don't trust systemd this much, but I trust my initscripts code. And I hadn't had time to set up a VM. Heiko
