[ANNOUNCE] New Mixer Handling in PA 0.9.16/F12

[Lennart Poettering]

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

[Bruno Wolff III]

On Tue, Jul 28, 2009 at 15:59:58 +0200,

Post by Lennart Poettering
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.

[Pierre-Yves]

Post by Lennart Poettering
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

[Lennart Poettering]

Post by Pierre-Yves

Post by Lennart Poettering
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

[Ben Boeckel]

Post by Lennart Poettering
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

Post by Lennart Poettering
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

[drago01]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Post by Lennart Poettering
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

Post by Lennart Poettering
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.

[Lennart Poettering]

Post by Lennart Poettering

Post by Lennart Poettering
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

Post by Lennart Poettering
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

[Doug Ledford]

Post by Lennart Poettering

Post by Lennart Poettering

Post by Lennart Poettering
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

Post by Lennart Poettering
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 at redhat.com>

GPG KeyID: CFBFF194
http://people.redhat.com/dledford

InfiniBand Specific RPMS
http://people.redhat.com/dledford/Infiniband




-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 203 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20090730/ff457df8/attachment.bin

[Bastien Nocera]

Post by Doug Ledford
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

[Matthew Woehlke]

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?

[Lennart Poettering]

Post by Matthew Woehlke

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

[Jeff Garzik]

Post by Lennart Poettering
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 :)

Modern hardware isn't all PCM either...

Jeff

[Lennart Poettering]

Post by Jeff Garzik

Post by Lennart Poettering
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

[Jeff Garzik]

Post by Lennart Poettering

Post by Jeff Garzik

Post by Lennart Poettering
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

[Lennart Poettering]

Post by Jeff Garzik

Post by Lennart Poettering

Post by Jeff Garzik

Post by Lennart Poettering
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

[Jeff Garzik]

Post by Lennart Poettering

Post by Jeff Garzik

Post by Lennart Poettering

Post by Jeff Garzik

Post by Lennart Poettering
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

[Lennart Poettering]

Post by Jeff Garzik

Post by Lennart Poettering

Post by Jeff Garzik

Post by Lennart Poettering

Post by Jeff Garzik

Post by Lennart Poettering
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

[Ben Boeckel]

Post by Lennart Poettering

Post by Jeff Garzik

Post by Lennart Poettering
Doing digital grabbing of is very reliable these days. The

analog path

Post by Lennart Poettering

Post by Jeff Garzik

Post by Lennart Poettering
is just completely obsolete.

I guess it's an open question why HDA touts multi-analog and

hw mixing

Post by Lennart Poettering

Post by Jeff Garzik
as modern features, then :)

Oh does it? How about adding some references to this claim?

Might be

Post by Lennart Poettering
actually convincing then.
At least I couldn't find anything googling for 'HDA hardware-

mixing'.

Post by Lennart Poettering
Nor could I find anything googling for 'HDA multi-analog'.
Please check your dictionary and look up "to tout". There

you'll find

Post by Lennart Poettering
that it means "to solicit, peddle, or persuade importunately".

It's

Post by Lennart Poettering
not particularly "importunate" if google can show no trace of

it, is it?

Post by Lennart Poettering
And also, please paste a dump of "amixer -c0" for your HDA

card so

Post by Lennart Poettering
that we can see that it includes a "CD" control. And the

contents of

Post by Lennart Poettering
/proc/asound/pcm would be cool, too, so that we can see your

HDA card

Post by Lennart Poettering
does hw mixing.
If you cannot produce anything of that I'd recommend a good

ol' cup of

Post by Lennart Poettering
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)

[John Poelstra]

Post by Lennart Poettering
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

[Josh Boyer]

Post by John Poelstra

Post by Lennart Poettering
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.

Post by John Poelstra
This is getting really childish and unprofessional.

I do certainly agree there.

josh

[Bill Nottingham]

Post by Lennart Poettering
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

[Doug Ledford]

Post by Bill Nottingham

Post by Lennart Poettering
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 at 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 at 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 at 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

[Lennart Poettering]

Post by Doug Ledford
[dledford at 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

[Doug Ledford]

Post by Lennart Poettering

Post by Jeff Garzik

Post by Lennart Poettering
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.

[Matthew Woehlke]

Please do not quote my e-mail address unobfuscated in message bodies.

Post by Lennart Poettering
- 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.

Post by Lennart Poettering
- 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...)

[Doug Ledford]

Post by Lennart Poettering

Post by Matthew Woehlke

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.

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.

Post by Lennart Poettering
- 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.

Post by Lennart Poettering
- 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.

Post by Lennart Poettering
- 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.

Post by Lennart Poettering
- 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.

Post by Lennart Poettering
- 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.

[Lennart Poettering]

Post by Doug Ledford

Post by Lennart Poettering
- 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

[Doug Ledford]

Post by Matthew Woehlke

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.
(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
(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.

[Matthew Garrett]

Post by Doug Ledford
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.

[Doug Ledford]

Post by Matthew Garrett

Post by Doug Ledford
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.

[Adam Williamson]

Post by Doug Ledford

Post by Matthew Garrett

Post by Doug Ledford
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?

[Doug Ledford]

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.

Post by Adam Williamson

Post by Doug Ledford

Post by Matthew Garrett

Post by Doug Ledford
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 at redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

[Matthew Garrett]

Post by Doug Ledford
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.

[Doug Ledford]

Apologies for my late reply, I was gone for a week.

Post by Matthew Garrett

Post by Doug Ledford
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.

Post by Matthew Garrett
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?

Post by Matthew Garrett
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.

Post by Matthew Garrett
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 at redhat.com>

GPG KeyID: CFBFF194
http://people.redhat.com/dledford

InfiniBand Specific RPMS
http://people.redhat.com/dledford/Infiniband




-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 203 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20090811/90d12658/attachment.bin

[Adam Williamson]

Post by Doug Ledford
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.

Post by Doug Ledford
(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.

[Matthew Garrett]

Post by Doug Ledford
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.

Post by Doug Ledford
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.

[Bill Nottingham]

Post by Lennart Poettering
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

[Lennart Poettering]

Post by Bill Nottingham

Post by Lennart Poettering
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

[Adam Williamson]

Post by Lennart Poettering

Post by Bill Nottingham

Post by Lennart Poettering
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]

Post by Adam Williamson

Post by Lennart Poettering

Post by Bill Nottingham
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.

[Karel Zak]

Post by Lennart Poettering

Post by Bill Nottingham

Post by Lennart Poettering
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

[Michal Hlavinka]

Post by Karel Zak
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.

[Dr. Diesel]

Post by Karel Zak
https://tango.0pointer.de/pipermail/pulseaudio-discuss/2009-July/004519.htm

Post by Karel Zak
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.

[Lennart Poettering]

Post by Michal Hlavinka

Post by Karel Zak
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

[Michal Hlavinka]

Post by Lennart Poettering

Post by Michal Hlavinka

Post by Karel Zak
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

[Adam Williamson]

Post by Michal Hlavinka

Post by Lennart Poettering
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.

[Jeff Garzik]

Post by Lennart Poettering
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...

Post by Lennart Poettering
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

[Lennart Poettering]

Post by Jeff Garzik

Post by Lennart Poettering
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

[Jeff Garzik]

Post by Lennart Poettering

Post by Jeff Garzik

Post by Lennart Poettering
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

[Adam Williamson]

Post by Lennart Poettering

Post by Jeff Garzik

Post by Lennart Poettering
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.

[King InuYasha]

Post by Adam Williamson

Post by Lennart Poettering

Post by Jeff Garzik

Post by Lennart Poettering
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 at 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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.fedoraproject.org/pipermail/devel/attachments/20090729/7ad20e06/attachment.html

[Jeff Garzik]

Post by Karel Zak

Post by Lennart Poettering
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.

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

[Lennart Poettering]

Post by Jeff Garzik

Post by Karel Zak

Post by Lennart Poettering
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.

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

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?

Post by Jeff Garzik
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

[Dominik 'Rathann' Mierzejewski]

Post by Lennart Poettering

Post by Jeff Garzik

Post by Karel Zak

Post by Lennart Poettering
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.

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

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?

Post by Jeff Garzik
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.

[Bastien Nocera]

On Wed, 2009-07-29 at 15:39 +0200, Dominik 'Rathann' Mierzejewski wrote:
<snip>

Post by Dominik 'Rathann' Mierzejewski
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.

Post by Dominik 'Rathann' Mierzejewski
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

[Dominik 'Rathann' Mierzejewski]

Post by Bastien Nocera
<snip>

Post by Dominik 'Rathann' Mierzejewski
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.

Post by Bastien Nocera
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.

Post by Bastien Nocera
I hope you see how flawed your argument is.

It was more of a ridicule than anything else.

Post by Bastien Nocera

Post by Dominik 'Rathann' Mierzejewski
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.

[Michal Schmidt]

Dne Wed, 29 Jul 2009 16:21:00 +0200 Dominik 'Rathann' Mierzejewski

Post by Dominik 'Rathann' Mierzejewski

Post by Bastien Nocera

Post by Dominik 'Rathann' Mierzejewski
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

[Adam Williamson]

Post by Michal Schmidt
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.

[Dominik 'Rathann' Mierzejewski]

Post by Adam Williamson

Post by Michal Schmidt
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.

[Adam Williamson]

Post by Dominik 'Rathann' Mierzejewski
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.

[Dr. Diesel]

On Wed, Jul 29, 2009 at 8:39 AM, Dominik 'Rathann' Mierzejewski <

Post by Karel Zak

Post by Lennart Poettering

Post by Jeff Garzik

Post by Karel Zak

Post by Lennart Poettering
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.

https://tango.0pointer.de/pipermail/pulseaudio-discuss/2009-July/004519.html

Post by Lennart Poettering

Post by Jeff Garzik

Post by Karel Zak
PA does not make use of hardware mixing. And I don't plan to

change

Post by Lennart Poettering

Post by Jeff Garzik

Post by Karel Zak
that. It's obsolete technology. CPUs these days come with

extensions

Post by Lennart Poettering

Post by Jeff Garzik

Post by Karel Zak
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

Post by Lennart Poettering

Post by Jeff Garzik

Post by Karel Zak
way to the future, both on the desktop and on embedded envs as

well.

Post by Lennart Poettering

Post by Jeff Garzik

Post by Karel Zak
The "obsolete technology" -- who made this decision? Is it your

private

Post by Lennart Poettering

Post by Jeff Garzik

Post by Karel Zak
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

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?

Post by Jeff Garzik
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.

[Adam Williamson]

Post by Dr. Diesel
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.

[Jeff Garzik]

Post by Adam Williamson

Post by Dr. Diesel
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.

$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

[Bastien Nocera]

Post by Jeff Garzik

Post by Adam Williamson

Post by Dr. Diesel
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.

$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...

[Nicolas Mailhot]

Post by Bastien Nocera

Post by Jeff Garzik
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.

[Lennart Poettering]

Post by Nicolas Mailhot

Post by Bastien Nocera

Post by Jeff Garzik
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

[Nicolas Mailhot]

Post by Lennart Poettering

Post by Nicolas Mailhot

Post by Bastien Nocera

Post by Jeff Garzik
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

[drago01]

On Wed, Jul 29, 2009 at 8:56 PM, Nicolas

Post by Nicolas Mailhot

Post by Lennart Poettering

Post by Nicolas Mailhot

Post by Bastien Nocera

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.

[Rodd Clarkson]

Post by Nicolas Mailhot

Post by Bastien Nocera

Post by Jeff Garzik
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.

[Nicolas Mailhot]

Post by Rodd Clarkson

Post by Nicolas Mailhot

Post by Bastien Nocera

Post by Jeff Garzik
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

Post by Rodd Clarkson
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Ceci est une partie de message
=?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20090801/5d8f04d7/attachment.bin

[Adam Williamson]

Post by Jeff Garzik

Post by Adam Williamson
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?

[Dr. Diesel]

Post by Adam Williamson

Post by Jeff Garzik

Post by Adam Williamson
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?

[Adam Williamson]

Post by Dr. Diesel
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...

[Rodd Clarkson]

Post by Adam Williamson
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.

[Orcan Ogetbil]

Post by Adam Williamson

Post by Adam Williamson
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

[Ralf Ertzinger]

Hi.

Post by Dominik 'Rathann' Mierzejewski
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.

[Dominik 'Rathann' Mierzejewski]

Hi,

Post by Ralf Ertzinger

Post by Dominik 'Rathann' Mierzejewski
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.

Post by Ralf Ertzinger
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.

[Jeff Garzik]

Post by Lennart Poettering

Post by Jeff Garzik

Post by Karel Zak

Post by Lennart Poettering
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.

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

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

[Dr. Diesel]

Post by Karel Zak

Post by Jeff Garzik

Post by Karel Zak

Post by Lennart Poettering
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.

https://tango.0pointer.de/pipermail/pulseaudio-discuss/2009-July/004519.html

Post by Jeff Garzik

Post by Karel Zak
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

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?

Post by Jeff Garzik
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

[Michal Schmidt]

On Wed, Jul 29, 2009 at 9:24 AM, Lennart Poettering

Post by Lennart Poettering

Post by Jeff Garzik
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.

[Doug Ledford]

Post by Jeff Garzik

Post by Karel Zak

Post by Lennart Poettering
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.

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
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 at redhat.com>

GPG KeyID: CFBFF194
http://people.redhat.com/dledford

InfiniBand Specific RPMS
http://people.redhat.com/dledford/Infiniband




-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 203 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20090730/30f814ab/attachment.bin

[Colin Walters]

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.

[Doug Ledford]

Post by Colin Walters

Post by Doug Ledford
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.

Post by Colin Walters

Post by Doug Ledford
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.

Post by Colin Walters

Post by Doug Ledford
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 at redhat.com>

GPG KeyID: CFBFF194
http://people.redhat.com/dledford

InfiniBand Specific RPMS
http://people.redhat.com/dledford/Infiniband




-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 203 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20090730/50c0c5c0/attachment.bin

[Matthew Garrett]

Post by Doug Ledford
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.

[Lennart Poettering]

Post by Karel Zak

Post by Lennart Poettering

Post by Bill Nottingham

Post by Lennart Poettering
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.

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.

Post by Karel Zak
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%20Windows%20Vista%E2%84%A2.aspx

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

[Adam Williamson]

Post by Lennart Poettering
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?

[Matthew Woehlke]

Post by Lennart Poettering
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.)

[Lennart Poettering]

Post by Matthew Woehlke

Post by Lennart Poettering
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

[Matthew Woehlke]

Please do not quote my e-mail address unobfuscated in message bodies.

Post by Lennart Poettering

Post by Matthew Woehlke

Post by Lennart Poettering
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.)

[Frank Ch. Eigler]

Post by Matthew Woehlke
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

[Ben Boeckel]

Post by Frank Ch. Eigler

Post by Matthew Woehlke
Please do not quote my e-mail address unobfuscated in message

bodies.

Post by Frank Ch. Eigler
Why on earth not? Your email address is in plain sight in the

headers.

Post by Frank Ch. Eigler
- FChE

Plus sf.net addresses get spammed just for existing.

- --Ben

[Michael Schwendt]

Post by Matthew Woehlke
Please do not quote my e-mail address unobfuscated in message bodies.

Post by Lennart Poettering

Post by Matthew Woehlke

Post by Lennart Poettering
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.

[Adam Williamson]

Post by Lennart Poettering
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.

[Felix Kaechele]

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

[Paul Jakma]

Post by Lennart Poettering
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,

[Thomas Janssen]

2009/7/28 Lennart Poettering <mzerqung at 0pointer.de>:

<snip>

Post by Lennart Poettering
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.

[Rodd Clarkson]

Post by Thomas Janssen

Post by Lennart Poettering
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.