8:59 a.m.
Heya!
I'd like to draw your attention to the new mixer handling logic in PA
0.9.16/F12. It includes a number of improvements:
- We now support input and output "ports". i.e. switching between
Mic/Line-In resp. Speaker/Headphones. Only one of those ports can be
active per sink at a time.
- we merge a number of low-level mixer controls into a single
slider. This has various advantages: we become less dependant on
correct mixer initialization done by "alsactl init"; we get a better
hardware volume granularity and range; we can make use of ALSA's
surround volume controls ("Front", "Rear", yadda yadda).
- We support semi-pro/pro sound cards much better and can wrap more
than just one channel of them (Currently done for two Native
Instruments Audio4DJ cards)
- The supported profiles and what to do with the alsa controls are no
longer hard coded in PA, but can be changed without recompiling via
the config files in /usr/share/pulseaudio/alsa-mixer/
In the F11 cycle there has been some criticism on how g-v-c was
presenting a new minimal volume control interface. Most issues raised
back then should now be fixed, except for a few which we consider
strictly out of focus for us.
I'd like to ask everyone to test this new volume logic. If you don't
raise your voice now that some output port is not properly detected or
audio is too faint then later on you won't have any right to complain.
You should particularly pay attention to the new "Hardware" tab in
g-v-c, where you can now choose the hardware profile (i.e. stereo
vs. 5.1, and so on) which you want to use. And then on the
Input/Output tab you may or may not find an additional dropdown menu
for selecting the port you want to use (only shown if you have more
than one).
When you test this, please make sure to run version 0.9.16-4.test3 of
PA and 2.27.5 of gnome-media at least. Both are still stuck in Koji,
aren't in Rawhide yet.
Please note that it is our intention not to wrap obsolete mixer
controls such as "CD", "PC Speaker", "MIDI" and so on. If
you file a
bug asking for those to be wrapped we will disappoint you and
close the bug WONTFIX.
gst-mixer is not longer listed as default in comps now.
Without too much effort it is now possible to change the way PA sees
the alsa mixer, for an explanation how to do that, consider reading this:
https://tango.0pointer.de/pipermail/pulseaudio-discuss/2009-June/004229.html
That mail also goes a bit into detail on the technical background of
these changes, might be an interesting read for everyone.
Lennart
--
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
9:06 a.m.
On Tue, 2009-07-28 at 15:59 +0200, Lennart Poettering wrote:
When you test this, please make sure to run version 0.9.16-4.test3
of
PA and 2.27.5 of gnome-media at least. Both are still stuck in Koji,
aren't in Rawhide yet.
Any plan to push this in F11 at some point ? (even if it stays in
testing ?)
Thanks,
Pierre
1:56 p.m.
On Tue, 28.07.09 16:06, Pierre-Yves (pingou(a)pingoured.fr) wrote:
On Tue, 2009-07-28 at 15:59 +0200, Lennart Poettering wrote:
> When you test this, please make sure to run version 0.9.16-4.test3 of
> PA and 2.27.5 of gnome-media at least. Both are still stuck in Koji,
> aren't in Rawhide yet.
Any plan to push this in F11 at some point ? (even if it stays in
testing ?)
No. This change is very invasive.
(Also, I always considered a pretty bad idea to updated already
released distros for anything but security fixes and bugfixes.)
Lennart
--
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
11:40 a.m.
On Tue, Jul 28, 2009 at 15:59:58 +0200,
Lennart Poettering <mzerqung(a)0pointer.de> wrote:
When you test this, please make sure to run version 0.9.16-4.test3 of
PA and 2.27.5 of gnome-media at least. Both are still stuck in Koji,
aren't in Rawhide yet.
mirrors2.kernel.org already has the 20090728 rawhide repo with those packages
included.
1:32 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Lennart Poettering wrote:
Please note that it is our intention not to wrap obsolete mixer
controls such as "CD", "PC Speaker", "MIDI" and so on. If
you
file a
bug asking for those to be wrapped we will disappoint you and
close the bug WONTFIX.
Curious: would patches be accepted if someone else did it or is
there just no support at all?
- --Ben
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAkpvRE8ACgkQiPi+MRHG3qSPsgCffnOp1HQKybognuYBL0svUJ7l
cUYAoJ91fkfJ9TzAR17WYkBuK3z4UI6D
=htuX
-----END PGP SIGNATURE-----
1:40 p.m.
On Tue, Jul 28, 2009 at 8:32 PM, Ben Boeckel<MathStuf(a)gmail.com> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Lennart Poettering wrote:
> Please note that it is our intention not to wrap obsolete mixer
> controls such as "CD", "PC Speaker", "MIDI" and so on.
If you
file a
> bug asking for those to be wrapped we will disappoint you and
> close the bug WONTFIX.
Curious: would patches be accepted if someone else did it or is
there just no support at all?
as this would violate the design choices made I doubt such patches
would be accepted.
1:59 p.m.
On Tue, 28.07.09 14:32, Ben Boeckel (MathStuf(a)gmail.com) wrote:
Lennart Poettering wrote:
> Please note that it is our intention not to wrap obsolete mixer
> controls such as "CD", "PC Speaker", "MIDI" and so on.
If you
file a
> bug asking for those to be wrapped we will disappoint you and
> close the bug WONTFIX.
Curious: would patches be accepted if someone else did it or is
there just no support at all?
Let me stress that we explicitly decided not to expose those
controls. This has nothing to do with whether there are patches for
that or not. So yeah, if you file a bug with a patch this will most
likely be treated the same as a bug without a patch and closed
WONTFIX.
Lennart
--
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
7:32 a.m.
On Jul 28, 2009, at 2:59 PM, Lennart Poettering wrote:
On Tue, 28.07.09 14:32, Ben Boeckel (MathStuf(a)gmail.com) wrote:
> Lennart Poettering wrote:
>> Please note that it is our intention not to wrap obsolete mixer
>> controls such as "CD", "PC Speaker", "MIDI" and so
on. If you
> file a
>> bug asking for those to be wrapped we will disappoint you and
>> close the bug WONTFIX.
>
> Curious: would patches be accepted if someone else did it or is
> there just no support at all?
Let me stress that we explicitly decided not to expose those
controls. This has nothing to do with whether there are patches for
that or not. So yeah, if you file a bug with a patch this will most
likely be treated the same as a bug without a patch and closed
WONTFIX.
Will PA ever expose the Monitor capability of input ports? If not,
I'll have to keep using gst-mixer or something equivalent forever.
Just for clarification, here's my audio configuration:
iPhone -> 7.1 -> line in
5.1 speakers <- KVM <- front, center, rear, sub out
Logitech USB headset <-> headset mic in, headset out
The ports that are on the 7.1 KVM are shared with a Windows Vista
computer. The 5.1 speakers are used for everything except VoIP
output, which goes to the USB headset. The line in is only used for
the iPhone. The USB headset mic is used for VoIP.
Now, given this setup, here are the problems I've had:
Separately controlling volume of line in, and also setting line in
into monitor mode (which redirects analog input directly to speakers
without involving any digital data transfers to host, a hard
requirement for me as I refuse to waste DMA/CPU resources and doing a
wasted A/D then D/A conversion just to listen to my iPhone's
playlists, he says as he listens to "We Made You" - Eminem). Windows
Vista does this just fine. In order to get this under F11 I have to
use gst-mixer. And truly the same is viable for the CD in portion of
a hardware mixer. Every system I build still keeps the analog signal
cable between the CD/DVD and the soundcard. This doesn't help if I
try to watch a movie as that signal has to be decoded and then played,
but for audio CDs it is still a perfectly acceptable means of playing
the music. So I'm not sure where this "CD in is obsolete" comes
from. Even the motherboard I bought about 2 months ago still has a CD
in port and the CD/DVD in that machine still has an analog output.
Getting PA to accept (and keep) the proper default input/output source
across reboots, especially if the USB headset was either plugged in or
unplugged at boot which changes the alsa detection order of the
devices (this appears to be more reliable in F11 now, but was really
bad in F9, I skipped F10).
Interestingly enough, at login now in F11, it plays a sound over the
speakers, but also plays what sounds like undecoded noise over the USB
headset.
I haven't tried reverting my .procmailrc of my secondary mail account
to use paplay on certain messages again. I have a workaround in
place, but in the past, attempts to do so would delay mails for hours
until I killed the hung paplay program.
--
Doug Ledford <dledford(a)redhat.com>
GPG KeyID: CFBFF194
http://people.redhat.com/dledford
InfiniBand Specific RPMS
http://people.redhat.com/dledford/Infiniband
4:15 p.m.
On Thu, 2009-07-30 at 08:32 -0400, Doug Ledford wrote:
Interestingly enough, at login now in F11, it plays a sound over the
speakers, but also plays what sounds like undecoded noise over the
USB
headset.
That's a kernel bug:
https://bugzilla.redhat.com/show_bug.cgi?id=497742
4:53 p.m.
Doug Ledford wrote:
Every system I build still keeps the analog signal cable between the
CD/DVD and the soundcard. This doesn't help if I try to watch a movie
as that signal has to be decoded and then played, but for audio CDs
it is still a perfectly acceptable means of playing the music. So I'm
not sure where this "CD in is obsolete" comes from. Even the
motherboard I bought about 2 months ago still has a CD in port and
the CD/DVD in that machine still has an analog output.
CD is digital and can be read in digital format by your CPU and sent in
digital to the sound device. This is lossless.
You want to:
(D->A) do the DAC in the CD drive
(A) toss that on an analog wire
(A/A->D->A) apply an analog volume adjustment (if you're lucky; you
might actually end up doing a ADC, digital volume adjustment, DAC)
(A/A->D) toss that on a different wire that might be digital
(A/D->A) hear it from your speakers
You could:
(D) read the CD digital data
(D) toss said data to the sound device (losslessly!)
(D/D->A) apply a digital volume adjustment (or maybe analog volume
adjustment after DAC)
(D/D->A) send that, maybe digitally, to your speakers
(A/D->A) hear it from your speakers
What exactly is better about the first scenario? At *best* you're moving
the analog signal across a longer run of wire (and one that is inside
your computer case with who-knows-what shielding picking up
who-knows-what interference). At worst you've tossed several analog
elements into a process that could have been digital from disc to
speaker cones.
Seriously... do I miss something?
--
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
--
Disadvantage: Bad Puns [-5]
You constantly utter puns so egregious as to cause mental distress to
anyone hearing them. This can, however, be used to distract enemies.
5:36 p.m.
On Thu, 30.07.09 16:53, Matthew Woehlke (mw_triad(a)users.sourceforge.net) wrote:
Doug Ledford wrote:
> Every system I build still keeps the analog signal cable between the
> CD/DVD and the soundcard. This doesn't help if I try to watch a movie
> as that signal has to be decoded and then played, but for audio CDs
> it is still a perfectly acceptable means of playing the music. So I'm
> not sure where this "CD in is obsolete" comes from. Even the
> motherboard I bought about 2 months ago still has a CD in port and
> the CD/DVD in that machine still has an analog output.
CD is digital and can be read in digital format by your CPU and sent in
digital to the sound device. This is lossless.
Adding here:
The "analog" path for CDDA is completely broken and obsolete:
- It doesn't work with USB cd drives
- It doesn't work with USB sound cards
- It doesn't work with Bluetooth headsets
- It doesn't work with SPDIF out
- It doesn't work if you have more than one cd drive
- It doesn't work if you have more than one audio device
- Modern cards don't even have the connector anymore
- There is no way to get acces to the PCM data before playing it,
meaning no equalizers applied, no visualizations, no signal meters,
no suurrround upmixing, no nothing.
- There is no way to figure out if it is actually connected, so
exposing it would more often than not show something that doesn't
work at all.
- and the killer argument: we don't even ship a CD player app that
could make use of the analog CDDA playback path. To my konwledge
there is none in the default install, nor in the entire distro.
Doing digital grabbing of is very reliable these days. The analog path
is just completely obsolete.
Every time someone brings the analog cd playback path he's just making
a complete fool out of himself because it is so very obvious that the
issue is made up and even he himself hasn't used that feature for
years. Because otherwise he'd know how broken it is.
Lennart
--
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
6:28 p.m.
On Thu, 30.07.09 19:06, Jeff Garzik (jgarzik(a)pobox.com) wrote:
Lennart Poettering wrote:
> Doing digital grabbing of is very reliable these days. The analog path
> is just completely obsolete.
I guess it's an open question why HDA touts multi-analog and hw mixing
as modern features, then :)
Oh does it? How about adding some references to this claim? Might be
actually convincing then.
At least I couldn't find anything googling for 'HDA hardware-mixing'.
Nor could I find anything googling for 'HDA multi-analog'.
Please check your dictionary and look up "to tout". There you'll find
that it means "to solicit, peddle, or persuade importunately". It's
not particularly "importunate" if google can show no trace of it, is it?
And also, please paste a dump of "amixer -c0" for your HDA card so
that we can see that it includes a "CD" control. And the contents of
/proc/asound/pcm would be cool, too, so that we can see your HDA card
does hw mixing.
If you cannot produce anything of that I'd recommend a good ol' cup of
STFU.
Lennart
--
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
6:37 p.m.
Lennart Poettering wrote:
On Thu, 30.07.09 19:06, Jeff Garzik (jgarzik(a)pobox.com) wrote:
> Lennart Poettering wrote:
>> Doing digital grabbing of is very reliable these days. The analog path
>> is just completely obsolete.
> I guess it's an open question why HDA touts multi-analog and hw mixing
> as modern features, then :)
Oh does it? How about adding some references to this claim? Might be
actually convincing then.
http://www.intel.com/design/chipsets/hdaudio.htm
Jeff
6:45 p.m.
On Thu, 30.07.09 19:37, Jeff Garzik (jgarzik(a)pobox.com) wrote:
Lennart Poettering wrote:
> On Thu, 30.07.09 19:06, Jeff Garzik (jgarzik(a)pobox.com) wrote:
>
>> Lennart Poettering wrote:
>>> Doing digital grabbing of is very reliable these days. The analog path
>>> is just completely obsolete.
>> I guess it's an open question why HDA touts multi-analog and hw
>> mixing as modern features, then :)
>
> Oh does it? How about adding some references to this claim? Might be
> actually convincing then.
http://www.intel.com/design/chipsets/hdaudio.htm
Where do you see hardware mixing mentioned there? Or multi-analog?
I certainly cannot see that mentioned directly or indirectly in any
way on that page.
Lennart
--
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
7:07 p.m.
Lennart Poettering wrote:
On Thu, 30.07.09 19:37, Jeff Garzik (jgarzik(a)pobox.com) wrote:
> Lennart Poettering wrote:
>> On Thu, 30.07.09 19:06, Jeff Garzik (jgarzik(a)pobox.com) wrote:
>>
>>> Lennart Poettering wrote:
>>>> Doing digital grabbing of is very reliable these days. The analog path
>>>> is just completely obsolete.
>>> I guess it's an open question why HDA touts multi-analog and hw
>>> mixing as modern features, then :)
>> Oh does it? How about adding some references to this claim? Might be
>> actually convincing then.
> http://www.intel.com/design/chipsets/hdaudio.htm
Where do you see hardware mixing mentioned there? Or multi-analog?
I certainly cannot see that mentioned directly or indirectly in any
way on that page.
Try the programmer's guide, for one.
If you are going to whine about googling, don't expect to be spoonfed
knowledge you should already know.
Jeff
7:34 p.m.
On Thu, 30.07.09 20:07, Jeff Garzik (jgarzik(a)pobox.com) wrote:
Lennart Poettering wrote:
> On Thu, 30.07.09 19:37, Jeff Garzik (jgarzik(a)pobox.com) wrote:
>
>> Lennart Poettering wrote:
>>> On Thu, 30.07.09 19:06, Jeff Garzik (jgarzik(a)pobox.com) wrote:
>>>
>>>> Lennart Poettering wrote:
>>>>> Doing digital grabbing of is very reliable these days. The analog
path
>>>>> is just completely obsolete.
>>>> I guess it's an open question why HDA touts multi-analog and hw
>>>> mixing as modern features, then :)
>>> Oh does it? How about adding some references to this claim? Might be
>>> actually convincing then.
>> http://www.intel.com/design/chipsets/hdaudio.htm
>
> Where do you see hardware mixing mentioned there? Or multi-analog?
>
> I certainly cannot see that mentioned directly or indirectly in any
> way on that page.
Try the programmer's guide, for one.
If you are going to whine about googling, don't expect to be spoonfed
knowledge you should already know.
Sorry, still don't see anything regarding "touted" hw mixing. Page
number please!
Lennart
--
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
6:59 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Lennart Poettering wrote:
On Thu, 30.07.09 19:06, Jeff Garzik (jgarzik(a)pobox.com) wrote:
>
> Lennart Poettering wrote:
>> Doing digital grabbing of is very reliable these days. The
analog path
>> is just completely obsolete.
>
> I guess it's an open question why HDA touts multi-analog and
hw mixing
> as modern features, then :)
Oh does it? How about adding some references to this claim?
Might be
actually convincing then.
At least I couldn't find anything googling for 'HDA hardware-
mixing'.
Nor could I find anything googling for 'HDA multi-analog'.
Please check your dictionary and look up "to tout". There
you'll
find
that it means "to solicit, peddle, or persuade
importunately".
It's
not particularly "importunate" if google can show no trace
of
it, is it?
And also, please paste a dump of "amixer -c0" for your HDA
card so
that we can see that it includes a "CD" control. And the
contents of
/proc/asound/pcm would be cool, too, so that we can see your
HDA card
does hw mixing.
If you cannot produce anything of that I'd recommend a good
ol' cup of
STFU.
Lennart
I see a "CD" control here. Not sure if anything indicates hw-
mixing or multi-analog, but here's stuff from a recent (ASUS
P5Q-VM) motherboard release late 2008[1]:
% amixer -c0
Simple mixer control 'Master',0
Capabilities: pvolume pvolume-joined pswitch pswitch-joined
Playback channels: Mono
Limits: Playback 0 - 31
Mono: Playback 31 [100%] [0.00dB] [on]
Simple mixer control 'Headphone',0
Capabilities: pswitch
Playback channels: Front Left - Front Right
Mono:
Front Left: Playback [on]
Front Right: Playback [on]
Simple mixer control 'PCM',0
Capabilities: pvolume
Playback channels: Front Left - Front Right
Limits: Playback 0 - 255
Mono:
Front Left: Playback 255 [100%] [0.00dB]
Front Right: Playback 255 [100%] [0.00dB]
Simple mixer control 'Front',0
Capabilities: pvolume pswitch
Playback channels: Front Left - Front Right
Limits: Playback 0 - 31
Mono:
Front Left: Playback 17 [55%] [-21.00dB] [on]
Front Right: Playback 17 [55%] [-21.00dB] [on]
Simple mixer control 'Front Mic',0
Capabilities: pvolume pswitch
Playback channels: Front Left - Front Right
Limits: Playback 0 - 31
Mono:
Front Left: Playback 0 [0%] [-34.50dB] [off]
Front Right: Playback 0 [0%] [-34.50dB] [off]
Simple mixer control 'Front Mic Boost',0
Capabilities: volume
Playback channels: Front Left - Front Right
Capture channels: Front Left - Front Right
Limits: 0 - 3
Front Left: 0 [0%]
Front Right: 0 [0%]
Simple mixer control 'Surround',0
Capabilities: pvolume pswitch
Playback channels: Front Left - Front Right
Limits: Playback 0 - 31
Mono:
Front Left: Playback 0 [0%] [-46.50dB] [on]
Front Right: Playback 0 [0%] [-46.50dB] [on]
Simple mixer control 'Center',0
Capabilities: pvolume pvolume-joined pswitch pswitch-joined
Playback channels: Mono
Limits: Playback 0 - 31
Mono: Playback 0 [0%] [-46.50dB] [on]
Simple mixer control 'LFE',0
Capabilities: pvolume pvolume-joined pswitch pswitch-joined
Playback channels: Mono
Limits: Playback 0 - 31
Mono: Playback 0 [0%] [-46.50dB] [on]
Simple mixer control 'Side',0
Capabilities: pvolume pswitch
Playback channels: Front Left - Front Right
Limits: Playback 0 - 31
Mono:
Front Left: Playback 0 [0%] [-46.50dB] [on]
Front Right: Playback 0 [0%] [-46.50dB] [on]
Simple mixer control 'Line',0
Capabilities: pvolume pswitch
Playback channels: Front Left - Front Right
Limits: Playback 0 - 31
Mono:
Front Left: Playback 0 [0%] [-34.50dB] [off]
Front Right: Playback 0 [0%] [-34.50dB] [off]
Simple mixer control 'CD',0
Capabilities: pvolume pswitch
Playback channels: Front Left - Front Right
Limits: Playback 0 - 31
Mono:
Front Left: Playback 0 [0%] [-34.50dB] [on]
Front Right: Playback 0 [0%] [-34.50dB] [on]
Simple mixer control 'Mic',0
Capabilities: pvolume pswitch
Playback channels: Front Left - Front Right
Limits: Playback 0 - 31
Mono:
Front Left: Playback 0 [0%] [-34.50dB] [off]
Front Right: Playback 0 [0%] [-34.50dB] [off]
Simple mixer control 'Mic Boost',0
Capabilities: volume
Playback channels: Front Left - Front Right
Capture channels: Front Left - Front Right
Limits: 0 - 3
Front Left: 0 [0%]
Front Right: 0 [0%]
Simple mixer control 'IEC958',0
Capabilities: pswitch pswitch-joined cswitch cswitch-joined
Playback channels: Mono
Capture channels: Mono
Mono: Playback [on] Capture [off]
Simple mixer control 'IEC958 Default PCM',0
Capabilities: pswitch pswitch-joined
Playback channels: Mono
Mono: Playback [on]
Simple mixer control 'PC Speaker',0
Capabilities: pvolume pswitch
Playback channels: Front Left - Front Right
Limits: Playback 0 - 31
Mono:
Front Left: Playback 0 [0%] [-34.50dB] [on]
Front Right: Playback 0 [0%] [-34.50dB] [on]
Simple mixer control 'Capture',0
Capabilities: cvolume cswitch
Capture channels: Front Left - Front Right
Limits: Capture 0 - 31
Front Left: Capture 11 [35%] [0.00dB] [on]
Front Right: Capture 11 [35%] [0.00dB] [on]
Simple mixer control 'Capture',1
Capabilities: cvolume cswitch
Capture channels: Front Left - Front Right
Limits: Capture 0 - 31
Front Left: Capture 0 [0%] [-16.50dB] [off]
Front Right: Capture 0 [0%] [-16.50dB] [off]
Simple mixer control 'Channel Mode',0
Capabilities: enum
Items: '6ch' '8ch'
Item0: '6ch'
Simple mixer control 'Input Source',0
Capabilities: cenum
Items: 'Mic' 'Front Mic' 'Line' 'CD'
Item0: 'Mic'
Simple mixer control 'Input Source',1
Capabilities: cenum
Items: 'Mic' 'Front Mic' 'Line' 'CD'
Item0: 'Mic'
% cat /proc/asound/pcm
00-00: ALC1200 Analog : ALC1200 Analog : playback 1 : capture 1
00-01: ALC1200 Digital : ALC1200 Digital : playback 1 : capture
1
00-02: ALC1200 Analog : ALC1200 Analog : capture 1
[1]http://shopper.cnet.com/4366-3049_9-33343780.html (iG45)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAkpyM9UACgkQiPi+MRHG3qSptgCeML0C2wcJIY2+/wzS0/vAJxSx
h1wAnjqhRI4yjGS8bwyJo5SdKvd75fSP
=HXtt
-----END PGP SIGNATURE-----
8:37 p.m.
Lennart Poettering said the following on 07/30/2009 04:28 PM Pacific Time:
If you cannot produce anything of that I'd recommend a good ol' cup of
STFU.
Lennart
How much longer are we going to wait to implement
http://fedoraproject.org/wiki/Hall_Monitor_Policy ?
This is getting really childish and unprofessional.
John
9:28 p.m.
On Thu, Jul 30, 2009 at 06:37:24PM -0700, John Poelstra wrote:
Lennart Poettering said the following on 07/30/2009 04:28 PM Pacific
Time:
>
> If you cannot produce anything of that I'd recommend a good ol' cup of
> STFU.
>
> Lennart
>
How much longer are we going to wait to implement
http://fedoraproject.org/wiki/Hall_Monitor_Policy ?
You realize warnings are done in private, right? So you normally wouldn't
know if that was enacted anyway, unless the person being warned decided to be
vocal about it.
This is getting really childish and unprofessional.
I do certainly agree there.
josh
8:54 p.m.
Lennart Poettering (mzerqung(a)0pointer.de) said:
And also, please paste a dump of "amixer -c0" for your HDA
card so
that we can see that it includes a "CD" control.
Sorry, but...
$ cat /proc/asound/cards
0 [Intel ]: HDA-Intel - HDA Intel
HDA Intel at 0xee240000 irq 17
$ amixer -c 0
...
Simple mixer control 'CD',0
Capabilities: pvolume pswitch cswitch cswitch-joined cswitch-exclusive
Capture exclusive group: 0
Playback channels: Front Left - Front Right
Capture channels: Mono
Limits: Playback 0 - 31
Mono: Capture [off]
Front Left: Playback 23 [74%] [0.00dB] [on]
Front Right: Playback 23 [74%] [0.00dB] [on]
...
Of course, I've had the laptop two and a half years, and never needed
to touch it.
But seriously, guys... take it off-list, I doubt anyone is that interested
any more.
Bill
12:58 a.m.
On Thu, Jul 30, 2009 at 09:54:29PM -0400, Bill Nottingham wrote:
Lennart Poettering (mzerqung(a)0pointer.de) said:
> And also, please paste a dump of "amixer -c0" for your HDA card so
> that we can see that it includes a "CD" control.
Sorry, but...
$ cat /proc/asound/cards
0 [Intel ]: HDA-Intel - HDA Intel
HDA Intel at 0xee240000 irq 17
$ amixer -c 0
...
Simple mixer control 'CD',0
Capabilities: pvolume pswitch cswitch cswitch-joined cswitch-exclusive
Capture exclusive group: 0
Playback channels: Front Left - Front Right
Capture channels: Mono
Limits: Playback 0 - 31
Mono: Capture [off]
Front Left: Playback 23 [74%] [0.00dB] [on]
Front Right: Playback 23 [74%] [0.00dB] [on]
...
[dledford@zd7000 ~]$ cat /proc/asound/cards
0 [ICH5 ]: ICH4 - Intel ICH5
Intel ICH5 with unknown codec at irq 17
1 [Modem ]: ICH-MODEM - Intel ICH5 Modem
Intel ICH5 Modem at irq 17
[dledford@zd7000 ~]$ amixer -c0
...
Simple mixer control 'Line',0
Capabilities: pvolume pswitch pswitch-joined cswitch cswitch-exclusive
Capture exclusive group: 0
Playback channels: Front Left - Front Right
Capture channels: Front Left - Front Right
Limits: Playback 0 - 31
Front Left: Playback 0 [0%] [-34.50dB] [off] Capture [off]
Front Right: Playback 0 [0%] [-34.50dB] [off] Capture [off]
Simple mixer control 'CD',0
Capabilities: pvolume pswitch pswitch-joined cswitch cswitch-exclusive
Capture exclusive group: 0
Playback channels: Front Left - Front Right
Capture channels: Front Left - Front Right
Limits: Playback 0 - 31
Front Left: Playback 23 [74%] [0.00dB] [on] Capture [off]
Front Right: Playback 23 [74%] [0.00dB] [on] Capture [off]
Simple mixer control 'Mic',0
Capabilities: pvolume pvolume-joined pswitch pswitch-joined cswitch
cswitch-exclusive
Capture exclusive group: 0
Playback channels: Mono
Capture channels: Front Left - Front Right
Limits: Playback 0 - 31
Mono: Playback 0 [0%] [-34.50dB] [off]
Front Left: Capture [on]
Front Right: Capture [on]
Simple mixer control 'Mic Boost (+20dB)',0
Capabilities: pswitch pswitch-joined
Playback channels: Mono
Mono: Playback [off]
Simple mixer control 'Video',0
Capabilities: cswitch cswitch-exclusive
Capture exclusive group: 0
Capture channels: Front Left - Front Right
Front Left: Capture [off]
Front Right: Capture [off]
...
[dledford@zd7000 ~]$ cat /proc/asound/pcm
00-00: Intel ICH : Intel ICH5 : playback 1 : capture 1
00-01: Intel ICH - MIC ADC : Intel ICH5 - MIC ADC : capture 1
00-02: Intel ICH - MIC2 ADC : Intel ICH5 - MIC2 ADC : capture 1
00-03: Intel ICH - ADC2 : Intel ICH5 - ADC2 : capture 1
00-04: Intel ICH - IEC958 : Intel ICH5 - IEC958 : playback 1
01-00: Intel ICH - Modem : Intel ICH5 Modem - Modem : playback 1 :
capture 1
9:19 a.m.
On Sat, 01.08.09 00:58, Doug Ledford (dledford(a)redhat.com) wrote:
[dledford@zd7000 ~]$ cat /proc/asound/pcm
00-00: Intel ICH : Intel ICH5 : playback 1 : capture 1
00-01: Intel ICH - MIC ADC : Intel ICH5 - MIC ADC : capture 1
00-02: Intel ICH - MIC2 ADC : Intel ICH5 - MIC2 ADC : capture 1
00-03: Intel ICH - ADC2 : Intel ICH5 - ADC2 : capture 1
00-04: Intel ICH - IEC958 : Intel ICH5 - IEC958 : playback 1
01-00: Intel ICH - Modem : Intel ICH5 Modem - Modem : playback 1 : capture 1
See, no hw mixing anywhere in sight. All you can do is modem, spdif
and analog output at the same time. And only one stream.
Lennart
--
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
12:51 a.m.
On Fri, Jul 31, 2009 at 01:28:58AM +0200, Lennart Poettering wrote:
On Thu, 30.07.09 19:06, Jeff Garzik (jgarzik(a)pobox.com) wrote:
>
> Lennart Poettering wrote:
>> Doing digital grabbing of is very reliable these days. The analog path
>> is just completely obsolete.
>
> I guess it's an open question why HDA touts multi-analog and hw mixing
> as modern features, then :)
Oh does it? How about adding some references to this claim? Might be
actually convincing then.
At least I couldn't find anything googling for 'HDA hardware-mixing'.
Nor could I find anything googling for 'HDA multi-analog'.
When you buy an Intel CPU do you expect it to say "Supports x86
instruction set"? The ability for a soundcard to accept multiple analog
inputs and output them all simultaneously to a single sink has been
standard for so long that any card that *can't* do it (assuming it has
multiple analog inputs) would be considered total garbage. You don't
have to tout something that is a basic, standard capability.
6:59 p.m.
Lennart Poettering wrote:
On Thu, 30.07.09 16:53, Matthew Woehlke (elided) wrote:
Please do not quote my e-mail address unobfuscated in message bodies.
The "analog" path for CDDA is completely broken and
obsolete:
- It doesn't work if you have more than one cd drive
Sure it does (assuming you have something to plug the second drive
into). I've used two drives with one card; second drive was on AUX.
- It doesn't work if you have more than one audio device
Not really true, you just can only play via one device.
Of course, the other points are all valid. (Well, didn't know about not
working with SPDIF, I would have assumed there would be an ADC in that
case...)
--
Matthew
Disadvantage: Bad Puns [-5]
You constantly utter puns so egregious as to cause mental distress to
anyone hearing them. This can, however, be used to distract enemies.
12:41 a.m.
On Fri, Jul 31, 2009 at 12:36:38AM +0200, Lennart Poettering wrote:
On Thu, 30.07.09 16:53, Matthew Woehlke
(mw_triad(a)users.sourceforge.net) wrote:
>
> Doug Ledford wrote:
>> Every system I build still keeps the analog signal cable between the
>> CD/DVD and the soundcard. This doesn't help if I try to watch a movie
>> as that signal has to be decoded and then played, but for audio CDs
>> it is still a perfectly acceptable means of playing the music. So I'm
>> not sure where this "CD in is obsolete" comes from. Even the
>> motherboard I bought about 2 months ago still has a CD in port and
>> the CD/DVD in that machine still has an analog output.
>
> CD is digital and can be read in digital format by your CPU and sent in
> digital to the sound device. This is lossless.
Adding here:
The "analog" path for CDDA is completely broken and obsolete:
And adding here that CD in is just one of two analog in paths I use that
I don't want to do digital data transfer on. You didn't address the
other one.
- It doesn't work with USB cd drives
Depends on wether or not the drive has an analog out. Most don't, but
I've seen them in the past that do.
- Modern cards don't even have the connector anymore
As mentioned in my previous mail, my most recent motherboard purchase
does, and so did all my previous purchases.
- There is no way to get acces to the PCM data before playing it,
meaning no equalizers applied, no visualizations, no signal meters,
no suurrround upmixing, no nothing.
Well, duh. I don't *want* that junk. I want a zero intervention pass
through that leaves my system unoccupied by mundane, trivial crap. Oh,
and my sound card automatically plays 2 channel stereo line in as either
4.1 or 5.1 output, so I *really* don't want CPU based surround upmixing.
- There is no way to figure out if it is actually connected, so
exposing it would more often than not show something that doesn't
work at all.
I *know* it's connected, I connected it myself.
- and the killer argument: we don't even ship a CD player app
that
could make use of the analog CDDA playback path. To my konwledge
there is none in the default install, nor in the entire distro.
And this has nothing to do with whether or not the mixer should be able
to deal with analog in to analog out directly, which was my complaint.
The CD portion of it was just one instance, the other being my use of
line in for my iPhone. Assuming that because you don't have access to a
CD player that does CDDA based playing today means that it simply
doesn't work in the hardware is just silly. And assuming that because
your CD in path doesn't work that no analog input path should be
redirected in hardware to speakers is also just as silly.
9:43 a.m.
eOn Sat, 01.08.09 00:41, Doug Ledford (dledford(a)redhat.com) wrote:
> - and the killer argument: we don't even ship a CD player
app that
> could make use of the analog CDDA playback path. To my konwledge
> there is none in the default install, nor in the entire distro.
And this has nothing to do with whether or not the mixer should be able
to deal with analog in to analog out directly, which was my complaint.
The CD portion of it was just one instance, the other being my use of
line in for my iPhone. Assuming that because you don't have access to a
CD player that does CDDA based playing today means that it simply
doesn't work in the hardware is just silly. And assuming that because
your CD in path doesn't work that no analog input path should be
redirected in hardware to speakers is also just as silly.
In three ways you seem very confused.
Firstly, analog path CDDA playback is a feature that got removed from
Fedora long before PA/g-v-c decided to hide the CD volume
slider. There is no CD player supporting the analog path in
Fedora. So _I_am_not_the_one_you_should_be_complaining_to_.
Secondly, PA doesn't even take away the ability to control the CD
slider, at all. In contrast to analog path CDDA playback where we
don't ship any tool that supports this anymore, we do ship numerous
alternative ALSA mixers, for the UI and for the terminal which expose
the CD slider. So, PA does not take anything away from you. And so
again, _I_am_not_the_one_you_should_be_complaining_to_.
Thirdly, you are conflating CDDA playback with support analog
input/output in some way that makes no sense at all. Of course we
support analog input and output. After all this is software for sound
cards! Claiming we would be dropping support for analog audio
input/output is as stupid as claiming Obama wasn't born in the US. All
PA does here is hiding a few obsolete ports, such as CDDA, which as
mentioned above, isn't otherwise supported anymore anyway.
Lennart
--
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
12:29 a.m.
On Thu, Jul 30, 2009 at 04:53:25PM -0500, Matthew Woehlke wrote:
Doug Ledford wrote:
> Every system I build still keeps the analog signal cable between the
> CD/DVD and the soundcard. This doesn't help if I try to watch a movie
> as that signal has to be decoded and then played, but for audio CDs
> it is still a perfectly acceptable means of playing the music. So I'm
> not sure where this "CD in is obsolete" comes from. Even the
> motherboard I bought about 2 months ago still has a CD in port and
> the CD/DVD in that machine still has an analog output.
CD is digital and can be read in digital format by your CPU and sent in
digital to the sound device. This is lossless.
You want to:
(D->A) do the DAC in the CD drive
(A) toss that on an analog wire
(A/A->D->A) apply an analog volume adjustment (if you're lucky; you
might actually end up doing a ADC, digital volume adjustment, DAC)
(A/A->D) toss that on a different wire that might be digital
(A/D->A) hear it from your speakers
You could:
(D) read the CD digital data
(D) toss said data to the sound device (losslessly!)
(D/D->A) apply a digital volume adjustment (or maybe analog volume
adjustment after DAC)
(D/D->A) send that, maybe digitally, to your speakers
(A/D->A) hear it from your speakers
What exactly is better about the first scenario? At *best* you're moving
the analog signal across a longer run of wire (and one that is inside
your computer case with who-knows-what shielding picking up
who-knows-what interference). At worst you've tossed several analog
elements into a process that could have been digital from disc to
speaker cones.
Seriously... do I miss something?
That reading in the data digitally uses non trivial amounts of PCI and
CPU bandwidth. If I can't hear the difference between the two modes,
then that CPU usage is a total waste of resources. I have other things
I want my CPU to be doing.
12:40 a.m.
On Sat, Aug 01, 2009 at 12:29:36AM -0500, Doug Ledford wrote:
That reading in the data digitally uses non trivial amounts of PCI
and
CPU bandwidth. If I can't hear the difference between the two modes,
then that CPU usage is a total waste of resources. I have other things
I want my CPU to be doing.
If 150K/sec is non-trivial PCI bandwidth, I think you should probably
ask for a refund on your motherboard. From a power management point of
view I'd like to agree that offloading this from the CPU is a good
thing, but Lennart's right - most newly built machines don't hook these
up, and adding a control that influences CD volume on a small number of
machines and does nothing whatsoever on a larger number isn't a sensible
UI optimisation.
--
Matthew Garrett | mjg59(a)srcf.ucam.org
1:01 a.m.
On Sat, Aug 01, 2009 at 06:40:12AM +0100, Matthew Garrett wrote:
On Sat, Aug 01, 2009 at 12:29:36AM -0500, Doug Ledford wrote:
> That reading in the data digitally uses non trivial amounts of PCI and
> CPU bandwidth. If I can't hear the difference between the two modes,
> then that CPU usage is a total waste of resources. I have other things
> I want my CPU to be doing.
If 150K/sec is non-trivial PCI bandwidth, I think you should probably
ask for a refund on your motherboard. From a power management point of
view I'd like to agree that offloading this from the CPU is a good
thing, but Lennart's right - most newly built machines don't hook these
up, and adding a control that influences CD volume on a small number of
machines and does nothing whatsoever on a larger number isn't a sensible
UI optimisation.
It's also things like erratic output via PA versus smooth output via
analog input. This particular laptop pops and crackles every time the
PCM starts/stops, while analog signals are much cleaner. And it would
be pretty easy to have a warn once dialog that tells users that attempt
to adjust the CD in volume that it may not have any effect if the analog
input isn't connected to the sound card or if the cd playback software
skips the analog input in favor of digital data transfer. You could
even ask users after an adjustment if the adjustment made any
difference, and if it didn't, you could remove it from the UI.
4:32 a.m.
On Sat, 2009-08-01 at 01:01 -0500, Doug Ledford wrote:
On Sat, Aug 01, 2009 at 06:40:12AM +0100, Matthew Garrett wrote:
> On Sat, Aug 01, 2009 at 12:29:36AM -0500, Doug Ledford wrote:
>
> > That reading in the data digitally uses non trivial amounts of PCI and
> > CPU bandwidth. If I can't hear the difference between the two modes,
> > then that CPU usage is a total waste of resources. I have other things
> > I want my CPU to be doing.
>
> If 150K/sec is non-trivial PCI bandwidth, I think you should probably
> ask for a refund on your motherboard. From a power management point of
> view I'd like to agree that offloading this from the CPU is a good
> thing, but Lennart's right - most newly built machines don't hook these
> up, and adding a control that influences CD volume on a small number of
> machines and does nothing whatsoever on a larger number isn't a sensible
> UI optimisation.
It's also things like erratic output via PA versus smooth output via
analog input.
What the hell? How is 'PA versus analog input' a remotely sensible
opposition? How are those things even related?
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
8:16 a.m.
CD in is nothing more than an analog input. PA ignores all the analog
inputs other than as a digital PCM source. Treating all the analog
inputs as digital sources and not allowing the hardware to mix them to
output has various drawbacks. I've just been covering some of them.
I'm out and about and using my phone to send this, so no long drawn
out discussions are possible.
On Aug 1, 2009, at 4:32 AM, Adam Williamson <awilliam(a)redhat.com> wrote:
On Sat, 2009-08-01 at 01:01 -0500, Doug Ledford wrote:
> On Sat, Aug 01, 2009 at 06:40:12AM +0100, Matthew Garrett wrote:
>> On Sat, Aug 01, 2009 at 12:29:36AM -0500, Doug Ledford wrote:
>>
>>> That reading in the data digitally uses non trivial amounts of
>>> PCI and
>>> CPU bandwidth. If I can't hear the difference between the two
>>> modes,
>>> then that CPU usage is a total waste of resources. I have other
>>> things
>>> I want my CPU to be doing.
>>
>> If 150K/sec is non-trivial PCI bandwidth, I think you should
>> probably
>> ask for a refund on your motherboard. From a power management
>> point of
>> view I'd like to agree that offloading this from the CPU is a good
>> thing, but Lennart's right - most newly built machines don't hook
>> these
>> up, and adding a control that influences CD volume on a small
>> number of
>> machines and does nothing whatsoever on a larger number isn't a
>> sensible
>> UI optimisation.
>
> It's also things like erratic output via PA versus smooth output via
> analog input.
What the hell? How is 'PA versus analog input' a remotely sensible
opposition? How are those things even related?
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
--
fedora-devel-list mailing list
fedora-devel-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
12:44 p.m.
On Sat, Aug 01, 2009 at 08:16:50AM -0500, Doug Ledford wrote:
CD in is nothing more than an analog input. PA ignores all the analog
inputs other than as a digital PCM source. Treating all the analog
inputs as digital sources and not allowing the hardware to mix them to
output has various drawbacks. I've just been covering some of them.
You're continuing to conflate two issues - hardware mixing of multiple
PCM streams (which some hardware supports but PA doesn't make use of)
and having control over the levels of analog inputs that are mixed
straight into the analog output stream. PA exposes some of these, but
not all of them - however, you can still use an alternative mixer app if
you want to configure this for your specific niche use case. When
Lennart says "PulseAudio does not support hardware mixing" he is *not*
talking about the case you're describing.
--
Matthew Garrett | mjg59(a)srcf.ucam.org
7:50 p.m.
Apologies for my late reply, I was gone for a week.
On Aug 1, 2009, at 1:44 PM, Matthew Garrett wrote:
On Sat, Aug 01, 2009 at 08:16:50AM -0500, Doug Ledford wrote:
> CD in is nothing more than an analog input. PA ignores all the analog
> inputs other than as a digital PCM source. Treating all the analog
> inputs as digital sources and not allowing the hardware to mix them
> to
> output has various drawbacks. I've just been covering some of them.
You're continuing to conflate two issues - hardware mixing of multiple
PCM streams (which some hardware supports but PA doesn't make use of)
Actually, I never referred to multiple PCM streams, just PCM +
multiple analog mixing.
and having control over the levels of analog inputs that are mixed
straight into the analog output stream. PA exposes some of these, but
not all of them -
I must have missed it. Where is it possible in PA to send *any*
analog input directly to analog output?
however, you can still use an alternative mixer app if
you want to configure this for your specific niche use case.
Which is what I currently do. However, my entry into this foray was
caused by the current maintainer of gst-mixer stating that he would
support it being removed from the default install image and comps.
From there it's a short step to it never getting compiled against
current libs and eventually falling away entirely. For PA to suit my
needs, and for this not to be a problem for me, I simply need support
for sending analog inputs to analog outputs. Nothing more.
The CD-In case is simply one instance of that capability and one I
don't really care about. However, from a coding perspective, once you
support CD-In or Aux or Line-In being sent directly to analog output,
all of the others are done too, you just change the input channel and
everything else is the same. So, from my perspective, saying that you
don't need to support CD-In because it's a dead and deprecated usage
of the hardware, and therefore you don't need to support *any* analog
input to analog output control is a logically fallacious argument
(specifically, generalization from one to the whole). Whether CD-In
usage is dead or not, the other uses aren't. So, for all I care, we
can skip CD-In support entirely, but Line-In and Aux should work.
And, of course, going back to what I just said, once either of those
two works, you already have the back end necessary to support CD-In
for free. So he's worried about unconnected CD drives causing bug
reports. Fine, don't enable CD-In, but that's not a valid excuse to
leave the other ports dysfunctional.
When
Lennart says "PulseAudio does not support hardware mixing" he is *not*
talking about the case you're describing.
Well, it *doesn't* support the case I'm describing, whether that's
what he means when he says so or not.
--
Doug Ledford <dledford(a)redhat.com>
GPG KeyID: CFBFF194
http://people.redhat.com/dledford
InfiniBand Specific RPMS
http://people.redhat.com/dledford/Infiniband
10:07 p.m.
On Tue, 2009-08-11 at 20:50 -0400, Doug Ledford wrote:
Which is what I currently do. However, my entry into this foray was
caused by the current maintainer of gst-mixer stating that he would
support it being removed from the default install image and comps.
From there it's a short step to it never getting compiled against
current libs and eventually falling away entirely. For PA to suit my
needs, and for this not to be a problem for me, I simply need support
for sending analog inputs to analog outputs. Nothing more.
I don't intend to maintain gst-mixer at all any more, and I intend to
drop it entirely from the distribution.
There are several other ALSA mixers you can use, like alsamixer ,
alsamixergui, xfce's mixer or kmix. I'd recommend alsamixer.
gst-mixer was only ever a stopgap for F11.
(specifically, generalization from one to the whole). Whether CD-In
usage is dead or not, the other uses aren't. So, for all I care, we
can skip CD-In support entirely, but Line-In and Aux should work.
And, of course, going back to what I just said, once either of those
two works, you already have the back end necessary to support CD-In
for free.
So he's worried about unconnected CD drives causing bug
reports. Fine, don't enable CD-In, but that's not a valid excuse to
leave the other ports dysfunctional.
You mean non-functional. The current Rawhide supports input selection in
gnome-volume-control and pavucontrol, anyway, so your concern is now
unneeded.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
8:03 a.m.
On Sat, Aug 01, 2009 at 01:01:44AM -0500, Doug Ledford wrote:
It's also things like erratic output via PA versus smooth output
via
analog input. This particular laptop pops and crackles every time the
PCM starts/stops, while analog signals are much cleaner.
There's a patch in the rawhide kernel that may improve this, depending
on your codec. You can also disable HDA power saving.
And it would be pretty easy to have a warn once dialog that tells
users that attempt to adjust the CD in volume that it may not have any
effect if the analog input isn't connected to the sound card or if the
cd playback software skips the analog input in favor of digital data
transfer. You could even ask users after an adjustment if the
adjustment made any difference, and if it didn't, you could remove it
from the UI.
We have a solution that we know always works, and it has negligable
cost. That's a much more straightforward design than one that has to
attempt to explain to the user that depending on whether or not there's
a specific piece of wire in their computer they may or may not hear
something in the CD player.
--
Matthew Garrett | mjg59(a)srcf.ucam.org
2:48 p.m.
Lennart Poettering (mzerqung(a)0pointer.de) said:
Please note that it is our intention not to wrap obsolete mixer
controls such as "CD", "PC Speaker", "MIDI" and so on. If
you file a
bug asking for those to be wrapped we will disappoint you and
close the bug WONTFIX.
When you mean 'not wrap them', do you mean they're no longer
selectable as a record source, if the hardware exports them?
Bill
3:07 p.m.
On Tue, 28.07.09 15:48, Bill Nottingham (notting(a)redhat.com) wrote:
Lennart Poettering (mzerqung(a)0pointer.de) said:
> Please note that it is our intention not to wrap obsolete mixer
> controls such as "CD", "PC Speaker", "MIDI" and so on.
If you file a
> bug asking for those to be wrapped we will disappoint you and
> close the bug WONTFIX.
When you mean 'not wrap them', do you mean they're no longer
selectable as a record source, if the hardware exports them?
Yes. You cannot select them as record source, you cannot mute or
unmute them, you cannot change their volume. "CD", "PC Speaker",
"MIDI" and so on are just obsolete.
If you want to control them you can always install alsamixer or
gst-mixer or whatever. But really, this controls are obsolete.
Lennart
--
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
1:55 a.m.
On Tue, 2009-07-28 at 22:07 +0200, Lennart Poettering wrote:
On Tue, 28.07.09 15:48, Bill Nottingham (notting(a)redhat.com) wrote:
>
> Lennart Poettering (mzerqung(a)0pointer.de) said:
> > Please note that it is our intention not to wrap obsolete mixer
> > controls such as "CD", "PC Speaker", "MIDI" and
so on. If you file a
> > bug asking for those to be wrapped we will disappoint you and
> > close the bug WONTFIX.
>
> When you mean 'not wrap them', do you mean they're no longer
> selectable as a record source, if the hardware exports them?
Yes. You cannot select them as record source, you cannot mute or
unmute them, you cannot change their volume. "CD", "PC Speaker",
"MIDI" and so on are just obsolete.
If you want to control them you can always install alsamixer or
gst-mixer or whatever. But really, this controls are obsolete.
so really lennart means 'no' :) they're not selectable via PA's mixer
interface. they will still be selectable via ALSA's mixer interface, and
hence via any alsamixer (alsamixer, kmix, xfce's mixer, gst-mixer as
long as it's around, etc).
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
2:02 a.m.
On Tue, 2009-07-28 at 23:55 -0700, Adam Williamson wrote:
> > When you mean 'not wrap them', do you mean
they're no longer
> > selectable as a record source, if the hardware exports them?
>
> Yes. You cannot select them as record source, you cannot mute or
> unmute them, you cannot change their volume. "CD", "PC
Speaker",
> "MIDI" and so on are just obsolete.
>
> If you want to control them you can always install alsamixer or
> gst-mixer or whatever. But really, this controls are obsolete.
so really lennart means 'no' :) they're not selectable via PA's mixer
interface. they will still be selectable via ALSA's mixer interface, and
hence via any alsamixer (alsamixer, kmix, xfce's mixer, gst-mixer as
long as it's around, etc).
(sorry for the self-reply) - and of course, this isn't a regression in
PA, as PA's mixer interface has never exposed these choices. so
nothing's got more restricted than it was before.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
2:46 a.m.
On Tue, Jul 28, 2009 at 10:07:32PM +0200, Lennart Poettering wrote:
On Tue, 28.07.09 15:48, Bill Nottingham (notting(a)redhat.com) wrote:
>
> Lennart Poettering (mzerqung(a)0pointer.de) said:
> > Please note that it is our intention not to wrap obsolete mixer
> > controls such as "CD", "PC Speaker", "MIDI" and
so on. If you file a
> > bug asking for those to be wrapped we will disappoint you and
> > close the bug WONTFIX.
>
> When you mean 'not wrap them', do you mean they're no longer
> selectable as a record source, if the hardware exports them?
Yes. You cannot select them as record source, you cannot mute or
unmute them, you cannot change their volume. "CD", "PC Speaker",
"MIDI" and so on are just obsolete.
This reminds me your note:
https://tango.0pointer.de/pipermail/pulseaudio-discuss/2009-July/004519.html
PA does not make use of hardware mixing. And I don't plan to change
that. It's obsolete technology. CPUs these days come with extensions
such as MMX or SSE precisely for speeding up DSP tasks such as PCM
mixing. This is way more flexible that hw mixing, and definitely the
way to the future, both on the desktop and on embedded envs as well.
The "obsolete technology" -- who made this decision? Is it your private
opinion or any suggestion from sound card manufacturers?
It seems that HW companies still produce the "obsolete technology".
Karel
--
Karel Zak <kzak(a)redhat.com>
5:33 a.m.
This reminds me your note:
https://tango.0pointer.de/pipermail/pulseaudio-discuss/2009-July/004519.htm
l
PA does not make use of hardware mixing. And I don't plan to change
that. It's obsolete technology. CPUs these days come with extensions
such as MMX or SSE precisely for speeding up DSP tasks such as PCM
mixing. This is way more flexible that hw mixing, and definitely the
way to the future, both on the desktop and on embedded envs as well.
The "obsolete technology" -- who made this decision? Is it your private
opinion or any suggestion from sound card manufacturers?
It seems that HW companies still produce the "obsolete technology".
First, I like pulseaudio, especially the ability of moving streams from one
sink to another is awesome for laptops with external sound card :o)
But imo hw mixer (or other hw parts) are not that bad... we still have hw
accelerated graphic, math,... why not sound? Also this remains me that
pulseaudio eats 24 % of my (1.6GHz) cpu when mapping stereo stream to 5.1
which (I suppose) some hw mixer could do while letting cpu free for other
tasks.
6:08 a.m.
On Wed, Jul 29, 2009 at 5:33 AM, Michal Hlavinka <mhlavink(a)redhat.com>wrote:
> This reminds me your note:
>
>
>
https://tango.0pointer.de/pipermail/pulseaudio-discuss/2009-July/004519.htm
>l
>
> PA does not make use of hardware mixing. And I don't plan to change
> that. It's obsolete technology. CPUs these days come with extensions
> such as MMX or SSE precisely for speeding up DSP tasks such as PCM
> mixing. This is way more flexible that hw mixing, and definitely the
> way to the future, both on the desktop and on embedded envs as well.
>
>
> The "obsolete technology" -- who made this decision? Is it your private
> opinion or any suggestion from sound card manufacturers?
>
> It seems that HW companies still produce the "obsolete technology".
First, I like pulseaudio, especially the ability of moving streams from one
sink to another is awesome for laptops with external sound card :o)
But imo hw mixer (or other hw parts) are not that bad... we still have hw
accelerated graphic, math,... why not sound? Also this remains me that
pulseaudio eats 24 % of my (1.6GHz) cpu when mapping stereo stream to 5.1
which (I suppose) some hw mixer could do while letting cpu free for other
tasks.
Absolutely... IMO Pulseaudio needs some serious justification for its
direction.
--
projecthuh.com
All of my bits are free, are yours? Fedoraproject.org
8:16 a.m.
On Wed, 29.07.09 12:33, Michal Hlavinka (mhlavink(a)redhat.com) wrote:
> This reminds me your note:
>
>
> https://tango.0pointer.de/pipermail/pulseaudio-discuss/2009-July/004519.htm
>l
>
> PA does not make use of hardware mixing. And I don't plan to change
> that. It's obsolete technology. CPUs these days come with extensions
> such as MMX or SSE precisely for speeding up DSP tasks such as PCM
> mixing. This is way more flexible that hw mixing, and definitely the
> way to the future, both on the desktop and on embedded envs as well.
>
>
> The "obsolete technology" -- who made this decision? Is it your private
> opinion or any suggestion from sound card manufacturers?
>
> It seems that HW companies still produce the "obsolete technology".
First, I like pulseaudio, especially the ability of moving streams from one
sink to another is awesome for laptops with external sound card :o)
But imo hw mixer (or other hw parts) are not that bad... we still have hw
accelerated graphic, math,... why not sound? Also this remains me that
pulseaudio eats 24 % of my (1.6GHz) cpu when mapping stereo stream to 5.1
which (I suppose) some hw mixer could do while letting cpu free for other
tasks.
If PA eats a lot of CPU this can have many reasons, most of them have
to do with the latency settings requested by the applications or that
have been configured due to frequent underruns. However the actual
mixing is certainly the smallest part of it. Plese don't forget that
mixing is not exactly the most complex operation on earth.
But then again, I am happy to take patches.
Lennart
--
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
8:26 a.m.
On Wednesday 29 July 2009 15:16:20 Lennart Poettering wrote:
On Wed, 29.07.09 12:33, Michal Hlavinka (mhlavink(a)redhat.com) wrote:
> > This reminds me your note:
> >
> >
> > https://tango.0pointer.de/pipermail/pulseaudio-discuss/2009-July/004519
> >.htm l
> >
> > PA does not make use of hardware mixing. And I don't plan to change
> > that. It's obsolete technology. CPUs these days come with
> > extensions such as MMX or SSE precisely for speeding up DSP tasks such
> > as PCM mixing. This is way more flexible that hw mixing, and definitely
> > the way to the future, both on the desktop and on embedded envs as
> > well.
> >
> >
> > The "obsolete technology" -- who made this decision? Is it your
private
> > opinion or any suggestion from sound card manufacturers?
> >
> > It seems that HW companies still produce the "obsolete technology".
>
> First, I like pulseaudio, especially the ability of moving streams from
> one sink to another is awesome for laptops with external sound card :o)
>
> But imo hw mixer (or other hw parts) are not that bad... we still have hw
> accelerated graphic, math,... why not sound? Also this remains me that
> pulseaudio eats 24 % of my (1.6GHz) cpu when mapping stereo stream to 5.1
> which (I suppose) some hw mixer could do while letting cpu free for other
> tasks.
If PA eats a lot of CPU this can have many reasons, most of them have
to do with the latency settings requested by the applications or that
have been configured due to frequent underruns. However the actual
mixing is certainly the smallest part of it. Plese don't forget that
mixing is not exactly the most complex operation on earth.
Well... I'm pretty sure I have no idea how it works :D I've just noticed that
when playing stereo and sound card (Aureon MK II) is configured for stereo, it
eats about 4 % and (when speakers are set as 5.1) only front speakers work (as
expected), when I configure that card for 5.1 output and play stereo stream it
goes to all 5.1 speakers and eats about 24 % of cpu
10:23 a.m.
On Wed, 2009-07-29 at 15:26 +0200, Michal Hlavinka wrote:
> If PA eats a lot of CPU this can have many reasons, most of them
have
> to do with the latency settings requested by the applications or that
> have been configured due to frequent underruns. However the actual
> mixing is certainly the smallest part of it. Plese don't forget that
> mixing is not exactly the most complex operation on earth.
Well... I'm pretty sure I have no idea how it works :D I've just noticed that
when playing stereo and sound card (Aureon MK II) is configured for stereo, it
eats about 4 % and (when speakers are set as 5.1) only front speakers work (as
expected), when I configure that card for 5.1 output and play stereo stream it
goes to all 5.1 speakers and eats about 24 % of cpu
That's not mixing, it's multiplexing. I don't think any card has ever
had hardware acceleration for that operation (though hey, I'm probably
wrong ;>).
Mixing is what happens when you play sound from two or more applications
at once.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
8:47 a.m.
Lennart Poettering wrote:
If PA eats a lot of CPU this can have many reasons, most of them
have
to do with the latency settings requested by the applications or that
have been configured due to frequent underruns. However the actual
/me notes the blame-shifting...
mixing is certainly the smallest part of it. Plese don't forget
that
mixing is not exactly the most complex operation on earth.
Please don't forget that hardware mixing... is more than just mixing.
Modern audio hardware can offload sample rate conversion, attenuation,
3D processing, and other goodies.
Jeff
8:56 a.m.
On Wed, 29.07.09 09:47, Jeff Garzik (jgarzik(a)pobox.com) wrote:
> mixing is certainly the smallest part of it. Plese don't
forget that
> mixing is not exactly the most complex operation on earth.
Please don't forget that hardware mixing... is more than just mixing.
Modern audio hardware can offload sample rate conversion, attenuation,
3D processing, and other goodies.
Interesting in which parallel universe you must be living.
Modern audio hardware is usually locked to a specific sample rate, got
rid of all mixer controls by going to 24bit and letting the CPU
attenuate using the 8bit extra headroom. And 3d processing, and other
"goodies" aren't avilable in newer hw designs anymore either. In fact
haven't been available since quite some time in any design
anymore. (With the excption of those creative cards)
Just get over it, the new designs are really dumbed down but
high-quality 24bit dacs. That's all.
And now please sombody tell me what on earth this has to do with
the new volume control UI in Fedora?
It's amazing how Karel went through the archives to find something he
is annoyed of and brought it up on this thread here, apparently just
to start yet another pointless flamewar, taking over a completely
unrelated thread. Is this an exercise to make LWN again?
Lennart
--
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
9:53 a.m.
Lennart Poettering wrote:
On Wed, 29.07.09 09:47, Jeff Garzik (jgarzik(a)pobox.com) wrote:
>> mixing is certainly the smallest part of it. Plese don't forget that
>> mixing is not exactly the most complex operation on earth.
> Please don't forget that hardware mixing... is more than just mixing.
> Modern audio hardware can offload sample rate conversion, attenuation,
> 3D processing, and other goodies.
Interesting in which parallel universe you must be living.
Modern audio hardware is usually locked to a specific sample rate, got
rid of all mixer controls by going to 24bit and letting the CPU
attenuate using the 8bit extra headroom. And 3d processing, and other
"goodies" aren't avilable in newer hw designs anymore either. In fact
haven't been available since quite some time in any design
anymore. (With the excption of those creative cards)
bzzt, sorry, thanks for playing.
The world has more to offer than 2005-era motherboard audio locked at 48K.
If you keeping bringing up Microsoft as a shining example, it might
behoove you examine how DirectSound has evolved for modern audio.
Jeff
10:50 a.m.
On Wed, 2009-07-29 at 15:56 +0200, Lennart Poettering wrote:
On Wed, 29.07.09 09:47, Jeff Garzik (jgarzik(a)pobox.com) wrote:
>> mixing is certainly the smallest part of it. Plese don't forget that
>> mixing is not exactly the most complex operation on earth.
>
> Please don't forget that hardware mixing... is more than just mixing.
> Modern audio hardware can offload sample rate conversion, attenuation,
> 3D processing, and other goodies.
Interesting in which parallel universe you must be living.
Modern audio hardware is usually locked to a specific sample rate, got
rid of all mixer controls by going to 24bit and letting the CPU
attenuate using the 8bit extra headroom. And 3d processing, and other
"goodies" aren't avilable in newer hw designs anymore either. In fact
haven't been available since quite some time in any design
anymore. (With the excption of those creative cards)
Just get over it, the new designs are really dumbed down but
high-quality 24bit dacs. That's all.
It may be easier to resolve this if both of you would say exactly what
hardware you're talking about...
for the sake of argument, my local PC store sells a range of cheap cards
that are just what Lennart says. For expensive consumer cards it has
several Asus cards (appear to be based on CMI chips), some AuzenTechs
(also CMI), and some HT Omegas (CMI again, I think I'm seeing a pattern
here :>). The Asus cards claim specifically that they support
DirectSound in hardware. Aside from that, all the expensive cards make
loud claims about Dolby and/or DTS systems for multiplexing and
headphone processing, but don't make clear whether they're done in
hardware or software. I didn't see anything about hardware SRC, though
they probably wouldn't advertise that, it's hard to tell until you own
one. My card, a Chaintech AV-710, does do SRC in hardware (you can set
it to any output sampling rate you like, via the mixer), but you can't
buy it any more, it was discontinued.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
11:10 a.m.
On Wed, Jul 29, 2009 at 10:50 AM, Adam Williamson <awilliam(a)redhat.com>wrote:
On Wed, 2009-07-29 at 15:56 +0200, Lennart Poettering wrote:
> On Wed, 29.07.09 09:47, Jeff Garzik (jgarzik(a)pobox.com) wrote:
>
> >> mixing is certainly the smallest part of it. Plese don't forget that
> >> mixing is not exactly the most complex operation on earth.
> >
> > Please don't forget that hardware mixing... is more than just mixing.
> > Modern audio hardware can offload sample rate conversion, attenuation,
> > 3D processing, and other goodies.
>
> Interesting in which parallel universe you must be living.
>
> Modern audio hardware is usually locked to a specific sample rate, got
> rid of all mixer controls by going to 24bit and letting the CPU
> attenuate using the 8bit extra headroom. And 3d processing, and other
> "goodies" aren't avilable in newer hw designs anymore either. In fact
> haven't been available since quite some time in any design
> anymore. (With the excption of those creative cards)
>
> Just get over it, the new designs are really dumbed down but
> high-quality 24bit dacs. That's all.
It may be easier to resolve this if both of you would say exactly what
hardware you're talking about...
for the sake of argument, my local PC store sells a range of cheap cards
that are just what Lennart says. For expensive consumer cards it has
several Asus cards (appear to be based on CMI chips), some AuzenTechs
(also CMI), and some HT Omegas (CMI again, I think I'm seeing a pattern
here :>). The Asus cards claim specifically that they support
DirectSound in hardware. Aside from that, all the expensive cards make
loud claims about Dolby and/or DTS systems for multiplexing and
headphone processing, but don't make clear whether they're done in
hardware or software. I didn't see anything about hardware SRC, though
they probably wouldn't advertise that, it's hard to tell until you own
one. My card, a Chaintech AV-710, does do SRC in hardware (you can set
it to any output sampling rate you like, via the mixer), but you can't
buy it any more, it was discontinued.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
--
fedora-devel-list mailing list
fedora-devel-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
If these controls and hardware accelerated audio isn't going to work
anymore, then why does Fedora still include the older OpenAL sample
implementation instead of the new OpenAL Soft implementation that comes with
a PulseAudio backend?
5:48 a.m.
Karel Zak wrote:
On Tue, Jul 28, 2009 at 10:07:32PM +0200, Lennart Poettering wrote:
> On Tue, 28.07.09 15:48, Bill Nottingham (notting(a)redhat.com) wrote:
> Yes. You cannot select them as record source, you cannot mute or
> unmute them, you cannot change their volume. "CD", "PC Speaker",
> "MIDI" and so on are just obsolete.
This reminds me your note:
https://tango.0pointer.de/pipermail/pulseaudio-discuss/2009-July/004519.html
PA does not make use of hardware mixing. And I don't plan to change
that. It's obsolete technology. CPUs these days come with extensions
such as MMX or SSE precisely for speeding up DSP tasks such as PCM
mixing. This is way more flexible that hw mixing, and definitely the
way to the future, both on the desktop and on embedded envs as well.
The "obsolete technology" -- who made this decision? Is it your private
opinion or any suggestion from sound card manufacturers?
It seems that HW companies still produce the "obsolete technology".
Quite agreed [says a former kernel audio driver maintainer], and I will
go even farther:
It is completely stupid to waste host CPU on a task that can be
offloaded in parallel to dedicated audio hardware.
If the user intentionally purchased expensive audio hardware with nice
hardware mixing, do not subvert the user's intentions by ignoring such
nice hardware.
Any developer who claims "always use software mixing" or "always use
hardware mixing" is a young, inexperienced fool. There are valid
situations for both choices.
Jeff
8:24 a.m.
On Wed, 29.07.09 06:48, Jeff Garzik (jgarzik(a)pobox.com) wrote:
Karel Zak wrote:
> On Tue, Jul 28, 2009 at 10:07:32PM +0200, Lennart Poettering wrote:
>> On Tue, 28.07.09 15:48, Bill Nottingham (notting(a)redhat.com) wrote:
>> Yes. You cannot select them as record source, you cannot mute or
>> unmute them, you cannot change their volume. "CD", "PC
Speaker",
>> "MIDI" and so on are just obsolete.
>
> This reminds me your note:
>
> https://tango.0pointer.de/pipermail/pulseaudio-discuss/2009-July/004519.html
>
> PA does not make use of hardware mixing. And I don't plan to change
> that. It's obsolete technology. CPUs these days come with extensions
> such as MMX or SSE precisely for speeding up DSP tasks such as PCM
> mixing. This is way more flexible that hw mixing, and definitely the
> way to the future, both on the desktop and on embedded envs as well.
>
>
> The "obsolete technology" -- who made this decision? Is it your private
> opinion or any suggestion from sound card manufacturers?
>
> It seems that HW companies still produce the "obsolete technology".
Quite agreed [says a former kernel audio driver maintainer], and I will
go even farther:
Maybe since the times you worked on audio drivers the design of the
sound cards changed a little and stuff like SSE became largely available?
It is completely stupid to waste host CPU on a task that can be
offloaded in parallel to dedicated audio hardware.
If the user intentionally purchased expensive audio hardware with nice
hardware mixing, do not subvert the user's intentions by ignoring such
nice hardware.
Any developer who claims "always use software mixing" or "always use
hardware mixing" is a young, inexperienced fool. There are valid
situations for both choices.
Hear hear, Mr. Garzik is the the old experienced wise man of audio,
who knows so much more about audio than any of the audio guys at
Microsoft or Apple.
Happy to take patches.
Lennart
--
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
8:35 a.m.
Lennart Poettering wrote:
On Wed, 29.07.09 06:48, Jeff Garzik (jgarzik(a)pobox.com) wrote:
> Karel Zak wrote:
>> On Tue, Jul 28, 2009 at 10:07:32PM +0200, Lennart Poettering wrote:
>>> On Tue, 28.07.09 15:48, Bill Nottingham (notting(a)redhat.com) wrote:
>>> Yes. You cannot select them as record source, you cannot mute or
>>> unmute them, you cannot change their volume. "CD", "PC
Speaker",
>>> "MIDI" and so on are just obsolete.
>> This reminds me your note:
>>
>> https://tango.0pointer.de/pipermail/pulseaudio-discuss/2009-July/004519.html
>>
>> PA does not make use of hardware mixing. And I don't plan to change
>> that. It's obsolete technology. CPUs these days come with extensions
>> such as MMX or SSE precisely for speeding up DSP tasks such as PCM
>> mixing. This is way more flexible that hw mixing, and definitely the
>> way to the future, both on the desktop and on embedded envs as well.
>>
>>
>> The "obsolete technology" -- who made this decision? Is it your
private
>> opinion or any suggestion from sound card manufacturers?
>>
>> It seems that HW companies still produce the "obsolete technology".
> Quite agreed [says a former kernel audio driver maintainer], and I will
> go even farther:
Maybe since the times you worked on audio drivers the design of the
sound cards changed a little and stuff like SSE became largely available?
I am well-versed in modern audio hardware -- moreso than you, apparently.
Jeff
8:39 a.m.
On Wednesday, 29 July 2009 at 15:24, Lennart Poettering wrote:
On Wed, 29.07.09 06:48, Jeff Garzik (jgarzik(a)pobox.com) wrote:
>
> Karel Zak wrote:
>> On Tue, Jul 28, 2009 at 10:07:32PM +0200, Lennart Poettering wrote:
>>> On Tue, 28.07.09 15:48, Bill Nottingham (notting(a)redhat.com) wrote:
>>> Yes. You cannot select them as record source, you cannot mute or
>>> unmute them, you cannot change their volume. "CD", "PC
Speaker",
>>> "MIDI" and so on are just obsolete.
>>
>> This reminds me your note:
>>
>>
https://tango.0pointer.de/pipermail/pulseaudio-discuss/2009-July/004519.html
>>
>> PA does not make use of hardware mixing. And I don't plan to change
>> that. It's obsolete technology. CPUs these days come with extensions
>> such as MMX or SSE precisely for speeding up DSP tasks such as PCM
>> mixing. This is way more flexible that hw mixing, and definitely the
>> way to the future, both on the desktop and on embedded envs as well.
>>
>>
>> The "obsolete technology" -- who made this decision? Is it your
private
>> opinion or any suggestion from sound card manufacturers?
>>
>> It seems that HW companies still produce the "obsolete technology".
>
> Quite agreed [says a former kernel audio driver maintainer], and I will
> go even farther:
Maybe since the times you worked on audio drivers the design of the
sound cards changed a little and stuff like SSE became largely available?
> It is completely stupid to waste host CPU on a task that can be
> offloaded in parallel to dedicated audio hardware.
>
> If the user intentionally purchased expensive audio hardware with nice
> hardware mixing, do not subvert the user's intentions by ignoring such
> nice hardware.
>
> Any developer who claims "always use software mixing" or "always use
> hardware mixing" is a young, inexperienced fool. There are valid
> situations for both choices.
Hear hear, Mr. Garzik is the the old experienced wise man of audio,
who knows so much more about audio than any of the audio guys at
Microsoft or Apple.
It's quite hypocritical of you to use an "anti-open-source" company
(Creative) as an argument for not supporting hw mixing on one side
and then touting other "anti-open-source" companies as examples to
follow on the other.
But whatever. Just please stop imposing pulseaudio on those who don't
want to use it. For the record, I'm still considering leaving Fedora
because - as a GNOME desktop - it's becoming unusable without pulseaudio.
Making it a hard dependency for GNOME bluetooth stack in F11 went a bit
too far in my opinion.
Regards,
R.
--
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu
"Faith manages."
-- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"
8:47 a.m.
On Wed, 2009-07-29 at 15:39 +0200, Dominik 'Rathann' Mierzejewski wrote:
<snip>
It's quite hypocritical of you to use an
"anti-open-source" company
(Creative) as an argument for not supporting hw mixing on one side
and then touting other "anti-open-source" companies as examples to
follow on the other.
Since when does using technology as an example mean that you condone the
way companies do business? Maybe we should start removing other parts of
Fedora because they were inspired by, or share similar technical
features to things Microsoft or Apple did before us.
I hope you see how flawed your argument is.
But whatever. Just please stop imposing pulseaudio on those who
don't
want to use it. For the record, I'm still considering leaving Fedora
because - as a GNOME desktop - it's becoming unusable without pulseaudio.
Making it a hard dependency for GNOME bluetooth stack in F11 went a bit
too far in my opinion.
I did that, and the reasons for it were discussed on this list. Nobody
has made any headway into explaining how to fix the problem[1] without
the hard dependency.
[1]: That'd be out-of-the-box Bluetooth headset and speakers support
9:21 a.m.
On Wednesday, 29 July 2009 at 15:47, Bastien Nocera wrote:
On Wed, 2009-07-29 at 15:39 +0200, Dominik 'Rathann'
Mierzejewski wrote:
<snip>
> It's quite hypocritical of you to use an "anti-open-source" company
> (Creative) as an argument for not supporting hw mixing on one side
> and then touting other "anti-open-source" companies as examples to
> follow on the other.
Since when does using technology as an example mean that you condone the
way companies do business?
Ask Lennart. I only took his argument to its logical conclusion.
Maybe we should start removing other parts of
Fedora because they were inspired by, or share similar technical
features to things Microsoft or Apple did before us.
Ah, so dropping support for hw mixing is a great innovation.
I hope you see how flawed your argument is.
It was more of a ridicule than anything else.
> But whatever. Just please stop imposing pulseaudio on those who
don't
> want to use it. For the record, I'm still considering leaving Fedora
> because - as a GNOME desktop - it's becoming unusable without pulseaudio.
> Making it a hard dependency for GNOME bluetooth stack in F11 went a bit
> too far in my opinion.
I did that, and the reasons for it were discussed on this list. Nobody
has made any headway into explaining how to fix the problem[1] without
the hard dependency.
[1]: That'd be out-of-the-box Bluetooth headset and speakers support
While having support for stuff like that is great, I still would like
to be able to remove pulseaudio (even it it means losing support for
bluetooth headsets and speakers) without losing the rest of gnome-bluetooth.
What was the problem with that?
Regards,
R.
--
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu
"Faith manages."
-- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"
9:46 a.m.
Dne Wed, 29 Jul 2009 16:21:00 +0200 Dominik 'Rathann' Mierzejewski
napsal:
> > But whatever. Just please stop imposing pulseaudio on those
who
> > don't want to use it. For the record, I'm still considering
> > leaving Fedora because - as a GNOME desktop - it's becoming
> > unusable without pulseaudio. Making it a hard dependency for
> > GNOME bluetooth stack in F11 went a bit too far in my opinion.
>
> I did that, and the reasons for it were discussed on this list.
> Nobody has made any headway into explaining how to fix the
> problem[1] without the hard dependency.
>
> [1]: That'd be out-of-the-box Bluetooth headset and speakers support
While having support for stuff like that is great, I still would like
to be able to remove pulseaudio (even it it means losing support for
bluetooth headsets and speakers) without losing the rest of
gnome-bluetooth.
Dominik,
if you don't want to use PA, remove only alsa-plugins-pulseaudio, then
the "default" ALSA output won't be redirected to PA. You can leave
"pulseaudio" package installed to satisfy the dependencies.
Michal
10:27 a.m.
On Wed, 2009-07-29 at 16:46 +0200, Michal Schmidt wrote:
Dominik,
if you don't want to use PA, remove only alsa-plugins-pulseaudio, then
the "default" ALSA output won't be redirected to PA. You can leave
"pulseaudio" package installed to satisfy the dependencies.
That does mean a PA daemon will still be run by default and anything
that, for instance, checks if PA is running and then outputs direct to
PA, still will. I think this is what gstreamer's default 'auto detect'
setting does. But you can re-configure that to go to ALSA directly.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
9:49 a.m.
On Wednesday, 29 July 2009 at 17:27, Adam Williamson wrote:
On Wed, 2009-07-29 at 16:46 +0200, Michal Schmidt wrote:
> Dominik,
>
> if you don't want to use PA, remove only alsa-plugins-pulseaudio, then
> the "default" ALSA output won't be redirected to PA. You can leave
> "pulseaudio" package installed to satisfy the dependencies.
That does mean a PA daemon will still be run by default and anything
that, for instance, checks if PA is running and then outputs direct to
PA, still will. I think this is what gstreamer's default 'auto detect'
setting does. But you can re-configure that to go to ALSA directly.
Removing pulseaudio daemon from disk would ensure that it cannot be started
behind your back by one sound library or another. Hence my gripe about
not being able to remove it without sacrificing functionality that is not
dependent on it directly.
Regards,
R.
--
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu
"Faith manages."
-- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"
10:15 a.m.
On Thu, 2009-07-30 at 16:49 +0200, Dominik 'Rathann' Mierzejewski wrote:
Removing pulseaudio daemon from disk would ensure that it cannot be
started
behind your back by one sound library or another. Hence my gripe about
not being able to remove it without sacrificing functionality that is not
dependent on it directly.
We've already said we know the dependency is sub-optimal but cannot find
a better way to do it, and welcome any improvements in the form of
patches.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
8:51 a.m.
On Wed, Jul 29, 2009 at 8:39 AM, Dominik 'Rathann' Mierzejewski <
dominik(a)greysector.net> wrote:
On Wednesday, 29 July 2009 at 15:24, Lennart Poettering wrote:
> On Wed, 29.07.09 06:48, Jeff Garzik (jgarzik(a)pobox.com) wrote:
>
> >
> > Karel Zak wrote:
> >> On Tue, Jul 28, 2009 at 10:07:32PM +0200, Lennart Poettering wrote:
> >>> On Tue, 28.07.09 15:48, Bill Nottingham (notting(a)redhat.com) wrote:
> >>> Yes. You cannot select them as record source, you cannot mute or
> >>> unmute them, you cannot change their volume. "CD", "PC
Speaker",
> >>> "MIDI" and so on are just obsolete.
> >>
> >> This reminds me your note:
> >>
> >>
https://tango.0pointer.de/pipermail/pulseaudio-discuss/2009-July/004519.html
> >>
> >> PA does not make use of hardware mixing. And I don't plan to
change
> >> that. It's obsolete technology. CPUs these days come with
extensions
> >> such as MMX or SSE precisely for speeding up DSP tasks such as PCM
> >> mixing. This is way more flexible that hw mixing, and definitely
the
> >> way to the future, both on the desktop and on embedded envs as
well.
> >>
> >>
> >> The "obsolete technology" -- who made this decision? Is it your
private
> >> opinion or any suggestion from sound card manufacturers?
> >>
> >> It seems that HW companies still produce the "obsolete
technology".
> >
> > Quite agreed [says a former kernel audio driver maintainer], and I will
> > go even farther:
>
> Maybe since the times you worked on audio drivers the design of the
> sound cards changed a little and stuff like SSE became largely available?
>
> > It is completely stupid to waste host CPU on a task that can be
> > offloaded in parallel to dedicated audio hardware.
> >
> > If the user intentionally purchased expensive audio hardware with nice
> > hardware mixing, do not subvert the user's intentions by ignoring such
> > nice hardware.
> >
> > Any developer who claims "always use software mixing" or "always
use
> > hardware mixing" is a young, inexperienced fool. There are valid
> > situations for both choices.
>
> Hear hear, Mr. Garzik is the the old experienced wise man of audio,
> who knows so much more about audio than any of the audio guys at
> Microsoft or Apple.
It's quite hypocritical of you to use an "anti-open-source" company
(Creative) as an argument for not supporting hw mixing on one side
and then touting other "anti-open-source" companies as examples to
follow on the other.
But whatever. Just please stop imposing pulseaudio on those who don't
want to use it. For the record, I'm still considering leaving Fedora
because - as a GNOME desktop - it's becoming unusable without pulseaudio.
Making it a hard dependency for GNOME bluetooth stack in F11 went a bit
too far in my opinion.
Regards,
R.
This is supported by the zillions of forum messages asking how to fix or
remove pulseaudio. Not to mention the billion post thread here on devel.
--
projecthuh.com
All of my bits are free, are yours? Fedoraproject.org
11:27 a.m.
On Wed, 2009-07-29 at 08:51 -0500, Dr. Diesel wrote:
This is supported by the zillions of forum messages asking how to
fix
or remove pulseaudio. Not to mention the billion post thread here on
devel.
In my experience, this is a more common pattern:
$POOR_NEWBIE: I have a problem with audio.
$RANDOM_'HELPFUL'_PERSON: Oh, you need to remove PulseAudio!
Removing PA is far too often jumped on as the 'obvious' fix for
resolving any kind of audio problem whatsoever. Even if it had nothing
to do with PA in the first place.
In any case, there's a fairly easy, working way to disable PA that has
been posted to this thread, that works in all Fedora releases. So
there's no problem.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
11:42 a.m.
Adam Williamson wrote:
On Wed, 2009-07-29 at 08:51 -0500, Dr. Diesel wrote:
> This is supported by the zillions of forum messages asking how to fix
> or remove pulseaudio. Not to mention the billion post thread here on
> devel.
In my experience, this is a more common pattern:
$POOR_NEWBIE: I have a problem with audio.
$RANDOM_'HELPFUL'_PERSON: Oh, you need to remove PulseAudio!
Removing PA is far too often jumped on as the 'obvious' fix for
resolving any kind of audio problem whatsoever. Even if it had nothing
to do with PA in the first place.
And? Random helpful person quickly becomes ignored person, if the
advice fails to work.
Problem is... removing or disabling PA often -does- solve a problem.
Jeff
11:49 a.m.
On Wed, 2009-07-29 at 12:42 -0400, Jeff Garzik wrote:
Adam Williamson wrote:
> On Wed, 2009-07-29 at 08:51 -0500, Dr. Diesel wrote:
>
>> This is supported by the zillions of forum messages asking how to fix
>> or remove pulseaudio. Not to mention the billion post thread here on
>> devel.
>
> In my experience, this is a more common pattern:
>
> $POOR_NEWBIE: I have a problem with audio.
> $RANDOM_'HELPFUL'_PERSON: Oh, you need to remove PulseAudio!
>
> Removing PA is far too often jumped on as the 'obvious' fix for
> resolving any kind of audio problem whatsoever. Even if it had nothing
> to do with PA in the first place.
And? Random helpful person quickly becomes ignored person, if the
advice fails to work.
Problem is... removing or disabling PA often -does- solve a problem.
Rather, it works around it. The problems in the kernel drivers are
usually still there...
1:20 p.m.
Le mercredi 29 juillet 2009 à 17:49 +0100, Bastien Nocera a écrit :
On Wed, 2009-07-29 at 12:42 -0400, Jeff Garzik wrote:
> Problem is... removing or disabling PA often -does- solve a
problem.
Rather, it works around it. The problems in the kernel drivers are
usually still there...
Before PA a sound problem didn't freeze the GUI (effectively bricking
the system for normal users). Now it can. In my case, a few months ago,
it was doing so because a new PA version could not parse a manual config
change advertised in Fedora's own "Glitch-free audio" feature page a
release before.
Lennart stated that all this (PA being able to pull the GUI down, PA not
being able to parse what was a correct config file a version before, PA
rpm performing an unsafe upgrade) was NOTABUG.
--
Nicolas Mailhot
1:48 p.m.
On Wed, 29.07.09 20:20, Nicolas Mailhot (nicolas.mailhot(a)laposte.net) wrote:
Le mercredi 29 juillet 2009 à 17:49 +0100, Bastien Nocera a écrit :
> On Wed, 2009-07-29 at 12:42 -0400, Jeff Garzik wrote:
> > Problem is... removing or disabling PA often -does- solve a problem.
>
> Rather, it works around it. The problems in the kernel drivers are
> usually still there...
Before PA a sound problem didn't freeze the GUI (effectively bricking
the system for normal users). Now it can. In my case, a few months ago,
it was doing so because a new PA version could not parse a manual config
change advertised in Fedora's own "Glitch-free audio" feature page a
release before.
Lennart stated that all this (PA being able to pull the GUI down, PA not
being able to parse what was a correct config file a version before, PA
rpm performing an unsafe upgrade) was NOTABUG.
Twisting my words....
Lennart
--
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
1:56 p.m.
Le mercredi 29 juillet 2009 à 20:48 +0200, Lennart Poettering a écrit :
On Wed, 29.07.09 20:20, Nicolas Mailhot (nicolas.mailhot(a)laposte.net)
wrote:
> Le mercredi 29 juillet 2009 Ã 17:49 +0100, Bastien Nocera a
écrit :
> > On Wed, 2009-07-29 at 12:42 -0400, Jeff Garzik wrote:
>
> > > Problem is... removing or disabling PA often -does- solve a problem.
> >
> > Rather, it works around it. The problems in the kernel drivers are
> > usually still there...
>
> Before PA a sound problem didn't freeze the GUI (effectively bricking
> the system for normal users). Now it can. In my case, a few months ago,
> it was doing so because a new PA version could not parse a manual config
> change advertised in Fedora's own "Glitch-free audio" feature page a
> release before.
>
> Lennart stated that all this (PA being able to pull the GUI down, PA not
> being able to parse what was a correct config file a version before, PA
> rpm performing an unsafe upgrade) was NOTABUG.
Twisting my words....
https://bugzilla.redhat.com/show_bug.cgi?id=508436
--
Nicolas Mailhot
2:04 p.m.
On Wed, Jul 29, 2009 at 8:56 PM, Nicolas
Mailhot<nicolas.mailhot(a)laposte.net> wrote:
Le mercredi 29 juillet 2009 à 20:48 +0200, Lennart Poettering a écrit :
> On Wed, 29.07.09 20:20, Nicolas Mailhot (nicolas.mailhot(a)laposte.net) wrote:
> > Le mercredi 29 juillet 2009 à 17:49 +0100, Bastien Nocera a écrit :
> > > On Wed, 2009-07-29 at 12:42 -0400, Jeff Garzik wrote:
> >
> > > > Problem is... Â removing or disabling PA often -does- solve a problem.
> > >
> > > Rather, it works around it. The problems in the kernel drivers are
> > > usually still there...
> >
> > Before PA a sound problem didn't freeze the GUI (effectively bricking
> > the system for normal users). Now it can. In my case, a few months ago,
> > it was doing so because a new PA version could not parse a manual config
> > change advertised in Fedora's own "Glitch-free audio" feature page
a
> > release before.
> >
> > Lennart stated that all this (PA being able to pull the GUI down, PA not
> > being able to parse what was a correct config file a version before, PA
> > rpm performing an unsafe upgrade) was NOTABUG.
>
> Twisting my words....
https://bugzilla.redhat.com/show_bug.cgi?id=508436
well that one is easy to fix, just rename the config file in newer
versions to config-default.pa (or anything else) which would result
into old files not causing problems.
Broken upgrade paths because of a config file changes like that is unacceptable.
9:54 p.m.
On Wed, 2009-07-29 at 20:20 +0200, Nicolas Mailhot wrote:
Le mercredi 29 juillet 2009 à 17:49 +0100, Bastien Nocera a écrit :
> On Wed, 2009-07-29 at 12:42 -0400, Jeff Garzik wrote:
> > Problem is... removing or disabling PA often -does- solve a problem.
>
> Rather, it works around it. The problems in the kernel drivers are
> usually still there...
Before PA a sound problem didn't freeze the GUI (effectively bricking
the system for normal users). Now it can. In my case, a few months ago,
it was doing so because a new PA version could not parse a manual config
change advertised in Fedora's own "Glitch-free audio" feature page a
release before.
Oh, you must not have been around when esound was used in gnome. esd
used to die all the time and drag down applications with it as it went.
The app would sit there waiting to ring it's bell (or whatever) and
since esd wasn't responding, it would just stop.
Of course, you might blame the application (or maybe gnome) for assuming
that the app couldn't go on until that little bell chime rang.
R.
5:53 a.m.
Le vendredi 31 juillet 2009 à 12:54 +1000, Rodd Clarkson a écrit :
On Wed, 2009-07-29 at 20:20 +0200, Nicolas Mailhot wrote:
> Le mercredi 29 juillet 2009 à 17:49 +0100, Bastien Nocera a écrit :
> > On Wed, 2009-07-29 at 12:42 -0400, Jeff Garzik wrote:
>
> > > Problem is... removing or disabling PA often -does- solve a problem.
> >
> > Rather, it works around it. The problems in the kernel drivers are
> > usually still there...
>
> Before PA a sound problem didn't freeze the GUI (effectively bricking
> the system for normal users). Now it can. In my case, a few months ago,
> it was doing so because a new PA version could not parse a manual config
> change advertised in Fedora's own "Glitch-free audio" feature page a
> release before.
Oh, you must not have been around when esound was used in gnome.
I was around when gnome 0.3 was published by the rh labs
esd
used to die all the time and drag down applications with it as it went.
The app would sit there waiting to ring it's bell (or whatever) and
since esd wasn't responding, it would just stop.
esd at its worst never had the full-desktop-blackout effect pa has now.
esd made at most one or two app fail with clear feadback that esd was as
fault. Since the start of the F12 cycle I count at least 2 different
audio bugs that resulted in a complete desktop hang with no meaningful
error reporting or any way to recover the system.
--
Nicolas Mailhot
11:53 a.m.
On Wed, 2009-07-29 at 12:42 -0400, Jeff Garzik wrote:
> Removing PA is far too often jumped on as the 'obvious'
fix for
> resolving any kind of audio problem whatsoever. Even if it had nothing
> to do with PA in the first place.
And? Random helpful person quickly becomes ignored person, if the
advice fails to work.
Problem is... removing or disabling PA often -does- solve a problem.
There's two problems. One, it's often not the _right_ fix - there are
cases where PA's interaction with ALSA reveals bugs in ALSA that
otherwise stay hidden. So disabling PA 'fixes the bug', but in reality
is just sweeping it under the carpet.
Two, even when the bug is in PA, if everyone just goes around disabling
PA, how are they going to get fixed? Telepathy?
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
12:25 p.m.
On Wed, Jul 29, 2009 at 11:53 AM, Adam Williamson <awilliam(a)redhat.com>wrote:
On Wed, 2009-07-29 at 12:42 -0400, Jeff Garzik wrote:
> > Removing PA is far too often jumped on as the 'obvious' fix for
> > resolving any kind of audio problem whatsoever. Even if it had nothing
> > to do with PA in the first place.
>
> And? Random helpful person quickly becomes ignored person, if the
> advice fails to work.
>
> Problem is... removing or disabling PA often -does- solve a problem.
There's two problems. One, it's often not the _right_ fix - there are
cases where PA's interaction with ALSA reveals bugs in ALSA that
otherwise stay hidden. So disabling PA 'fixes the bug', but in reality
is just sweeping it under the carpet.
Two, even when the bug is in PA, if everyone just goes around disabling
PA, how are they going to get fixed? Telepathy?
How long do we expect people to tolerate these bugs before they move on?
--
projecthuh.com
All of my bits are free, are yours? Fedoraproject.org
1:17 p.m.
On Wed, 2009-07-29 at 12:25 -0500, Dr. Diesel wrote:
How long do we expect people to tolerate these bugs before they move
on?
I don't. However, for those doing support, there's better approaches
than 'disable PA and carry on using the system'. There's some
configuration tweaks you can make to PA. You can check the kernel and PA
logs for clues as to what the problem may be. You can get the
alsa-info.sh output and check for known issues with the hardware in
question (search on subv / subd for HDA hardware). Finally, if disabling
PA 'solves' the problem, you can file a bug on PA explaining the issue
and the symptoms, and including the kernel and PA logs. (To get PA log
output, kill the system pulseaudio instance, and run it from a console
as 'pulseaudio -vvvvv', then reproduce the problem). The key point is to
try and get some useful information about the problem and file a bug, so
that Lennart and the kernel sound guys _know_ about it. If no bugs are
filed, it's very unlikely the problem is going to be fixed.
I should probably write up a Debugging page for sound / PulseAudio,
actually...
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
9:51 p.m.
On Wed, 2009-07-29 at 12:25 -0500, Dr. Diesel wrote:
PA, how are they going to get fixed? Telepathy?
How long do we expect people to tolerate these bugs before they move
on?
I agree, there's only so long that people are willing to wait. But you
actually have to file a bug before you move on or you haven't
contributed at all.
I have bugs all over my now laptop and I could just switch OSes, but I'm
willing to be a little patient to allow things to catch up. More
importantly, I'm willing to file bugs and let someone address them.
But when you have a problem and go to a forum and find a solution and
don't ever report a bug, then you've got no right to bitch and whine
that bugs never get fixed and you get sick of waiting.
This of course is just good advice and has nothing to do with
pulseaudio, other then making the point in this thread.
R.
3:47 p.m.
On Wed, Jul 29, 2009 at 12:53 PM, Adam Williamson wrote:
On Wed, 2009-07-29 at 12:42 -0400, Jeff Garzik wrote:
> > Removing PA is far too often jumped on as the 'obvious' fix for
> > resolving any kind of audio problem whatsoever. Even if it had nothing
> > to do with PA in the first place.
>
> And? Â Random helpful person quickly becomes ignored person, if the
> advice fails to work.
>
> Problem is... Â removing or disabling PA often -does- solve a problem.
There's two problems. One, it's often not the _right_ fix - there are
cases where PA's interaction with ALSA reveals bugs in ALSA that
otherwise stay hidden. So disabling PA 'fixes the bug', but in reality
is just sweeping it under the carpet.
Two, even when the bug is in PA, if everyone just goes around disabling
PA, how are they going to get fixed? Telepathy?
Well, the fix is easy. Do I need repeat it once more? It's been a while :)
Orcan
9:19 a.m.
Hi.
On Wed, 29 Jul 2009 15:39:14 +0200, Dominik 'Rathann' Mierzejewski wrote:
But whatever. Just please stop imposing pulseaudio on those who
don't
want to use it. For the record, I'm still considering leaving Fedora
because - as a GNOME desktop - it's becoming unusable without
pulseaudio. Making it a hard dependency for GNOME bluetooth stack in
F11 went a bit too far in my opinion.
I'm obviously missing something. Are you opposed to the general fact that
PA packages use up your disk space, or just to the fact that PA tries
to handle your audio?
If the latter, I've removed alsa-plugins-pulseaudio and pointed my audip
apps to alsa for sound output. As far as I can tell that removes PA
from the picture.
9:47 a.m.
Hi,
On Wednesday, 29 July 2009 at 16:19, Ralf Ertzinger wrote:
On Wed, 29 Jul 2009 15:39:14 +0200, Dominik 'Rathann'
Mierzejewski wrote:
> But whatever. Just please stop imposing pulseaudio on those who don't
> want to use it. For the record, I'm still considering leaving Fedora
> because - as a GNOME desktop - it's becoming unusable without
> pulseaudio. Making it a hard dependency for GNOME bluetooth stack in
> F11 went a bit too far in my opinion.
I'm obviously missing something. Are you opposed to the general fact that
PA packages use up your disk space, or just to the fact that PA tries
to handle your audio?
I don't want pulseaudio daemon to be started at all. The proper way to do
it is to remove it from my disk. I do care about disk space, but I don't
particularly mind if there are some libraries taking up space. Daemons that
get started behind my back are a different and annoying issue.
If the latter, I've removed alsa-plugins-pulseaudio and pointed
my audip
apps to alsa for sound output. As far as I can tell that removes PA
from the picture.
Not completely IIUC.
Regards,
R.
--
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu
"Faith manages."
-- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"
3:35 p.m.
On Wed, Jul 29, 2009 at 9:24 AM, Lennart Poettering <mzerqung(a)0pointer.de>wrote:
On Wed, 29.07.09 06:48, Jeff Garzik (jgarzik(a)pobox.com) wrote:
>
> Karel Zak wrote:
>> On Tue, Jul 28, 2009 at 10:07:32PM +0200, Lennart Poettering wrote:
>>> On Tue, 28.07.09 15:48, Bill Nottingham (notting(a)redhat.com) wrote:
>>> Yes. You cannot select them as record source, you cannot mute or
>>> unmute them, you cannot change their volume. "CD", "PC
Speaker",
>>> "MIDI" and so on are just obsolete.
>>
>> This reminds me your note:
>>
>>
https://tango.0pointer.de/pipermail/pulseaudio-discuss/2009-July/004519.html
>>
>> PA does not make use of hardware mixing. And I don't plan to change
>> that. It's obsolete technology. CPUs these days come with extensions
>> such as MMX or SSE precisely for speeding up DSP tasks such as PCM
>> mixing. This is way more flexible that hw mixing, and definitely the
>> way to the future, both on the desktop and on embedded envs as well.
>>
>>
>> The "obsolete technology" -- who made this decision? Is it your
private
>> opinion or any suggestion from sound card manufacturers?
>>
>> It seems that HW companies still produce the "obsolete technology".
>
> Quite agreed [says a former kernel audio driver maintainer], and I will
> go even farther:
Maybe since the times you worked on audio drivers the design of the
sound cards changed a little and stuff like SSE became largely available?
> It is completely stupid to waste host CPU on a task that can be
> offloaded in parallel to dedicated audio hardware.
>
> If the user intentionally purchased expensive audio hardware with nice
> hardware mixing, do not subvert the user's intentions by ignoring such
> nice hardware.
>
> Any developer who claims "always use software mixing" or "always use
> hardware mixing" is a young, inexperienced fool. There are valid
> situations for both choices.
Hear hear, Mr. Garzik is the the old experienced wise man of audio,
who knows so much more about audio than any of the audio guys at
Microsoft or Apple.
Happy to take patches.
Lennart
Here is a patch, 2 weeks old.
https://bugzilla.redhat.com/show_bug.cgi?id=461546
--
projecthuh.com
All of my bits are free, are yours? Fedoraproject.org
9:01 a.m.
Dne Wed, 29 Jul 2009 16:35:54 -0400 Dr. Diesel napsal(a):
On Wed, Jul 29, 2009 at 9:24 AM, Lennart Poettering
> On Wed, 29.07.09 06:48, Jeff Garzik wrote:
> > Any developer who claims "always use software mixing" or
"always
> > use hardware mixing" is a young, inexperienced fool. There are
> > valid situations for both choices.
>
> Hear hear, Mr. Garzik is the the old experienced wise man of audio,
> who knows so much more about audio than any of the audio guys at
> Microsoft or Apple.
>
> Happy to take patches.
>
> Lennart
>
Here is a patch, 2 weeks old.
https://bugzilla.redhat.com/show_bug.cgi?id=461546
I took a look at the bug and also at the related upstream Trac ticket
http://www.pulseaudio.org/ticket/606
A few observations:
- The patch has nothing to do with {soft,hard}ware mixing. It's about
system-wide mode of PA.
- The patch may be 2 weeks old, but there was active discussion
about it just 2 days ago.
- It's funny how in the BZ the proponent of the patch first accused
Lennart of "Dreppering" the bug and then he himself needlessly
insulted Lubomir Rintel who had reviewed the patch.
- In the upstream ticket the patch proponent uses undiplomatic innuendo
in most comments and stubbornly demands his patch to be accepted
even though it is seen as a kludge by both Lennart and Colin and
Lennart gives a hint how it should be solved in a better way.
7 a.m.
On Jul 29, 2009, at 6:48 AM, Jeff Garzik wrote:
Karel Zak wrote:
> On Tue, Jul 28, 2009 at 10:07:32PM +0200, Lennart Poettering wrote:
>> On Tue, 28.07.09 15:48, Bill Nottingham (notting(a)redhat.com) wrote:
>> Yes. You cannot select them as record source, you cannot mute or
>> unmute them, you cannot change their volume. "CD", "PC
Speaker",
>> "MIDI" and so on are just obsolete.
> This reminds me your note:
> https://tango.0pointer.de/pipermail/pulseaudio-discuss/2009-July/004519.html
> PA does not make use of hardware mixing. And I don't plan to
> change
> that. It's obsolete technology. CPUs these days come with
> extensions
> such as MMX or SSE precisely for speeding up DSP tasks such as PCM
> mixing. This is way more flexible that hw mixing, and definitely
> the
> way to the future, both on the desktop and on embedded envs as
> well.
> The "obsolete technology" -- who made this decision? Is it your
> private
> opinion or any suggestion from sound card manufacturers?
> It seems that HW companies still produce the "obsolete technology".
Quite agreed [says a former kernel audio driver maintainer], and I
will go even farther:
It is completely stupid to waste host CPU on a task that can be
offloaded in parallel to dedicated audio hardware.
If the user intentionally purchased expensive audio hardware with
nice hardware mixing, do not subvert the user's intentions by
ignoring such nice hardware.
Any developer who claims "always use software mixing" or "always use
hardware mixing" is a young, inexperienced fool. There are valid
situations for both choices.
Agree 1000%. As another kernel engineer that's done sound hardware
amongst other things, if you want to duplicate hardware mixing in my
CPU I'm going to toss you out on your ear. The amount of CPU PA
wastes already drives me nuts. My CPU is intended for important
things, like kernel compiles, not to be wasted unnecessarily on down
mixing or up mixing an audio stream. It gets worse when you have a
primary log in as yourself, and a secondary login for separate mail
processing, and you want paplay to play a sound on certain emails,
because it has to route the sound through pa means that if it even
plays at all it plays rough and choppy and uses an assload of CPU
time. I can't tell you how many times emails got delayed 12+ hours
because they were waiting on paplay to finish playing a simple beep
when they didn't own the console.
--
Doug Ledford <dledford(a)redhat.com>
GPG KeyID: CFBFF194
http://people.redhat.com/dledford
InfiniBand Specific RPMS
http://people.redhat.com/dledford/Infiniband
8:28 a.m.
On Thu, Jul 30, 2009 at 12:00 PM, Doug Ledford<dledford(a)redhat.com> wrote:
Agree 1000%. Â As another kernel engineer that's done sound hardware amongst
other things, if you want to duplicate hardware mixing in my CPU I'm going
to toss you out on your ear. Â The amount of CPU PA wastes already drives me
nuts. Â My CPU is intended for important things, like kernel compiles, not to
be wasted unnecessarily on down mixing or up mixing an audio stream.
So you personally own such hardware?
 It
gets worse when you have a primary log in as yourself, and a secondary login
for separate mail processing, and you want paplay to play a sound on certain
emails, because it has to route the sound through pa means that if it even
plays at all it plays rough and choppy
Sound is hard; as I understand it this could be driver bugs,
scheduling problems, etc. Lennart's done a lot of work on safely
making the pulse process real-time, which you may or may not have yet.
can't tell you how many times emails got delayed 12+ hours
because they were
waiting on paplay to finish playing a simple beep when they didn't own the
console.
Hmm...I'm confused about the setup here (why a secondary login for
mail processing?) but that aside, probably paplay should have a
--force option to avoid the delay. The reason pulse delays here is
for things like music players where the target behavior is when you
fast user switch, the music player app stops playing.
9:41 a.m.
On Jul 30, 2009, at 9:28 AM, Colin Walters wrote:
On Thu, Jul 30, 2009 at 12:00 PM, Doug
Ledford<dledford(a)redhat.com>
wrote:
>
> Agree 1000%. As another kernel engineer that's done sound hardware
> amongst
> other things, if you want to duplicate hardware mixing in my CPU
> I'm going
> to toss you out on your ear. The amount of CPU PA wastes already
> drives me
> nuts. My CPU is intended for important things, like kernel
> compiles, not to
> be wasted unnecessarily on down mixing or up mixing an audio stream.
So you personally own such hardware?
Not hardware up mix/down mixing, but hardware mixing. And as my other
post points out, I make use of it and have no intent of ever not using
it. Right now I simply use gst-mixer to enable the mixing behind PA's
back. I consider the fact that PA can't/won't do it to be a serious
design flaw.
> It
> gets worse when you have a primary log in as yourself, and a
> secondary login
> for separate mail processing, and you want paplay to play a sound
> on certain
> emails, because it has to route the sound through pa means that if
> it even
> plays at all it plays rough and choppy
Sound is hard; as I understand it this could be driver bugs,
scheduling problems, etc. Lennart's done a lot of work on safely
making the pulse process real-time, which you may or may not have yet.
It worked fine prior to PA. I can't say what specifically is causing
it, other than the paplay command will often start to play, get a
little out, then just never complete. I used to use this to alert me
to specific emails that I needed to respond to immediately, instead I
now redirect them to a different folder and have my mail client (which
runs as the primary user) alert me instead.
> can't tell you how many times emails got delayed 12+ hours
because
> they were
> waiting on paplay to finish playing a simple beep when they didn't
> own the
> console.
Hmm...I'm confused about the setup here (why a secondary login for
mail processing?) but that aside, probably paplay should have a
--force option to avoid the delay. The reason pulse delays here is
for things like music players where the target behavior is when you
fast user switch, the music player app stops playing.
Because I fetchmail all my different email accounts to a single box,
and depending on mail client, some want different actual IMAP accounts
in order to support multiple outgoing identities. My primary account
has an IMAP login that maps to one email address and the secondary
account maps to another.
--
Doug Ledford <dledford(a)redhat.com>
GPG KeyID: CFBFF194
http://people.redhat.com/dledford
InfiniBand Specific RPMS
http://people.redhat.com/dledford/Infiniband
1:14 p.m.
On Thu, Jul 30, 2009 at 10:41:34AM -0400, Doug Ledford wrote:
Not hardware up mix/down mixing, but hardware mixing. And as my
other
post points out, I make use of it and have no intent of ever not using
it. Right now I simply use gst-mixer to enable the mixing behind PA's
back. I consider the fact that PA can't/won't do it to be a serious
design flaw.
The discussion in question was on whether or not PA would support using
hardware functionality to mix multiple PCM streams. Your situation seems
to be orthogonal to that. Conflating them isn't helpful.
--
Matthew Garrett | mjg59(a)srcf.ucam.org
8:13 a.m.
On Wed, 29.07.09 09:46, Karel Zak (kzak(a)redhat.com) wrote:
On Tue, Jul 28, 2009 at 10:07:32PM +0200, Lennart Poettering wrote:
> On Tue, 28.07.09 15:48, Bill Nottingham (notting(a)redhat.com) wrote:
>
> >
> > Lennart Poettering (mzerqung(a)0pointer.de) said:
> > > Please note that it is our intention not to wrap obsolete mixer
> > > controls such as "CD", "PC Speaker", "MIDI"
and so on. If you file a
> > > bug asking for those to be wrapped we will disappoint you and
> > > close the bug WONTFIX.
> >
> > When you mean 'not wrap them', do you mean they're no longer
> > selectable as a record source, if the hardware exports them?
>
> Yes. You cannot select them as record source, you cannot mute or
> unmute them, you cannot change their volume. "CD", "PC
Speaker",
> "MIDI" and so on are just obsolete.
This reminds me your note:
https://tango.0pointer.de/pipermail/pulseaudio-discuss/2009-July/004519.html
PA does not make use of hardware mixing. And I don't plan to change
that. It's obsolete technology. CPUs these days come with extensions
such as MMX or SSE precisely for speeding up DSP tasks such as PCM
mixing. This is way more flexible that hw mixing, and definitely the
way to the future, both on the desktop and on embedded envs as well.
The "obsolete technology" -- who made this decision? Is it your private
opinion or any suggestion from sound card manufacturers?
It's my opinion. Which is based on not being blind to what's happening
around me.
It seems that HW companies still produce the "obsolete
technology".
Modern sound card designs don't do hw mixing anymore, it's like
fm synthesis or wavetable audio. It's simply not done in hw
anymore. The only exceptions are cards for gamers, i.e. Creative
cards. And uh, quite frankly those cards probably only have it because
they need at least something that distuingishes them from normal HDA
cards.
In my little array of sound cards I have here not a single one still
does hw mixing. So even if I wanted to add hw mixing support to PA I
couldn't because I have nothing to test with. Also given that these
days you find that feature only in Creative cards and Creative is
mostly anti-Free-Software I really see no point in spending a minute
on adding support for this to PA even if it would make technical
sense, which it doesn't.
Also, let's not forget smething: DirectSound in Vista does not support
hw acceleration for audio at all anymore:
http://connect.creativelabs.com/openal/OpenAL%20Wiki/OpenAL%C2%AE%20and%2...
And CoreAudio never did either.
Creative is now pushing OpenAL since they apparently believe that hw
mixing just for hw mixing's sake is something that makes sense to
gamers -- even though it makes no sense at all to me.
But than again, if hw mixing is that important to you, I am happy to
merge patches if they are clean.
Lennart
--
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
10:21 a.m.
On Wed, 2009-07-29 at 15:13 +0200, Lennart Poettering wrote:
Modern sound card designs don't do hw mixing anymore, it's
like
fm synthesis or wavetable audio. It's simply not done in hw
anymore. The only exceptions are cards for gamers, i.e. Creative
cards. And uh, quite frankly those cards probably only have it because
they need at least something that distuingishes them from normal HDA
cards.
Just out of curiosity - do modern pro cards (M-Audio etc) do hw mixing?
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
5:09 p.m.
Lennart Poettering wrote:
Modern sound card designs don't do hw mixing anymore, it's
like
fm synthesis or wavetable audio.
/me misses fm synth :-)
(At least, I'm still looking for something that will turn a MIDI into a
.wav/.ogg/etc that sounds like an SB16... DOS MIDI player in dosbox is
the closest I've found so far, but it sucks for batch processing.)
--
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
--
Disadvantage: Bad Puns [-5]
You constantly utter puns so egregious as to cause mental distress to
anyone hearing them. This can, however, be used to distract enemies.
5:23 p.m.
On Thu, 30.07.09 17:09, Matthew Woehlke (mw_triad(a)users.sourceforge.net) wrote:
Lennart Poettering wrote:
> Modern sound card designs don't do hw mixing anymore, it's like
> fm synthesis or wavetable audio.
/me misses fm synth :-)
(At least, I'm still looking for something that will turn a MIDI into a
.wav/.ogg/etc that sounds like an SB16... DOS MIDI player in dosbox is
the closest I've found so far, but it sucks for batch processing.)
Try timidity.
Lennart
--
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
6:58 p.m.
Lennart Poettering wrote:
On Thu, 30.07.09 17:09, Matthew Woehlke (elided) wrote:
Please do not quote my e-mail address unobfuscated in message bodies.
> Lennart Poettering wrote:
>> Modern sound card designs don't do hw mixing anymore, it's like
>> fm synthesis or wavetable audio.
> /me misses fm synth :-)
>
> (At least, I'm still looking for something that will turn a MIDI into a
> .wav/.ogg/etc that sounds like an SB16... DOS MIDI player in dosbox is
> the closest I've found so far, but it sucks for batch processing.)
Try timidity.
You have a soundfont that sounds like an OPL3? If so, I would be much
appreciative if you could hook me up. (But I'm guessing you failed to
read the part about "sounds like an SB16"... i.e. an OPL3 fm synth chip,
not the AWE-generation wavetable stuff. I *do* still have my Creative
AWE .sf2's, thank you.)
--
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
--
Disadvantage: Bad Puns [-5]
You constantly utter puns so egregious as to cause mental distress to
anyone hearing them. This can, however, be used to distract enemies.
8:10 p.m.
Matthew Woehlke <mw_triad(a)users.sourceforge.net> writes:
Lennart Poettering wrote:
> On Thu, 30.07.09 17:09, Matthew Woehlke (elided) wrote:
Please do not quote my e-mail address unobfuscated in message bodies.
Why on earth not? Your email address is in plain sight in the headers.
- FChE
8:22 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Frank Ch. Eigler wrote:
Matthew Woehlke writes:
> Lennart Poettering wrote:
>> On Thu, 30.07.09 17:09, Matthew Woehlke (elided) wrote:
>
> Please do not quote my e-mail address unobfuscated in message
bodies.
Why on earth not? Your email address is in plain sight in the
headers.
- FChE
Plus sf.net addresses get spammed just for existing.
- --Ben
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAkpyR1UACgkQiPi+MRHG3qSglgCggrG9hVmOQcS1e143e0ZjufI2
H9IAoKGdpKSC1d8Ifbl2Oef/ahdeQ6bc
=5vB3
-----END PGP SIGNATURE-----
11:41 a.m.
On Thu, 30 Jul 2009 18:58:55 -0500, Matthew wrote:
Lennart Poettering wrote:
> On Thu, 30.07.09 17:09, Matthew Woehlke (elided) wrote:
Please do not quote my e-mail address unobfuscated in message bodies.
>> Lennart Poettering wrote:
>>> Modern sound card designs don't do hw mixing anymore, it's like
>>> fm synthesis or wavetable audio.
>> /me misses fm synth :-)
>>
>> (At least, I'm still looking for something that will turn a MIDI into a
>> .wav/.ogg/etc that sounds like an SB16... DOS MIDI player in dosbox is
>> the closest I've found so far, but it sucks for batch processing.)
>
> Try timidity.
You have a soundfont that sounds like an OPL3? If so, I would be much
appreciative if you could hook me up. (But I'm guessing you failed to
read the part about "sounds like an SB16"... i.e. an OPL3 fm synth chip,
not the AWE-generation wavetable stuff. I *do* still have my Creative
AWE .sf2's, thank you.)
You cannot come close to OPL3 with just soundfonts or wavetables. It would
need OPL3 chip emulation (similar to "adplug", in Fedora). And even then
you need a MIDI player that implements approximately the same instrument
definitions as the original one from DOS/Windows. For many MIDI
soundtracks created for AdLib as well as OPL2/3, it needs a special
AdLib/OPL3 driver that programs the original synthetical instruments.
Btw, early AWE-generation boards, such as the AWE32, also had AdLib plus
OPL3 onboard.
3:10 a.m.
On Tue, 2009-07-28 at 15:59 +0200, Lennart Poettering wrote:
In the F11 cycle there has been some criticism on how g-v-c was
presenting a new minimal volume control interface. Most issues raised
back then should now be fixed, except for a few which we consider
strictly out of focus for us.
I'd like to ask everyone to test this new volume logic. If you don't
raise your voice now that some output port is not properly detected or
audio is too faint then later on you won't have any right to complain.
You should particularly pay attention to the new "Hardware" tab in
g-v-c, where you can now choose the hardware profile (i.e. stereo
vs. 5.1, and so on) which you want to use. And then on the
Input/Output tab you may or may not find an additional dropdown menu
for selecting the port you want to use (only shown if you have more
than one).
gst-mixer is not longer listed as default in comps now.
as the other interested party, this is perfectly fine by me as long as
we get any bugs out of the new code, which I'm sure we'll manage. I may
even drop the package entirely, since we do have other alternatives.
thanks a lot for the work on the new stuff.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
3:33 a.m.
Let me take the chance to thank you, Lennart. Even though PulseAudio has
always been a controversial topic and there are many negative feelings
about it I still think I am not the only one who really enjoys the new
audio and volume control features Fedoa offers. It has really made my
life easier and is a big step forward towards a user-friendly desktop
environment. I think many people who don't actually know how to use a
mailing list and just use PulseAudio et al. think the same.
Lennart, I think you are moving things in the right direction and I
would like to thank you for all the hard work you have put into
PulseAudio. I think you have the kind of thick skin that is required to
make fundamental changes in this environment ;-)
Felix
11:08 a.m.
On Tue, 28 Jul 2009, Lennart Poettering wrote:
I'd like to ask everyone to test this new volume logic. If you
don't raise your voice now that some output port is not properly
detected or audio is too faint then later on you won't have any
right to complain.
Is there a way to test this if one does not have the luxury of
re-installing one's desktop to F12 (from F11)?
ObPA: I wish client volume state was kept PA side - not enjoying the
frequent resets of volume in clients in F11. Bring back system-side
state for volume please..
regards,
--
Paul Jakma paul(a)jakma.org Key ID: 64A2FF6A
Fortune:
Your mode of life will be changed to ASCII.
6:10 a.m.
2009/7/28 Lennart Poettering <mzerqung(a)0pointer.de>:
<snip>
I'd like to ask everyone to test this new volume logic. If you
don't
raise your voice now that some output port is not properly detected or
audio is too faint then later on you won't have any right to complain.
I think you do what you can to make an excellent job on PA.
What i really dont like is this quoted part. Not everybody is able to
test that right now. Means all that people who can't (for whatever
reasons), are screwed "later" (whatever later means). Together with
the attitude of "WONTFIX" in BZ that will come up, as you said, sounds
really bad.
But i might understand it wrong. Greetings from one of the lucky users
who has no problem with PA.
--
LG Thomas
Dubium sapientiae initium
5:54 a.m.
On Fri, 2009-07-31 at 11:10 +0000, Thomas Janssen wrote:
> I'd like to ask everyone to test this new volume logic. If
you don't
> raise your voice now that some output port is not properly detected or
> audio is too faint then later on you won't have any right to complain.
I think you do what you can to make an excellent job on PA.
What i really dont like is this quoted part. Not everybody is able to
test that right now. Means all that people who can't (for whatever
reasons), are screwed "later" (whatever later means).
Two points.
Firstly, that's the nature of testing. Not everyone can test things and
sometimes some peoples situations get missed.
Secondly, Lennart posted this to fedora-devel-list which is for people
willing to test the current version of fedora. So everyone on this list
who interested in this can test it should they wish.
R.
5370
days inactive
5385
days old
96 comments
30 participants
participants (30)
-
Adam Williamson -
Andy Lawrence -
Bastien Nocera -
Ben Boeckel -
Bill Nottingham -
Bruno Wolff III -
Colin Walters -
Dominik 'Rathann' Mierzejewski -
Doug Ledford -
drago01 -
Felix Kaechele -
Frank Ch. Eigler -
Jeff Garzik -
John Poelstra -
Josh Boyer -
Karel Zak -
Lennart Poettering -
Matthew Garrett -
Matthew Woehlke -
Michael Schwendt -
Michal Hlavinka -
Michal Schmidt -
Neal Gompa -
Nicolas Mailhot -
Orcan Ogetbil -
Paul Jakma -
Pierre-Yves Chibon -
Ralf Ertzinger -
Rodd Clarkson -
Thomas Janssen