[arch-general] Pulseaudio disabling auto-mute mode
I'm not sure how/why (or when it started) but pulseaudio is disabling auto-mute mode on my laptop. Normally when you plug in headphones, speakers get muted. However, every time PA starts up, it disables that auto-mute feature. (I then have to go into alsamixer and manually re-enable it.) Not a huge issue, but definitely a nuisance. It's definitely PA that's responsible: if I enable auto-mute, then do "pulseaudio --kill", the setting immediately gets disabled. I've followed the instructions at https://wiki.archlinux.org/index.php/PulseAudio/Troubleshooting#Auto-Mute_Mode and https://wiki.archlinux.org/index.php/Advanced_Linux_Sound_Architecture#Disabling_auto_mute_on_startup - i.e., change the setting to enabled, and then alsactl store. However, that's obviously having no impact, since pulseaudio later *overrides* the alsa setting when it starts up. Anyone else having similar issue? Or have any idea what the issue is / how to fix? (Or link to an open bug report?) Thanks, DR
[arch-general] pulseaudio
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 How to deny to touch mixer setings? - -- Have a nice day! ~~~ This PGP signature only certifies the sender and date of the message. It implies no approval from the administrators of nym.mixmin.net. Date: Mon Jan 11 11:39:41 2016 GMT From: f...@nym.mixmin.net -BEGIN PGP SIGNATURE- Version: GnuPG v1 iEYEARECAAYFAlaTlH0ACgkQViYZwngkfDvf1ACgiEOSVhxqjEShptEyA3z2oB/2 o6kAnjWdmNU4KNV4wizGh9UOG5AmkPNZ =V7b1 -END PGP SIGNATURE-
Re: [arch-general] pulseaudio, systemd --user and session problems
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 10/21/2015 05:57 AM, Karsten Rode wrote: > Hi, > > I have a problem I think is related to the startup of a systemd > user session. I noticed lately that pulseaudio does not > automatically start, although I can start it form the command line > later with > > $ pulseaudio --start > > After digging around I found that pulseaudio should be started by > the systemd user session, so as a first test I did > > $ systemctl --user > > which gave > > Failed to list units: Process org.freedesktop.systemd1 exited with > status 1 > > From what I recall, there are some conditions that has to be met > in order for user sessions to work, and the output of > > $ loginctl show-session $XDG_SESSION_ID > > contains (among other things): Remote=no Service=lightdm > Desktop=xfce Scope=session-c2.scope Leader=1118 Audit=0 Type=x11 > Class=user Active=yes > > Does anybody have an idea of where o look for further information ? > As you can see above I use lightdm as the display manager. > I think the wiki page should get you going. https://wiki.archlinux.org/index.php/Systemd/User -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJWJ559AAoJEJHJh+RMQi5CYDYP/AvO1iVfRwSxJw5uIGkM5b+2 VEBOy7xywOvTfvmSmJwooskUIR1iivhgkd3e0GFSiQawlHVJj2YW4qtoAuwo1HKC Rq8B+8Yan6jeTrPdrwSOsju2w82K9Wv1Kifd1n7icOahlhq3mWVOdvkF/QpucNZc UjiRZ2+8h/qkHpUPDE6QXF0QSt+j2YqdhJzm5SfJ5E8mbnz8oCtdp8ei0Oq/iwpK 9mpUCxBZx3PZs5F+czJxbPJJUkZUDEC7//OKSaDuG1GDmACuga4VHVZc/HSGZCQa mMERjZIPwpiTCOqgGRHaWTnl/AxQ/HW7I1v3hw7l6ItsVezQoErceCsFkmOmcXjI rhJQjZEwckGugngOjR+rpb/z7DZwYzoXpDs8j8YALOzCzvfe6bpcj+tyGPCuofja ND1aSI+qj299tUlVsZnJhwC8/lfeO/+KyL/qMm/v70b13nockEeKNtCDeDjr12Xr SPbS8BshMgOA6AdPmMsAXqz/qlzBACuv3FgTD2TMGgjfAqXXe6QoV0katXLF7orI tRYEJC3gucVJewiGgKmfT1wrEG89EEjJ5H0IthZlUNPHIcxWfleluTpOidgL+p0L BOFp8Pv9RsD6qFEiwedBtrv6HEV6OHbVnvCPkuj0HL6SWIe+zpMyaHiSjHKQfcCk rcLD1reb0mTtWJgMMman =ZVos -END PGP SIGNATURE-
Re: [arch-general] pulseaudio, systemd --user and session problems
On 21 October 2015 at 14:57, Karsten Rode wrote: > Hi, > > I have a problem I think is related to the startup of a systemd user > session. I noticed lately that pulseaudio does not automatically start, > although I can start it form the command line later with > > $ pulseaudio --start > > After digging around I found that pulseaudio should be started by the > systemd user session, > [...] > > Unless this changed, pulseaudio is started automatically by libpulse when a client needs the daemon. This can be controlled by the autospawn option in /etc/pulse/client.conf or ~/.config/pulse/client.conf (see man pulse-client.conf). You could disable autospawn there (even if it seems to be broken already) and use systemd user sessions. For that you would have to enable either the pulseaudio.service or pulseaudio.socket unit in your user session (systemctl --user enable ). Either way, normally it should just work without systemd user sessions. So if you didn't change the autospawn setting something seems to be broken. Keep in mind that libpulse also delays starting the daemon until someone tries to use it. So maybe you're just observing this. -- Maarten
[arch-general] pulseaudio, systemd --user and session problems
Hi, I have a problem I think is related to the startup of a systemd user session. I noticed lately that pulseaudio does not automatically start, although I can start it form the command line later with $ pulseaudio --start After digging around I found that pulseaudio should be started by the systemd user session, so as a first test I did $ systemctl --user which gave Failed to list units: Process org.freedesktop.systemd1 exited with status 1 From what I recall, there are some conditions that has to be met in order for user sessions to work, and the output of $ loginctl show-session $XDG_SESSION_ID contains (among other things): Remote=no Service=lightdm Desktop=xfce Scope=session-c2.scope Leader=1118 Audit=0 Type=x11 Class=user Active=yes Does anybody have an idea of where o look for further information ? As you can see above I use lightdm as the display manager. -- Karsten signature.asc Description: PGP signature
[arch-general] pulseaudio 6.99 in [testing], daemon can't start, chokes on module-native-protocol-unix
Anyone else seeing this? My default.pa is stock (it wasn't before, but I reverted the minor changes and no change in behaviour), and the daemon just won't start. If I comment out module-native-protocol-unix it will, but of course it's not usable that way. Reported it as a bug on freedesktop[1], but I'd be surprised if its actually a bug given how I'd assume I'm not the only [testing] user using this... any ideas? [1] - https://bugs.freedesktop.org/show_bug.cgi?id=92061
Re: [arch-general] Pulseaudio 5.1 Setup echoes Front Speakers to Rear speakers
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 03/18/2014 04:49 AM, Rodrigo Rivas wrote: > On Tue, Mar 18, 2014 at 2:34 AM, Mark Lee > wrote: >> -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 >> >> On 03/17/2014 07:54 PM, Adriano Moura wrote: >>> Does the same happens with speaker-test? (included in >>> alsa-utils) Try running it like this: speaker-test -c 6 > > Try with "speaker-test -c 6 -D hw:0" to test with the alsa driver. > The default device is "default" and it is most likely the > PulseAudio driver. > > Naturally, if you had more than one sound card you might need > "hw:1" or "hw:2" or whatever... > > If this command still does echo, then probably it is an > ALSA/hardware issue. If this command does not echo, then all points > to a PulseAudio issue. > > -- Rodrigo > Salutations, Interestingly when I set the speakers to stereo, I am still getting the echoing of sound content from the front speakers to the rear speakers. Regards, Mark -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlMoQ4kACgkQZ/Z80n6+J/ZB+AEAidgIEEX040aU0YnuUTz+gvcA oPW+cy9I9muNT7mYDLUA/3mQnHGRJI7fn7Br+voP3o1uH9pKD80jKtrSN0obUBVD =foR3 -END PGP SIGNATURE-
Re: [arch-general] Pulseaudio 5.1 Setup echoes Front Speakers to Rear speakers
On Tue, Mar 18, 2014 at 2:34 AM, Mark Lee wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > On 03/17/2014 07:54 PM, Adriano Moura wrote: >> Does the same happens with speaker-test? (included in alsa-utils) >> Try running it like this: >> speaker-test -c 6 Try with "speaker-test -c 6 -D hw:0" to test with the alsa driver. The default device is "default" and it is most likely the PulseAudio driver. Naturally, if you had more than one sound card you might need "hw:1" or "hw:2" or whatever... If this command still does echo, then probably it is an ALSA/hardware issue. If this command does not echo, then all points to a PulseAudio issue. -- Rodrigo
Re: [arch-general] Pulseaudio 5.1 Setup echoes Front Speakers to Rear speakers
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 03/17/2014 07:54 PM, Adriano Moura wrote: > Does the same happens with speaker-test? (included in alsa-utils) > Try running it like this: > speaker-test -c 6 > > > 2014-03-17 2:40 GMT-03:00 Kyle Terrien : > >> On 03/16/2014 10:21 PM, Kyle Terrien wrote: >>> Are you using PulseAudio? >> >> D'oh! I noticed the subject line said "Pulseaudio" right after sending >> my message. Sorry for the stupid question. >> >> --Kyle >> >> Salutations, I tried "$ speaker-test -c 6" and received the same result (echoing of front speakers to rear speakers). Pavucontrol doesn't seem to have any extra configuration options to correct the issue. Regards, Mark -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlMnor4ACgkQZ/Z80n6+J/ZHpQD9Hxhm0fMlrgaNY1llRAWvoFbu fUlLuNsas4RqKXeIfG0A/0XcDyE2HrrmSuAC6H6Nz2utlIB5XbmhwbuqpkRRkyJj =wwrA -END PGP SIGNATURE-
Re: [arch-general] Pulseaudio 5.1 Setup echoes Front Speakers to Rear speakers
Does the same happens with speaker-test? (included in alsa-utils) Try running it like this: speaker-test -c 6 2014-03-17 2:40 GMT-03:00 Kyle Terrien : > On 03/16/2014 10:21 PM, Kyle Terrien wrote: > > Are you using PulseAudio? > > D'oh! I noticed the subject line said "Pulseaudio" right after sending > my message. Sorry for the stupid question. > > --Kyle > >
Re: [arch-general] Pulseaudio 5.1 Setup echoes Front Speakers to Rear speakers
On 03/16/2014 10:21 PM, Kyle Terrien wrote: > Are you using PulseAudio? D'oh! I noticed the subject line said "Pulseaudio" right after sending my message. Sorry for the stupid question. --Kyle signature.asc Description: OpenPGP digital signature
Re: [arch-general] Pulseaudio 5.1 Setup echoes Front Speakers to Rear speakers
On 03/16/2014 09:59 PM, Mark Lee wrote: > Salutations, > > I recently hooked up a 5.1 surround sound receiver to my Haswell setup > via HDMI. I used the sound manager in gnome to set the system to output > 5.1 surround sound. However, while testing each individual speaker using > the gnome sound settings, I found that front speakers were echoing > content to rear speakers (with a small delay). I also noticed that if I > set the fade to rear, I would lose all front speaker output. Moving the > fade to the front reproduced the echo again. This is noticeable in any > 5.1 audio I play as well. Has anyone experienced this and found a solution? > > Regards, > Mark > Are you using PulseAudio? If so, try looking at the sound settings with pavucontrol, the official PulseAudio configuration utility (in the package extra/pavucontrol). Correct me if I'm wrong, but if I remember correctly, the Gnome sound manager and pavucontrol are different programs. In my experience, I have had the best luck using pavucontrol to configure sound. --Kyle signature.asc Description: OpenPGP digital signature
[arch-general] Pulseaudio 5.1 Setup echoes Front Speakers to Rear speakers
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Salutations, I recently hooked up a 5.1 surround sound receiver to my Haswell setup via HDMI. I used the sound manager in gnome to set the system to output 5.1 surround sound. However, while testing each individual speaker using the gnome sound settings, I found that front speakers were echoing content to rear speakers (with a small delay). I also noticed that if I set the fade to rear, I would lose all front speaker output. Moving the fade to the front reproduced the echo again. This is noticeable in any 5.1 audio I play as well. Has anyone experienced this and found a solution? Regards, Mark -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlMmgTsACgkQZ/Z80n6+J/a4oQD/SmOzZZJ9hlu1o6z1TV62gGqc TVRZrVu2yMBnQb3l5XUA/AznszmgsTjGd7Kq01LvwjzGCCsgkZNDYoz2UXLrZyWT =ekbP -END PGP SIGNATURE-
Re: [arch-general] Pulseaudio update - mpd now refuses to play as same user
On 19.11.2012 08:08, Jan Steffens wrote: > On Mon, Nov 19, 2012 at 7:50 AM, Oon-Ee Ng wrote: >> Hi, Pulseaudio from [testing] just updated to 2.99.2-1, now mpd audio >> output (running mpd as my own user) fails with the following:- >> >> Nov 19 14:45 : output: Failed to enable "MPD Pulse Output" [pulse]: >> pa_context_connect() has failed: Connection refused >> Nov 19 14:45 : player_thread: problems opening audio device while playing >> "PointBreak-StandTough.mp3" >> >> Setting up pulseaudio to listen on TCP locally as in the wiki works, but I >> never needed to do that before. Can anyone else verify this? Is it perhaps >> logind related (worked fine before this last pulseaudio update)? > > You're running mpd from systemd? I believe it's because PulseAudio now > uses $XDG_RUNTIME_DIR/pulse instead of /tmp/pulse-XX, > $XDG_CONFIG_HOME/pulse instead of $HOME/.pulse, and > $XDG_CONFIG_HOME/pulse/cookie instead of $HOME/.pulse-cookie. > > mpd has no session, so these variables are not set, unlike the session > you login to. > > This should be sent upstream (bugs.freedesktop.org). > I've asked in #pulseaudio and you can use PULSE_RUNTIME_PATH to override XDG_RUNTIME_DIR, but I'm not sure how this could be fixed in our package. XDG_RUNTIME_DIR is supposed to be removed if the user logs out so you shouldn't put the pulse socket there if you want mpd to use it. -- Florian Pritz signature.asc Description: OpenPGP digital signature
Re: [arch-general] Pulseaudio update - mpd now refuses to play as same user
On Tue, 20 Nov 2012, Zeke Sulastin wrote: > > > > Earlier I couldn't get pulseaudio to stop blocking my audio for vlc and > > mplayer until I fixed this group membership problem. > > > If you're logging in with systemd, your user should definitely not be in > the 'audio' group and vlc/mplayer should be very much able to connect to > Pulse unless you have them running as their own user. How are you starting > X? > > I'm not starting x, I run command line only. --- jude Adobe fiend for failing to Flash
Re: [arch-general] Pulseaudio update - mpd now refuses to play as same user
On Mon, 2012-11-19 at 22:45 -0500, Jude DaShiell wrote: > Is > the > user > that's > supposed > to > be > able > to > use > mpd > in > the > audio > group? > > If > not, > it > may > help > to > add > the > user > to > audio. > > Earlier I couldn't get pulseaudio to stop blocking my audio for vlc and > mplayer until I fixed this group membership problem. The link in the original mail does provide a link that says: "Don’t add your user to the “audio” group" - http://voices.canonical.com/david.henningsson/ Regards, Ralf
Re: [arch-general] Pulseaudio update - mpd now refuses to play as same user
> > Earlier I couldn't get pulseaudio to stop blocking my audio for vlc and > mplayer until I fixed this group membership problem. If you're logging in with systemd, your user should definitely not be in the 'audio' group and vlc/mplayer should be very much able to connect to Pulse unless you have them running as their own user. How are you starting X?
Re: [arch-general] Pulseaudio update - mpd now refuses to play as same user
Hi, * On Tue, Nov 20, 2012 at 07:41:52AM +0800, Oon-Ee Ng wrote: On Mon, Nov 19, 2012 at 5:53 PM, Tom Gundersen wrote: On Nov 19, 2012 10:27 AM, "Oon-Ee Ng" wrote: > > On Mon, Nov 19, 2012 at 3:08 PM, Jan Steffens wrote: > > > On Mon, Nov 19, 2012 at 7:50 AM, Oon-Ee Ng wrote: > > > Hi, Pulseaudio from [testing] just updated to 2.99.2-1, now mpd audio > > > output (running mpd as my own user) fails with the following:- > > > > > > Nov 19 14:45 : output: Failed to enable "MPD Pulse Output" [pulse]: > > > pa_context_connect() has failed: Connection refused > > > Nov 19 14:45 : player_thread: problems opening audio device while playing > > > "PointBreak-StandTough.mp3" > > > > > > Setting up pulseaudio to listen on TCP locally as in the wiki works, but > > I > > > never needed to do that before. Can anyone else verify this? Is it > > perhaps > > > logind related (worked fine before this last pulseaudio update)? > > > > You're running mpd from systemd? I believe it's because PulseAudio now > > uses $XDG_RUNTIME_DIR/pulse instead of /tmp/pulse-XX, > > $XDG_CONFIG_HOME/pulse instead of $HOME/.pulse, and > > $XDG_CONFIG_HOME/pulse/cookie instead of $HOME/.pulse-cookie. > > > > mpd has no session, so these variables are not set, unlike the session > > you login to. > > > > This should be sent upstream (bugs.freedesktop.org). > > > > Hi Jan, thanks for the reply. Sorry for the slightly clueless follow-up, > but it's unclear to me whether 'upstream' here refers to pulseaudio, > systemd, or mpd. Or even whether its actually wrong behaviour. > > My understanding of your explanation is that there's no clear > responsibility. mpd does not use (or require) a session, the locations > pulse uses are fairly standard (I've always hated apps using ~/.foo)... This was recently discussed: http://arunraghavan.net/2012/11/pulseconf-2012-report/ Does not look like anything has come of it yet. I guess it might make sense to ask advice from the PA guys though, they would hopefully have an idea. Tom Thanks Tom, I'll ask on their ML. Thanks for the investigation. The only change I needed to do was add "/run/user/1000/pulse/native" (obtained from pactl info | grep 'Server String'). I believe it may be because mpd was connecting or trying to connect to different server (I also noticed "shm_unlink(/pulse-shm-2228832221) failed: No such file or directory" in the logs and thought something wrong with auto-detection of mpd). Regards, -- Raghavendra Prabhu GPG Id : 0xD72BE977 Fingerprint: B93F EBCB 8E05 7039 CD3C A4B8 A616 DCA1 D72B E977 www: wnohang.net pgpQoxAZwtPD0.pgp Description: PGP signature
Re: [arch-general] Pulseaudio update - mpd now refuses to play as same user
On Tue, 20 Nov 2012, Oon-Ee Ng wrote: > On Mon, Nov 19, 2012 at 5:53 PM, Tom Gundersen wrote: > > > On Nov 19, 2012 10:27 AM, "Oon-Ee Ng" wrote: > > > > > > On Mon, Nov 19, 2012 at 3:08 PM, Jan Steffens > >wrote: > > > > > > > On Mon, Nov 19, 2012 at 7:50 AM, Oon-Ee Ng > > wrote: > > > > > Hi, Pulseaudio from [testing] just updated to 2.99.2-1, now mpd audio > > > > > output (running mpd as my own user) fails with the following:- > > > > > > > > > > Nov 19 14:45 : output: Failed to enable "MPD Pulse Output" [pulse]: > > > > > pa_context_connect() has failed: Connection refused > > > > > Nov 19 14:45 : player_thread: problems opening audio device while > > playing > > > > > "PointBreak-StandTough.mp3" > > > > > > > > > > Setting up pulseaudio to listen on TCP locally as in the wiki works, > > but > > > > I > > > > > never needed to do that before. Can anyone else verify this? Is it > > > > perhaps > > > > > logind related (worked fine before this last pulseaudio update)? > > > > > > > > You're running mpd from systemd? I believe it's because PulseAudio now > > > > uses $XDG_RUNTIME_DIR/pulse instead of /tmp/pulse-XX, > > > > $XDG_CONFIG_HOME/pulse instead of $HOME/.pulse, and > > > > $XDG_CONFIG_HOME/pulse/cookie instead of $HOME/.pulse-cookie. > > > > > > > > mpd has no session, so these variables are not set, unlike the session > > > > you login to. > > > > > > > > This should be sent upstream (bugs.freedesktop.org). > > > > > > > > > > Hi Jan, thanks for the reply. Sorry for the slightly clueless follow-up, > > > but it's unclear to me whether 'upstream' here refers to pulseaudio, > > > systemd, or mpd. Or even whether its actually wrong behaviour. > > > > > > My understanding of your explanation is that there's no clear > > > responsibility. mpd does not use (or require) a session, the locations > > > pulse uses are fairly standard (I've always hated apps using ~/.foo)... > > > > This was recently discussed: > > http://arunraghavan.net/2012/11/pulseconf-2012-report/ > > > > Does not look like anything has come of it yet. I guess it might make sense > > to ask advice from the PA guys though, they would hopefully have an idea. > > > > Tom > > > > Thanks Tom, I'll ask on their ML. > > Is the user that's supposed to be able to use mpd in the audio group? If not, it may help to add the user to audio. Earlier I couldn't get pulseaudio to stop blocking my audio for vlc and mplayer until I fixed this group membership problem. --- jude Adobe fiend for failing to Flash
Re: [arch-general] Pulseaudio update - mpd now refuses to play as same user
On Mon, Nov 19, 2012 at 5:53 PM, Tom Gundersen wrote: > On Nov 19, 2012 10:27 AM, "Oon-Ee Ng" wrote: > > > > On Mon, Nov 19, 2012 at 3:08 PM, Jan Steffens >wrote: > > > > > On Mon, Nov 19, 2012 at 7:50 AM, Oon-Ee Ng > wrote: > > > > Hi, Pulseaudio from [testing] just updated to 2.99.2-1, now mpd audio > > > > output (running mpd as my own user) fails with the following:- > > > > > > > > Nov 19 14:45 : output: Failed to enable "MPD Pulse Output" [pulse]: > > > > pa_context_connect() has failed: Connection refused > > > > Nov 19 14:45 : player_thread: problems opening audio device while > playing > > > > "PointBreak-StandTough.mp3" > > > > > > > > Setting up pulseaudio to listen on TCP locally as in the wiki works, > but > > > I > > > > never needed to do that before. Can anyone else verify this? Is it > > > perhaps > > > > logind related (worked fine before this last pulseaudio update)? > > > > > > You're running mpd from systemd? I believe it's because PulseAudio now > > > uses $XDG_RUNTIME_DIR/pulse instead of /tmp/pulse-XX, > > > $XDG_CONFIG_HOME/pulse instead of $HOME/.pulse, and > > > $XDG_CONFIG_HOME/pulse/cookie instead of $HOME/.pulse-cookie. > > > > > > mpd has no session, so these variables are not set, unlike the session > > > you login to. > > > > > > This should be sent upstream (bugs.freedesktop.org). > > > > > > > Hi Jan, thanks for the reply. Sorry for the slightly clueless follow-up, > > but it's unclear to me whether 'upstream' here refers to pulseaudio, > > systemd, or mpd. Or even whether its actually wrong behaviour. > > > > My understanding of your explanation is that there's no clear > > responsibility. mpd does not use (or require) a session, the locations > > pulse uses are fairly standard (I've always hated apps using ~/.foo)... > > This was recently discussed: > http://arunraghavan.net/2012/11/pulseconf-2012-report/ > > Does not look like anything has come of it yet. I guess it might make sense > to ask advice from the PA guys though, they would hopefully have an idea. > > Tom > Thanks Tom, I'll ask on their ML.
Re: [arch-general] Pulseaudio update - mpd now refuses to play as same user
On Nov 19, 2012 10:27 AM, "Oon-Ee Ng" wrote: > > On Mon, Nov 19, 2012 at 3:08 PM, Jan Steffens wrote: > > > On Mon, Nov 19, 2012 at 7:50 AM, Oon-Ee Ng wrote: > > > Hi, Pulseaudio from [testing] just updated to 2.99.2-1, now mpd audio > > > output (running mpd as my own user) fails with the following:- > > > > > > Nov 19 14:45 : output: Failed to enable "MPD Pulse Output" [pulse]: > > > pa_context_connect() has failed: Connection refused > > > Nov 19 14:45 : player_thread: problems opening audio device while playing > > > "PointBreak-StandTough.mp3" > > > > > > Setting up pulseaudio to listen on TCP locally as in the wiki works, but > > I > > > never needed to do that before. Can anyone else verify this? Is it > > perhaps > > > logind related (worked fine before this last pulseaudio update)? > > > > You're running mpd from systemd? I believe it's because PulseAudio now > > uses $XDG_RUNTIME_DIR/pulse instead of /tmp/pulse-XX, > > $XDG_CONFIG_HOME/pulse instead of $HOME/.pulse, and > > $XDG_CONFIG_HOME/pulse/cookie instead of $HOME/.pulse-cookie. > > > > mpd has no session, so these variables are not set, unlike the session > > you login to. > > > > This should be sent upstream (bugs.freedesktop.org). > > > > Hi Jan, thanks for the reply. Sorry for the slightly clueless follow-up, > but it's unclear to me whether 'upstream' here refers to pulseaudio, > systemd, or mpd. Or even whether its actually wrong behaviour. > > My understanding of your explanation is that there's no clear > responsibility. mpd does not use (or require) a session, the locations > pulse uses are fairly standard (I've always hated apps using ~/.foo)... This was recently discussed: http://arunraghavan.net/2012/11/pulseconf-2012-report/ Does not look like anything has come of it yet. I guess it might make sense to ask advice from the PA guys though, they would hopefully have an idea. Tom
Re: [arch-general] Pulseaudio update - mpd now refuses to play as same user
On Mon, Nov 19, 2012 at 3:08 PM, Jan Steffens wrote: > On Mon, Nov 19, 2012 at 7:50 AM, Oon-Ee Ng wrote: > > Hi, Pulseaudio from [testing] just updated to 2.99.2-1, now mpd audio > > output (running mpd as my own user) fails with the following:- > > > > Nov 19 14:45 : output: Failed to enable "MPD Pulse Output" [pulse]: > > pa_context_connect() has failed: Connection refused > > Nov 19 14:45 : player_thread: problems opening audio device while playing > > "PointBreak-StandTough.mp3" > > > > Setting up pulseaudio to listen on TCP locally as in the wiki works, but > I > > never needed to do that before. Can anyone else verify this? Is it > perhaps > > logind related (worked fine before this last pulseaudio update)? > > You're running mpd from systemd? I believe it's because PulseAudio now > uses $XDG_RUNTIME_DIR/pulse instead of /tmp/pulse-XX, > $XDG_CONFIG_HOME/pulse instead of $HOME/.pulse, and > $XDG_CONFIG_HOME/pulse/cookie instead of $HOME/.pulse-cookie. > > mpd has no session, so these variables are not set, unlike the session > you login to. > > This should be sent upstream (bugs.freedesktop.org). > Hi Jan, thanks for the reply. Sorry for the slightly clueless follow-up, but it's unclear to me whether 'upstream' here refers to pulseaudio, systemd, or mpd. Or even whether its actually wrong behaviour. My understanding of your explanation is that there's no clear responsibility. mpd does not use (or require) a session, the locations pulse uses are fairly standard (I've always hated apps using ~/.foo)...
Re: [arch-general] Pulseaudio update - mpd now refuses to play as same user
On Mon, Nov 19, 2012 at 7:50 AM, Oon-Ee Ng wrote: > Hi, Pulseaudio from [testing] just updated to 2.99.2-1, now mpd audio > output (running mpd as my own user) fails with the following:- > > Nov 19 14:45 : output: Failed to enable "MPD Pulse Output" [pulse]: > pa_context_connect() has failed: Connection refused > Nov 19 14:45 : player_thread: problems opening audio device while playing > "PointBreak-StandTough.mp3" > > Setting up pulseaudio to listen on TCP locally as in the wiki works, but I > never needed to do that before. Can anyone else verify this? Is it perhaps > logind related (worked fine before this last pulseaudio update)? You're running mpd from systemd? I believe it's because PulseAudio now uses $XDG_RUNTIME_DIR/pulse instead of /tmp/pulse-XX, $XDG_CONFIG_HOME/pulse instead of $HOME/.pulse, and $XDG_CONFIG_HOME/pulse/cookie instead of $HOME/.pulse-cookie. mpd has no session, so these variables are not set, unlike the session you login to. This should be sent upstream (bugs.freedesktop.org).
[arch-general] Pulseaudio update - mpd now refuses to play as same user
Hi, Pulseaudio from [testing] just updated to 2.99.2-1, now mpd audio output (running mpd as my own user) fails with the following:- Nov 19 14:45 : output: Failed to enable "MPD Pulse Output" [pulse]: pa_context_connect() has failed: Connection refused Nov 19 14:45 : player_thread: problems opening audio device while playing "PointBreak-StandTough.mp3" Setting up pulseaudio to listen on TCP locally as in the wiki works, but I never needed to do that before. Can anyone else verify this? Is it perhaps logind related (worked fine before this last pulseaudio update)?
Re: [arch-general] PulseAudio again (was: change in mount behaviour?)
On Sat, 2012-01-28 at 20:25 +, Fons Adriaensen wrote: > On Sat, Jan 28, 2012 at 01:14:47PM -0600, Leonid Isaev wrote: > > > PA is a great consumer thing, and that's exactly what we need. > > PA is indeed a great consumer thing, and it may be what > you need. It is definitely not what some others need. > > > Because noone cares about "pro" audio solutions > > You mean _you_ don't. > > > which are a nightmare to configure. > > Very strange that you claim to have some knowledge on > something you don't care about. Which 'pro' audio HW > have you actually used ? On what experience is is your > 'nightmare to configure' comment based ? > > Having used a significant percentage of what is available, > and earning my daily pizza by providing services and > consultancy mostly based on Linux audio using 'pro' HW, > I can only say that your comment is pure nonsense. I need to chime in here. (Hard to shut up) After some conversation off list I agree that a dummy package provided by the repositories might be a less good idea. But I noticed some lacks of knowhow. E.g. it's not a problem for a classic Jack only. Cards as the Envy24 ones (the OP already tried to explain this) or the RME (Fons already mentioned it) already don't work with PA. So if even software like GDM depends to PA (it might be a dependency of a dependency), it's ridiculous. Of cause, it's possible to use another login manager, but someday too many apps might depend on PA, that don't need PA. The different "solutions" to turn off PA often don't work. "autospawn = no" might work for Arch Linux, but AFAIK some distros still kept disadvantages of PA when using this. Cheers, Ralf
Re: [arch-general] PulseAudio again (was: change in mount behaviour?)
Am Sat, 28 Jan 2012 12:37:14 -0600 schrieb C Anthony Risinger : > is this roughly message you want to send? No, this is not the message, and I guess you totally misunderstood me. The problem is that PulseAudio is not working with every sound and audio card, but users are forced to install it as a dependency by some distros and/or DEs, even if it doesn't support several audio cards. And the problem is that this leads to being called PulseAudio as a standard even if it doesn't support a lot of sound and audio cards, so that sound probably wouldn't work with those cards some day. And the problem is upstream's reaction on bug reports about this, that they say something like "it's ALSA's fault that our software doesn't work with your audio card" even if ALSA supports these card perfectly out-of-the-box, etc. So to me it just sounds like "We want our software to be a standard but we just don't care about hardware we don't understand, and we just ignore it." That are the problems. Like I said before, if PulseAudio was just another piece of software which I can install or not, I totally wouldn't care about it. But as soon as someone forces me to installing this, I do care. Well, I'm currently using Arch Linux and Xfce. So I'm not, yet, forced to install it. But I'd like to keep it this way. > i think if you read a bit more ... eg. man pages, documentation, > introductory blogs/etc, and not rants by random-equally-infuriated > users ... you may find some reason, and *maybe* even some use. ftw, > PA idles at 0% CPU for me, and when streaming over the network to an > XBMC sound system, it uses a steady average 1-2% (actually brief > intermittent bursts at 10% or so) ... nothing outrageous ...meanwhile, > FF consumes 3-5% to run flash, and flash consumes 8-10% to run Pandora > ... PA is the lightest link in the chain. I didn't say anything about PulseAudio's CPU usage. That was someone else. I just answered that 2% CPU usage at idle time would be too much. Actually I don't know how many resources it needs. Heiko
Re: [arch-general] PulseAudio again (was: change in mount behaviour?)
Am Sat, 28 Jan 2012 13:14:47 -0600 schrieb Leonid Isaev : > PA is a great consumer thing, and that's exactly what we need. That may be exactly what you need, but not what we need. Otherwise we all could stick with Windows. You can read your e-mails and write some letters with Windows. So why using Linux? > Because noone cares about "pro" audio solutions which are a nightmare > to configure. I don't need to configure anything to get my M-Audio Audiophile 24/96 to get running perfectly with ALSA. And all the pro audio software work without any configuration out-of-the-box with this card and ALSA. What's not working with this card is PulseAudio, and to get it working with PulseAudio somehow I need to cripple it down to stereo with a nightmare of configuration. Heiko
Re: [arch-general] PulseAudio again (was: change in mount behaviour?)
On Sat, Jan 28, 2012 at 01:14:47PM -0600, Leonid Isaev wrote: > PA is a great consumer thing, and that's exactly what we need. PA is indeed a great consumer thing, and it may be what you need. It is definitely not what some others need. > Because noone cares about "pro" audio solutions You mean _you_ don't. > which are a nightmare to configure. Very strange that you claim to have some knowledge on something you don't care about. Which 'pro' audio HW have you actually used ? On what experience is is your 'nightmare to configure' comment based ? Having used a significant percentage of what is available, and earning my daily pizza by providing services and consultancy mostly based on Linux audio using 'pro' HW, I can only say that your comment is pure nonsense. Ciao, -- FA Vor uns liegt ein weites Tal, die Sonne scheint - ein Glitzerstrahl.
Re: [arch-general] PulseAudio again (was: change in mount behaviour?)
On Sat, 28 Jan 2012 20:29:28 +0100 Ralf Mardorf wrote: > On Sat, 2012-01-28 at 13:14 -0600, Leonid Isaev wrote: > > Please please please not again!!! > > > > PA is a great consumer thing, and that's exactly what we need. Because > > noone cares about "pro" audio solutions which are a nightmare to configure. > > > > PA goes far beyond you KDE/gnome to embedded systems with android and > > webos. Having different volume controls for different ergimes is very > > handy there. > > The discussion would stop once and for all, if there would simply be a > dummy package available by the repositories of all the distros who make > PA a dependency. > This idea is plain ridiculous. Please stop embarassing yourself like this. > Neither the OP nor I have started this discussion on several other > lists, where it was a thread some days ago. All the time there are > averaged non-pro-audio users having trouble with PA. > > And now I shut up, > Ralf > > > -- Leonid Isaev GnuPG key ID: 164B5A6D Key fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D signature.asc Description: PGP signature
Re: [arch-general] PulseAudio again (was: change in mount behaviour?)
Thanks. On Sat, Jan 28, 2012 at 11:29 AM, Ralf Mardorf wrote: > On Sat, 2012-01-28 at 13:14 -0600, Leonid Isaev wrote: > > Please please please not again!!! > > > > PA is a great consumer thing, and that's exactly what we need. Because > noone > > cares about "pro" audio solutions which are a nightmare to configure. > > > > PA goes far beyond you KDE/gnome to embedded systems with android and > webos. > > Having different volume controls for different ergimes is very handy > there. > > The discussion would stop once and for all, if there would simply be a > dummy package available by the repositories of all the distros who make > PA a dependency. > > Neither the OP nor I have started this discussion on several other > lists, where it was a thread some days ago. All the time there are > averaged non-pro-audio users having trouble with PA. > > And now I shut up, > Ralf > > > >
Re: [arch-general] PulseAudio again (was: change in mount behaviour?)
On Sat, Jan 28, 2012 at 8:29 PM, Ralf Mardorf wrote: > On Sat, 2012-01-28 at 13:14 -0600, Leonid Isaev wrote: > > Please please please not again!!! > > > > PA is a great consumer thing, and that's exactly what we need. Because > noone > > cares about "pro" audio solutions which are a nightmare to configure. > > > > PA goes far beyond you KDE/gnome to embedded systems with android and > webos. > > Having different volume controls for different ergimes is very handy > there. > > The discussion would stop once and for all, if there would simply be a > dummy package available by the repositories of all the distros who make > PA a dependency. > If it's an upstream dependency , then a package depends on it. If you don't like PA. Then either stop using it or improve it, just don't spread this silly FUD and complains. Man up and take it to upstream. > Neither the OP nor I have started this discussion on several other > lists, where it was a thread some days ago. All the time there are > averaged non-pro-audio users having trouble with PA. > > As always "Patches welcome!" > And now I shut up, > Ralf > > > > -- Jelle van der Waa
Re: [arch-general] PulseAudio again (was: change in mount behaviour?)
On Sat, 2012-01-28 at 13:14 -0600, Leonid Isaev wrote: > Please please please not again!!! > > PA is a great consumer thing, and that's exactly what we need. Because noone > cares about "pro" audio solutions which are a nightmare to configure. > > PA goes far beyond you KDE/gnome to embedded systems with android and webos. > Having different volume controls for different ergimes is very handy there. The discussion would stop once and for all, if there would simply be a dummy package available by the repositories of all the distros who make PA a dependency. Neither the OP nor I have started this discussion on several other lists, where it was a thread some days ago. All the time there are averaged non-pro-audio users having trouble with PA. And now I shut up, Ralf
Re: [arch-general] PulseAudio again (was: change in mount behaviour?)
On Sat, 2012-01-28 at 12:37 -0600, C Anthony Risinger wrote:
> dear Lennart and co.,
>
> make sure that your software is 100% optional and free of dependencies
> in either direction.
>
> signed,
>
> Your Friends in the Community
Dear my Friends in the Community,
PA already is optional.
Please test what happens, if you replace it with a dummy package.
$ cat PKGBUILD
pkgname=pulseaudio-dummy
pkgver=1.0
pkgrel=1
pkgdesc="A dummy package that pretends to provide pulseaudio."
arch=('any')
url=""
license=('BSD')
provides=('pulseaudio')
conflicts=('pulseaudio')
source=()
Is anything broken for you, if you replace it by this package?
signed,
Oc Dna Trannel
Re: [arch-general] PulseAudio again (was: change in mount behaviour?)
On Sat, 28 Jan 2012 18:24:07 +0100 Heiko Baums wrote: > Am Sat, 28 Jan 2012 17:05:25 + > schrieb Fons Adriaensen : > > > PA is for 'consumer' use, its scope ends at ITU 5.1 or so. > > It doesn't support any serious multichannel card (like the > > the comlete RME series, up to 64+64 channels). Users of such > > cards don't need or want PA, so it's really not a problem at > > all. > > That's principally what I said. The problem is that several distros and > DEs like Gnome depend on PulseAudio as far as I know. This is > what I'm concerned about. Arch Linux and Xfce, what I'm using, > fortunately don't depend on it. > > If PulseAudio was generally only optional and if its developers > wouldn't try to declare it as a standard, I just wouldn't care. > > > If you use such cards you probably have Jack running, and > > if you really want PA you can configure it as a Jack client. > > I'm using an M-Audio Audiophile 24/96, so one of the cheapest > semi-professional audio cards of this kind. And I admit I primarily use > it for listening to music, watching videos etc. because of its sound > quality. > > But you're right I don't want and need PulseAudio. > > Heiko Please please please not again!!! PA is a great consumer thing, and that's exactly what we need. Because noone cares about "pro" audio solutions which are a nightmare to configure. PA goes far beyond you KDE/gnome to embedded systems with android and webos. Having different volume controls for different ergimes is very handy there. -- Leonid Isaev GnuPG key ID: 164B5A6D Key fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D signature.asc Description: PGP signature
Re: [arch-general] PulseAudio again (was: change in mount behaviour?)
On Sat, Jan 28, 2012 at 11:34 AM, Heiko Baums wrote: > > If Lennart would either fix all those issues in PulseAudio and systemd, > so that they would really work for everybody and would really bring > advantages for everybody or at least no disadvantages, or if his > software would just be optional and not needed as a dependency by some > distros or DEs, I'm pretty sure this discussion wouldn't always pop up > again. dear Lennart and co., the community would appreciate software that is 100% free of all bugs, now and forever. we expect these things to work with every card ever manufactured, even stuff 10yrs obsolete or in the 1% of use cases. and no, before you ask, just working is not good enough, please be sure that all possible features are exposed. also, ensure your software integrates perfectly with legacy systems and perfectly with future systems that haven't been thought of. lastly, after achieving completely awesome and 150% interoperability (must include future), make sure that your software is 100% optional and free of dependencies in either direction. seriously, if you can't hit this entry-level 3rd grade target, there is no hope of becoming a l33t linnicks developer, and you should right fuxxor off, guy. signed, Your Friends in the Community .. haha, i make myself laugh, that's all that really matters. is this roughly message you want to send? both PA and systemd already do a pretty good job coping with legacy stuff, in two areas that are *notorious* for their excessive proliferation ... you seem to have some basic misunderstandings of ALSA/alsa-lib/init ... you do know that init doesn't actually do *anything*, right? i reimplemented init in ~40 lines of bash years ago for LXC containers ... and it was full-featured, supporting all signals, and even inittab. that shiz was unfixable garbage imo. i think if you read a bit more ... eg. man pages, documentation, introductory blogs/etc, and not rants by random-equally-infuriated users ... you may find some reason, and *maybe* even some use. ftw, PA idles at 0% CPU for me, and when streaming over the network to an XBMC sound system, it uses a steady average 1-2% (actually brief intermittent bursts at 10% or so) ... nothing outrageous ...meanwhile, FF consumes 3-5% to run flash, and flash consumes 8-10% to run Pandora ... PA is the lightest link in the chain. ... and that's a wrap on this topic, for me that is. -- C Anthony
Re: [arch-general] PulseAudio again (was: change in mount behaviour?)
Am Sat, 28 Jan 2012 17:34:32 + schrieb Fons Adriaensen : > It's part of a more general trend, that of dependencies on > specific desktop junk trickling down into even basic system > components and plain apps. And that's a problem. This should be changed again. > And it's staring to affect Arch > as well, be it much less than some others. The Arch devs fortunately try to avoid this trend as good as possible. I hope they can keep it up. And I hope that other distros and upstream developers will rethink soon. Heiko
Re: [arch-general] PulseAudio again (was: change in mount behaviour?)
Am Sat, 28 Jan 2012 18:22:05 +0100 schrieb Stefan Wilkens : > Does this really need to be rehashed yet again? This isn't arch > related yet these PA back and forths keeps popping up in the mailboxes > of all the registered people looking for arch-related content. > > I didn't follow the original discussion so I cant argument on that > extent, but the last thing we need on this list is more noise. I guess there's a reason why this always pops up on several mailing lists. I would say it's just related to Lennart Poettering who has also developed systemd which was originally mentioned regarding the mount behaviour, and who thinks he needs to take part on the discussion about the FHS and thinks he needs to change every standard. And both tools shall be declared as a new Linux standard (that's at least my impression) even if both don't work very well, don't support every hardware or are just unnecessary (PulseAudio) or have issues regarding incompatibilities (systemd). That's the point and that's why you always will read PulseAudio in threads which are at least partly related to Lennart Poettering or his software. If Lennart would either fix all those issues in PulseAudio and systemd, so that they would really work for everybody and would really bring advantages for everybody or at least no disadvantages, or if his software would just be optional and not needed as a dependency by some distros or DEs, I'm pretty sure this discussion wouldn't always pop up again. Heiko
Re: [arch-general] PulseAudio again (was: change in mount behaviour?)
On Sat, Jan 28, 2012 at 06:24:07PM +0100, Heiko Baums wrote: > If PulseAudio was generally only optional and if its developers > wouldn't try to declare it as a standard, I just wouldn't care. It's part of a more general trend, that of dependencies on specific desktop junk trickling down into even basic system components and plain apps. And it's staring to affect Arch as well, be it much less than some others. Ciao, -- FA Vor uns liegt ein weites Tal, die Sonne scheint - ein Glitzerstrahl.
Re: [arch-general] PulseAudio again (was: change in mount behaviour?)
Am Sat, 28 Jan 2012 17:05:25 + schrieb Fons Adriaensen : > PA is for 'consumer' use, its scope ends at ITU 5.1 or so. > It doesn't support any serious multichannel card (like the > the comlete RME series, up to 64+64 channels). Users of such > cards don't need or want PA, so it's really not a problem at > all. That's principally what I said. The problem is that several distros and DEs like Gnome depend on PulseAudio as far as I know. This is what I'm concerned about. Arch Linux and Xfce, what I'm using, fortunately don't depend on it. If PulseAudio was generally only optional and if its developers wouldn't try to declare it as a standard, I just wouldn't care. > If you use such cards you probably have Jack running, and > if you really want PA you can configure it as a Jack client. I'm using an M-Audio Audiophile 24/96, so one of the cheapest semi-professional audio cards of this kind. And I admit I primarily use it for listening to music, watching videos etc. because of its sound quality. But you're right I don't want and need PulseAudio. Heiko
Re: [arch-general] PulseAudio again (was: change in mount behaviour?)
2012/1/28 Heiko Baums : > Am Sat, 28 Jan 2012 15:29:33 +0100 > schrieb Ralf Mardorf : > >> The majority of Linux users on non-audio Linux mailing lists praise >> PA, ... > > And the most computer users use Windows. So what's the point? That > doesn't mean that Windows is better than Linux or that Windows works > perfectly. > > I'm sure that most Linux users just use their stereo or maybe surround > SoundBlaster like or onboard AC'97 sound card and not a > (semi-)professional audio card. > > For those people PulseAudio may work, but that doesn't mean that it > really works, because they just don't see all the flaws. And it > definitely doesn't work with those ice1712 cards. And I've seen a lot > of discussions in Linux and IT forums where PulseAudio absolutely > wasn't praised, where most users said that it is crap or at least > unnecessary, because of the missing hardware support, and because most > of the features are already done by ALSA itself out-of-the-box. > >> I always had issues with PA and I never had an issue when I replaced >> PA by dummy packages, but seemingly there's a work flow by a majority >> of Linux users, where having PA installed is an advantage. >> >> You might take a look at Debian users mailing list. On KDE4 PA is >> using 2% CPU already when doing nothing. For some people using 2% for >> nothing isn't a bug, it's ok for them. > > So you see, that some people just don't care, maybe because they don't > know better. I would call those 2% buggy and a waste of resources. > Another reason not to using PulseAudio. > >> Why should I trust that a musician is a good drummer, when she's a bad >> guitarist? Perhaps because she's a drummer ;). > > This comparison is flawed. A guitarist wouldn't go on stage and drum, > if he can't drum, and vice versa. But Lennart writes a software for > something he at least doesn't know enough about (PulseAudio) and tries > to have this declared as standard, and at the same time writes another > software (systemd), which also has several issues or is at least not > really compatible with existing systems or script as far as I know, > instead of first fixing the first one, so that it really works. And > then he thinks he has to get involved in other things at the same time. > This is something completely different, and this is what I'm worried > about. > > If he would do one thing and would really try to fix its issues and he > would really try to learn how to fix them, I wouldn't say much. But I > don't see this. So how should I trust him and his software if he gets > himself involved in several different things if he's not able to do the > one and even the other thing correctly? > > Heiko Does this really need to be rehashed yet again? This isn't arch related yet these PA back and forths keeps popping up in the mailboxes of all the registered people looking for arch-related content. I didn't follow the original discussion so I cant argument on that extent, but the last thing we need on this list is more noise.
Re: [arch-general] PulseAudio again (was: change in mount behaviour?)
Am Sat, 28 Jan 2012 15:29:33 +0100 schrieb Ralf Mardorf : > The majority of Linux users on non-audio Linux mailing lists praise > PA, ... And the most computer users use Windows. So what's the point? That doesn't mean that Windows is better than Linux or that Windows works perfectly. I'm sure that most Linux users just use their stereo or maybe surround SoundBlaster like or onboard AC'97 sound card and not a (semi-)professional audio card. For those people PulseAudio may work, but that doesn't mean that it really works, because they just don't see all the flaws. And it definitely doesn't work with those ice1712 cards. And I've seen a lot of discussions in Linux and IT forums where PulseAudio absolutely wasn't praised, where most users said that it is crap or at least unnecessary, because of the missing hardware support, and because most of the features are already done by ALSA itself out-of-the-box. > I always had issues with PA and I never had an issue when I replaced > PA by dummy packages, but seemingly there's a work flow by a majority > of Linux users, where having PA installed is an advantage. > > You might take a look at Debian users mailing list. On KDE4 PA is > using 2% CPU already when doing nothing. For some people using 2% for > nothing isn't a bug, it's ok for them. So you see, that some people just don't care, maybe because they don't know better. I would call those 2% buggy and a waste of resources. Another reason not to using PulseAudio. > Why should I trust that a musician is a good drummer, when she's a bad > guitarist? Perhaps because she's a drummer ;). This comparison is flawed. A guitarist wouldn't go on stage and drum, if he can't drum, and vice versa. But Lennart writes a software for something he at least doesn't know enough about (PulseAudio) and tries to have this declared as standard, and at the same time writes another software (systemd), which also has several issues or is at least not really compatible with existing systems or script as far as I know, instead of first fixing the first one, so that it really works. And then he thinks he has to get involved in other things at the same time. This is something completely different, and this is what I'm worried about. If he would do one thing and would really try to fix its issues and he would really try to learn how to fix them, I wouldn't say much. But I don't see this. So how should I trust him and his software if he gets himself involved in several different things if he's not able to do the one and even the other thing correctly? Heiko
Re: [arch-general] - pulseaudio - GNOME3 in [testing]
On 09-04-2011 14:47, Matthew Monaco wrote: > Hmm, I tried that, didn't seem to help. In fact it's super frustrating > now because VLC is back to use ~16% CPU again no matter what resample > method I use and what audio output option I choose. Are you sure you have set vlc to output to pulse directly? It works fine here with minimal cpu usage. Also make sure you dont have any pavucontrol or volume metering apps running. I've found those can be quite taxing on the cpu. -- Mauro Santos
Re: [arch-general] - pulseaudio - GNOME3 in [testing]
On Sat, 09 Apr 2011 09:47:16 -0400 Matthew Monaco wrote: > On 04/09/2011 04:46 AM, Mauro Santos wrote: > > On 09-04-2011 02:12, Oon-Ee Ng wrote: > > > >> PA buffers better than ALSA, or is supposed to, in any case. Of > >> course, if you're using its ALSA-emulation that's a moot point. AFAICR > >> (haven't had this problem for ages), CPU usage from PA is basically > >> caused by the resampling, which you can just modify to a simpler > >> method if you don't need the higher quality of the default (speex, I > >> believe). > > > > I have been using the ffmpeg resample method because of that, it uses > > less cpu, or seems to use less cpu here, and with my setup I cannot > > detect any loss in quality, but hey, it is a laptop and the analog audio > > path is not stellar so ymmv. > > > > > Hmm, I tried that, didn't seem to help. In fact it's super frustrating now > because VLC is back to use ~16% CPU again no matter what resample method I > use > and what audio output option I choose. > > Also, does anyone know what is restarting pulseaudio after I --kill? Is it > gnome-shell? > I don't have Pulseaudio installed, yet, so I haven't tried it myself, but AFAIK you could try to start VLC with pasuspender wich will suspend PA as long as a given programm is running.
Re: [arch-general] - pulseaudio - GNOME3 in [testing]
On Sat, Apr 9, 2011 at 9:24 AM, Sander Jansen wrote: > On Sat, Apr 9, 2011 at 8:47 AM, Matthew Monaco wrote: >> On 04/09/2011 04:46 AM, Mauro Santos wrote: >>> >>> On 09-04-2011 02:12, Oon-Ee Ng wrote: >>> PA buffers better than ALSA, or is supposed to, in any case. Of course, if you're using its ALSA-emulation that's a moot point. AFAICR (haven't had this problem for ages), CPU usage from PA is basically caused by the resampling, which you can just modify to a simpler method if you don't need the higher quality of the default (speex, I believe). >>> >>> I have been using the ffmpeg resample method because of that, it uses >>> less cpu, or seems to use less cpu here, and with my setup I cannot >>> detect any loss in quality, but hey, it is a laptop and the analog audio >>> path is not stellar so ymmv. >>> >> >> >> Hmm, I tried that, didn't seem to help. In fact it's super frustrating now >> because VLC is back to use ~16% CPU again no matter what resample method I >> use and what audio output option I choose. >> >> Also, does anyone know what is restarting pulseaudio after I --kill? Is it >> gnome-shell? > > I believe it uses dbus activation so it could be any pulseaudio client... > Actually, not sure if that's entirely true what I just said. Now '/etc/pulse/client.conf' does have a autospawn configuration option which might prevent it from restarting.
Re: [arch-general] - pulseaudio - GNOME3 in [testing]
On Sat, Apr 9, 2011 at 8:47 AM, Matthew Monaco wrote: > On 04/09/2011 04:46 AM, Mauro Santos wrote: >> >> On 09-04-2011 02:12, Oon-Ee Ng wrote: >> >>> PA buffers better than ALSA, or is supposed to, in any case. Of >>> course, if you're using its ALSA-emulation that's a moot point. AFAICR >>> (haven't had this problem for ages), CPU usage from PA is basically >>> caused by the resampling, which you can just modify to a simpler >>> method if you don't need the higher quality of the default (speex, I >>> believe). >> >> I have been using the ffmpeg resample method because of that, it uses >> less cpu, or seems to use less cpu here, and with my setup I cannot >> detect any loss in quality, but hey, it is a laptop and the analog audio >> path is not stellar so ymmv. >> > > > Hmm, I tried that, didn't seem to help. In fact it's super frustrating now > because VLC is back to use ~16% CPU again no matter what resample method I > use and what audio output option I choose. > > Also, does anyone know what is restarting pulseaudio after I --kill? Is it > gnome-shell? I believe it uses dbus activation so it could be any pulseaudio client...
Re: [arch-general] - pulseaudio - GNOME3 in [testing]
On 04/09/2011 04:46 AM, Mauro Santos wrote: On 09-04-2011 02:12, Oon-Ee Ng wrote: PA buffers better than ALSA, or is supposed to, in any case. Of course, if you're using its ALSA-emulation that's a moot point. AFAICR (haven't had this problem for ages), CPU usage from PA is basically caused by the resampling, which you can just modify to a simpler method if you don't need the higher quality of the default (speex, I believe). I have been using the ffmpeg resample method because of that, it uses less cpu, or seems to use less cpu here, and with my setup I cannot detect any loss in quality, but hey, it is a laptop and the analog audio path is not stellar so ymmv. Hmm, I tried that, didn't seem to help. In fact it's super frustrating now because VLC is back to use ~16% CPU again no matter what resample method I use and what audio output option I choose. Also, does anyone know what is restarting pulseaudio after I --kill? Is it gnome-shell?
Re: [arch-general] PulseAudio in [testing]
Le mercredi 8 à 0:55, Brendan Long a écrit : > Have you seen the PulseAudio volume control applet (for Gnome)? My > favorite two parts are being able to control sound for each > application separately (Pidgin doesn't need to be as loud as Banshee), > and being able to switch output while things are playing (makes using > a headset much nicer). I actually stopped using PulseAudio to try OSS, > and I'm thinking of going back just for those two things. In OSS, ossxmix gives a per-application mixer, and also allows you to switch on/off outputs. NB: just launching ossxmix will both start the mixer and create a small applet in GNOME's panel; use ossxmix -S to not place an icon in the panel. -- Fred
Re: [arch-general] PulseAudio in [testing]
On 12/01/2010 08:09 PM, C Anthony Risinger wrote: since i recently blew up my computer "accidentally on purpose"[1]... i decided to try this since i said i would and so many others to had success. works perfectly under a fresh install, e17 desktop; nice w3rk! i'm liking it quite a bit... sharing/sending sound to other machines is a pretty neat trick; maybe i can set it up under my local headless KVM server and send music/etc to my or my fiancé's laptops... or both... cool. C Anthony [1] me==smart. http://www.spinics.net/lists/linux-btrfs/msg07193.html Have you seen the PulseAudio volume control applet (for Gnome)? My favorite two parts are being able to control sound for each application separately (Pidgin doesn't need to be as loud as Banshee), and being able to switch output while things are playing (makes using a headset much nicer). I actually stopped using PulseAudio to try OSS, and I'm thinking of going back just for those two things. Brendan Long
Re: [arch-general] PulseAudio in [testing]
Of course. My observation was meant to go with the comment above on preventing pulseaudio from starting if it is installed by deleting the dbus activation files. Just pointing out that an application may, potentially, still start it.
Re: [arch-general] PulseAudio in [testing]
On 02.12.2010 16:23, Simon Gomizelj wrote: From my limited experience with pulseaudio on a machine without X, it seems that anything that has native pulse support in it will automatically start pulse on demand anyways. on ArchLinux if you don't install the pulseaudio package, there wont be anything to start, since the daemon is part of that package. And nothing requires that package either. -- дамјан
Re: [arch-general] PulseAudio in [testing]
>From my limited experience with pulseaudio on a machine without X, it seems that anything that has native pulse support in it will automatically start pulse on demand anyways. 2010/12/1 Ng Oon-Ee > On Wed, 2010-12-01 at 21:09 -0600, C Anthony Risinger wrote: > > On Mon, Nov 29, 2010 at 11:03 AM, Jan Steffens > wrote: > > > On Mon, Nov 29, 2010 at 5:49 PM, Sander Jansen > wrote: > > >> Correct me if I'm wrong, but if pulseaudio is installed, I believe you > > >> should be able to prevent it from starting by removing the dbus > > >> activation files: > > >> > > >> etc/xdg/ > > >> etc/xdg/autostart/ > > >> etc/xdg/autostart/pulseaudio-kde.desktop > > >> etc/xdg/autostart/pulseaudio.desktop > > >> > > >> (unless pulse has some other way of auto-starting the daemon) > > > > > > You will also need to uncomment and deactivate the autospawn option in > > > /etc/pulse/client.conf. > > > > since i recently blew up my computer "accidentally on purpose"[1]... i > > decided to try this since i said i would and so many others to had > > success. > > [1] me==smart. http://www.spinics.net/lists/linux-btrfs/msg07193.html > > Ouch. Hope you didn't lose anything too important. > > > > works perfectly under a fresh install, e17 desktop; nice w3rk! i'm > > liking it quite a bit... sharing/sending sound to other machines is a > > pretty neat trick; maybe i can set it up under my local headless KVM > > server and send music/etc to my or my fiancé's laptops... or both... > > cool. > > Yeah, linux users are like goldfish, we don't need anything until we > actually try it out and realize is pretty cool =). I'm using PA-specific > features almost as much as I use audio on this machine. > >
Re: [arch-general] PulseAudio in [testing]
On Wed, 2010-12-01 at 21:09 -0600, C Anthony Risinger wrote: > On Mon, Nov 29, 2010 at 11:03 AM, Jan Steffens wrote: > > On Mon, Nov 29, 2010 at 5:49 PM, Sander Jansen wrote: > >> Correct me if I'm wrong, but if pulseaudio is installed, I believe you > >> should be able to prevent it from starting by removing the dbus > >> activation files: > >> > >> etc/xdg/ > >> etc/xdg/autostart/ > >> etc/xdg/autostart/pulseaudio-kde.desktop > >> etc/xdg/autostart/pulseaudio.desktop > >> > >> (unless pulse has some other way of auto-starting the daemon) > > > > You will also need to uncomment and deactivate the autospawn option in > > /etc/pulse/client.conf. > > since i recently blew up my computer "accidentally on purpose"[1]... i > decided to try this since i said i would and so many others to had > success. > [1] me==smart. http://www.spinics.net/lists/linux-btrfs/msg07193.html Ouch. Hope you didn't lose anything too important. > > works perfectly under a fresh install, e17 desktop; nice w3rk! i'm > liking it quite a bit... sharing/sending sound to other machines is a > pretty neat trick; maybe i can set it up under my local headless KVM > server and send music/etc to my or my fiancé's laptops... or both... > cool. Yeah, linux users are like goldfish, we don't need anything until we actually try it out and realize is pretty cool =). I'm using PA-specific features almost as much as I use audio on this machine.
Re: [arch-general] PulseAudio in [testing]
On Mon, Nov 29, 2010 at 11:03 AM, Jan Steffens wrote: > On Mon, Nov 29, 2010 at 5:49 PM, Sander Jansen wrote: >> Correct me if I'm wrong, but if pulseaudio is installed, I believe you >> should be able to prevent it from starting by removing the dbus >> activation files: >> >> etc/xdg/ >> etc/xdg/autostart/ >> etc/xdg/autostart/pulseaudio-kde.desktop >> etc/xdg/autostart/pulseaudio.desktop >> >> (unless pulse has some other way of auto-starting the daemon) > > You will also need to uncomment and deactivate the autospawn option in > /etc/pulse/client.conf. since i recently blew up my computer "accidentally on purpose"[1]... i decided to try this since i said i would and so many others to had success. works perfectly under a fresh install, e17 desktop; nice w3rk! i'm liking it quite a bit... sharing/sending sound to other machines is a pretty neat trick; maybe i can set it up under my local headless KVM server and send music/etc to my or my fiancé's laptops... or both... cool. C Anthony [1] me==smart. http://www.spinics.net/lists/linux-btrfs/msg07193.html
Re: [arch-general] PulseAudio in [testing]
On Mon, Nov 29, 2010 at 5:49 PM, Sander Jansen wrote: > Correct me if I'm wrong, but if pulseaudio is installed, I believe you > should be able to prevent it from starting by removing the dbus > activation files: > > etc/xdg/ > etc/xdg/autostart/ > etc/xdg/autostart/pulseaudio-kde.desktop > etc/xdg/autostart/pulseaudio.desktop > > (unless pulse has some other way of auto-starting the daemon) You will also need to uncomment and deactivate the autospawn option in /etc/pulse/client.conf.
Re: [arch-general] PulseAudio in [testing]
On Mon, Nov 29, 2010 at 6:21 AM, Damjan Georgievski wrote: >> I've put PulseAudio into [testing] some time ago, but received no >> feedback on this. >> >> This either means it works well, or nobody uses it. >> >> So I'm asking for it now, especially from GNOME and KDE users running >> PulseAudio. > > Great work Jan, > it seems your updates have eliminated all the *-pulse packages I had > from AUR (except the kde mixer for now). > > It would be a good time to post a news article about these changes. It > should explain the reasons for the change, the fact that without the > "pulseaudio" package the server is not installed and can't be started > EVER, and also how this obsoletes packages from AUR (on my count: > mplayer-pulse, xine-lib-pulse, phonon-pulse, libao-pulse, > gstreamer*-pulse, what else?). Correct me if I'm wrong, but if pulseaudio is installed, I believe you should be able to prevent it from starting by removing the dbus activation files: etc/xdg/ etc/xdg/autostart/ etc/xdg/autostart/pulseaudio-kde.desktop etc/xdg/autostart/pulseaudio.desktop (unless pulse has some other way of auto-starting the daemon) Cheers, Sander
Re: [arch-general] Pulseaudio
On 29.11.2010 10:21, Jan de Groot wrote: On Mon, 2010-11-29 at 10:09 +0100, Philipp Überbacher wrote: I guess I am one of those pulse-haters. I don't care whether it's in [extra], some other official repo or not since I simply don't need it. But now mplayer pulls in libpulse, and I have no idea which consequences this could have. I don't see why I need to have libs for a soundserver that I have no use for floating around on my machine. It is at best unnecessary and does nothing, at worst.. I don't know. I hope I don't need to install GNOME to turn it off or something.. (gconf and stuff). [...] If you don't want that tiny lib on your system, be my guest, recompile all your mediaplayers to get rid of all those optional codecs for media you don't use. Those are useless libs too, but somehow nobody complains about that. We should not forget to mention all this plagued ati and intel mplayer users, who are beeing forced to carry the burden of having libvdpau on their systems! Have not heard so much complaing about that so far ... Cheers, Ulf
Re: [arch-general] PulseAudio in [testing]
On 28.11.2010 11:47, Χρήστος Κώτσαρης wrote: > Regarding phonon being dropped, after some googling it seems i was mistaken, > what i had read was that Qt framework is dropping phonon, not KDE. But still, > i believe it would be sane to drop phonon in KDE too and replace it with > Pulseaudio, it is the best choice. No need for 2 sound servers when one could > do the trick. > > Plus, in case someone says Phonon can switch sound cards without the app > restarting, everytime i try it Amarok and others crash, so yes, it needs > restarting... Well Qt (or Nokia if you like) does not drop phonon completly, but Qt will switch to a native framework called Qt-Multimedia. There no change in functionality. Phonon isn't a sound or video playback backend, it's just an abstraction layer using other engine like vlc or xine or pulseaudio
Re: [arch-general] PulseAudio in [testing]
On Mon, 2010-11-29 at 13:21 +0100, Damjan Georgievski wrote: > > I've put PulseAudio into [testing] some time ago, but received no > > feedback on this. > > > > This either means it works well, or nobody uses it. > > > > So I'm asking for it now, especially from GNOME and KDE users running > > PulseAudio. > > Great work Jan, > it seems your updates have eliminated all the *-pulse packages I had > from AUR (except the kde mixer for now). On my system I still have mpd-pulse, gnome-media-pulse, gnome-settings-daemon-pulse, and sdl-pulse. The middle two at least will disappear with gnome updates I'm sure. I wonder whether the other two should just be left as is (without pulse support in the [extra] packages). Not a big issue, compiling from the AUR isn't a pain =) > > It would be a good time to post a news article about these changes. It > should explain the reasons for the change, the fact that without the > "pulseaudio" package the server is not installed and can't be started > EVER, and also how this obsoletes packages from AUR (on my count: > mplayer-pulse, xine-lib-pulse, phonon-pulse, libao-pulse, > gstreamer*-pulse, what else?). > > Thanks again for your effort Ditto
Re: [arch-general] PulseAudio in [testing]
> I've put PulseAudio into [testing] some time ago, but received no > feedback on this. > > This either means it works well, or nobody uses it. > > So I'm asking for it now, especially from GNOME and KDE users running > PulseAudio. Great work Jan, it seems your updates have eliminated all the *-pulse packages I had from AUR (except the kde mixer for now). It would be a good time to post a news article about these changes. It should explain the reasons for the change, the fact that without the "pulseaudio" package the server is not installed and can't be started EVER, and also how this obsoletes packages from AUR (on my count: mplayer-pulse, xine-lib-pulse, phonon-pulse, libao-pulse, gstreamer*-pulse, what else?). Thanks again for your effort -- damjan
Re: [arch-general] PulseAudio in [testing]
>> The benefit is that Flash will not f**k and lock your sound card. > > These problems are solved since years. I even made a test. Playing two > flash videos, playing music through mplayer with alsa and starting an > old game which uses oss. All this works just fine with plain alsa. No, I ment the situation when Flash locks up. When using the Alsa dmix plugin (which enables software mixing of streams from different apps) the first application that starts playing sound is the "master" one, that controls the hardware. When the master is Flash and it locks up (and it does happen often) you loose all sound on the desktop. -- damjan
Re: [arch-general] Pulseaudio
On Monday 29 November 2010 09:21:12 Jan de Groot wrote: > On Mon, 2010-11-29 at 10:09 +0100, Philipp Überbacher wrote: > > I guess I am one of those pulse-haters. I don't care whether it's in > > [extra], some other official repo or not since I simply don't need it. > > But now mplayer pulls in libpulse, and I have no idea which consequences > > this could have. I don't see why I need to have libs for a > > soundserver that I have no use for floating around on my machine. It is > > at best unnecessary and does nothing, at worst.. I don't know. I hope I > > don't need to install GNOME to turn it off or something.. (gconf and > > stuff). > > We are the first binary distribution that offers you the complete choice > of pulse or not. There's not any binary distribution out there that > dares to implement pulseaudio this way. Either they force it up your ass > completely, which is the way upstream wants, or the don't support it at > all, which we used to do before. Hear hear! And I for one am really grateful for the effort that's made this happen. Though the early part of this thread was the result of some sort of lack of understanding (on my part, at least, if not others too) I really think that, now this has been explained properly, this is a virtual non-issue. > If you don't want that tiny lib on your system, be my guest, recompile > all your mediaplayers to get rid of all those optional codecs for media > you don't use. Those are useless libs too, but somehow nobody complains > about that. (Unfortunately?), there are plenty of examples of this, like emacs always requiring gconf just in case you also have GNOME installed and ask emacs to use the GNOME font. But, there's always a tradeoff, and these things are not that big. And, in case anyone needed even extra flexibility that that which the dev's already try to provide (as in pulse's case), we have ABS and the AUR. Arch FTW! Pete.
Re: [arch-general] Pulseaudio
Excerpts from Jan de Groot's message of 2010-11-29 10:21:12 +0100: > On Mon, 2010-11-29 at 10:09 +0100, Philipp Überbacher wrote: > > I guess I am one of those pulse-haters. I don't care whether it's in > > [extra], some other official repo or not since I simply don't need it. > > But now mplayer pulls in libpulse, and I have no idea which consequences > > this could have. I don't see why I need to have libs for a > > soundserver that I have no use for floating around on my machine. It is > > at best unnecessary and does nothing, at worst.. I don't know. I hope I > > don't need to install GNOME to turn it off or something.. (gconf and > > stuff). > > Sorry, but this is plain. > When GNOME switched to pulse, we made the choice to boycot it and patch > our applications to use GStreamer instead. We still do that with our > GNOME packages, as we still don't want to force pulseaudio on systems. > The reason for libpulse is that without pulseaudio installed, it will > not have any function besides offering optional support for pulseaudio. > No pulseaudio with libpulse just means no pulseaudio. > We are the first binary distribution that offers you the complete choice > of pulse or not. There's not any binary distribution out there that > dares to implement pulseaudio this way. Either they force it up your ass > completely, which is the way upstream wants, or the don't support it at > all, which we used to do before. Good if libpulse really does nothing, but I hope you see my point. Libpulse is the part of PA you need to install in order to avoid PA. In a way it's like a vaccine. It sounds like what you guys did is the best possible thing for us users, and I appreciate that, but it shouldn't be forced up our asses by upstream in the first place. > If you don't want that tiny lib on your system, be my guest, recompile > all your mediaplayers to get rid of all those optional codecs for media > you don't use. Those are useless libs too, but somehow nobody complains > about that. Codecs are at least potentially useful, but it's still a valid comparison. The only media player I know that handles this sanely is MOC. Say it's built with wavpack support it. If wavpack is installed you can load and play wavpack files just fine, if wavpack is missing at runtime you simply can't add wavpack files to the playlist or play ones that already are in the playlist. That's the way it should be IMHO, but it's rarely the case.
Re: [arch-general] Pulseaudio
On 11/28/10 23:19, Christos Kotsaris wrote: Well Morgan Gangwere since all of us Arch users understand this greatly important need to play a 13 year game on an 11 year old machine, we should rollback all changes and send pulseaudio in AUR where it belongs. I mean, we can't leave behind every cheap computer user who can't be bothered to buy even a 5 years old used machine, can we? I mean, Linux is about supporting antics isn't it? We should accomondate those needs, because we might lose this kind of user. He might just go and install Windows 7 on his coppermine. I mean, Windows always supported 11 year old pcs, why Arch wont? Please developers, reconsider. Best post here...ever. :-D
Re: [arch-general] Pulseaudio
On Mon, 2010-11-29 at 17:25 +0800, Ng Oon-Ee wrote: > Good luck getting pulse-haters to understand that a 1.14 MB package > isn't going to kill their system though. > > Thanks JGC for your work on this. I didn't think it was possible to > have > such choice, and it looks like you've jumped through quite a few > packaging hoops to get here. I haven't done anything in this, as I have always avoided pulse like the plague. It was Jan Steffens who did all the work. I brought him on the team to take over GNOME together with Ionut, so I can focus on Xorg with my limited time.
Re: [arch-general] Pulseaudio
On Mon, 2010-11-29 at 10:21 +0100, Jan de Groot wrote: > On Mon, 2010-11-29 at 10:09 +0100, Philipp Überbacher wrote: > > I guess I am one of those pulse-haters. I don't care whether it's in > > [extra], some other official repo or not since I simply don't need it. > > But now mplayer pulls in libpulse, and I have no idea which consequences > > this could have. I don't see why I need to have libs for a > > soundserver that I have no use for floating around on my machine. It is > > at best unnecessary and does nothing, at worst.. I don't know. I hope I > > don't need to install GNOME to turn it off or something.. (gconf and > > stuff). > > Sorry, but this is plain. > When GNOME switched to pulse, we made the choice to boycot it and patch > our applications to use GStreamer instead. We still do that with our > GNOME packages, as we still don't want to force pulseaudio on systems. > The reason for libpulse is that without pulseaudio installed, it will > not have any function besides offering optional support for pulseaudio. > No pulseaudio with libpulse just means no pulseaudio. > We are the first binary distribution that offers you the complete choice > of pulse or not. There's not any binary distribution out there that > dares to implement pulseaudio this way. Either they force it up your ass > completely, which is the way upstream wants, or the don't support it at > all, which we used to do before. > > If you don't want that tiny lib on your system, be my guest, recompile > all your mediaplayers to get rid of all those optional codecs for media > you don't use. Those are useless libs too, but somehow nobody complains > about that. > Good luck getting pulse-haters to understand that a 1.14 MB package isn't going to kill their system though. Thanks JGC for your work on this. I didn't think it was possible to have such choice, and it looks like you've jumped through quite a few packaging hoops to get here.
Re: [arch-general] Pulseaudio
On Mon, 2010-11-29 at 10:09 +0100, Philipp Überbacher wrote: > I guess I am one of those pulse-haters. I don't care whether it's in > [extra], some other official repo or not since I simply don't need it. > But now mplayer pulls in libpulse, and I have no idea which consequences > this could have. I don't see why I need to have libs for a > soundserver that I have no use for floating around on my machine. It is > at best unnecessary and does nothing, at worst.. I don't know. I hope I > don't need to install GNOME to turn it off or something.. (gconf and > stuff). Sorry, but this is plain. When GNOME switched to pulse, we made the choice to boycot it and patch our applications to use GStreamer instead. We still do that with our GNOME packages, as we still don't want to force pulseaudio on systems. The reason for libpulse is that without pulseaudio installed, it will not have any function besides offering optional support for pulseaudio. No pulseaudio with libpulse just means no pulseaudio. We are the first binary distribution that offers you the complete choice of pulse or not. There's not any binary distribution out there that dares to implement pulseaudio this way. Either they force it up your ass completely, which is the way upstream wants, or the don't support it at all, which we used to do before. If you don't want that tiny lib on your system, be my guest, recompile all your mediaplayers to get rid of all those optional codecs for media you don't use. Those are useless libs too, but somehow nobody complains about that.
Re: [arch-general] Pulseaudio
Excerpts from christos.kotsaris's message of 2010-11-29 08:05:40 +0100: > On a more serious mode now: > > As the devs themselves said, pulseaudio is optional, unless you are using > GNOME, which requires Pulseaudio upstream. There is nothing clearer than > that. > Go blame GNOME developers. > > There is something i noticed. Morgan Gandwere is a Debian convert... That > explains a lot of things actually. > > Debian is known to modify every possible package, since Debian maintainers > are > more wise and of course they know better than upstream developers about > upstream software. > > Debian is known to fork a package when some upstream developer does not > accept > a debian maintainer's POS patch. Then the package is left to rott and die, > since the debian maintainer is not able to develop it. > > Debian users are used to this mentality. That explains why someone with this > background believes that a distribution should modify upstream to fit its > maintainers whims. > > Sometimes there have been packages i wanted that didn't make part of Arch, > even though in my opinion they should. For example, libxft-lcd was in > community, while lib32-libxft-lcd was not. I asked in the forum to include > that too, but instead, libxft-lcd went to AUR also. I didn't bitch about it, > i > just use AUR and that's it. One can't expect a whole distribution to > accomondate his personal needs. > > So pulseaudio haters, since pulseaudio is optional, the only reason you > complain is that you don't want it in extra, you don't want to install > libpulse since you cant afford 1MB disk space, and you also don't want media > packages compiled with pulse support because of a purely theoritical bloat. > > Well, you can't expect the distro to remain behind the times and not include > proper (optional) pulse support for these reasons. If 1 mb of disk space and > tiny bits of memory bloat in executables is such a waste for you, you could > recompile those packages, or even better, try Gentoo. I hear Gentoo is really > fast and without bloat. After 60 hours of compiling your apps start 5ns > faster. Great! I guess I am one of those pulse-haters. I don't care whether it's in [extra], some other official repo or not since I simply don't need it. But now mplayer pulls in libpulse, and I have no idea which consequences this could have. I don't see why I need to have libs for a soundserver that I have no use for floating around on my machine. It is at best unnecessary and does nothing, at worst.. I don't know. I hope I don't need to install GNOME to turn it off or something.. (gconf and stuff).
Re: [arch-general] PulseAudio in [testing]
On Mon, Nov 29, 2010 at 8:32 AM, Pierre Schmitz wrote: > These problems are solved since years. I even made a test. Playing two > flash videos, playing music through mplayer with alsa and starting an > old game which uses oss. All this works just fine with plain alsa. > > -- > Pierre Schmitz, https://users.archlinux.de/~pierre > Slight detail: ALSA's built-in OSS emulation is inside the kernel, meaning it can only use the hardware directly. This bypasses dmix and other extensions of ALSA userspace. You would need to use aoss if you want to use dmix with OSS applications. ossp's ALSA backend is in a bad state, regrettably.
Re: [arch-general] PulseAudio in [testing]
On Sat, 27 Nov 2010 13:27:47 +0100, Damjan wrote: >>> I've put PulseAudio into [testing] some time ago, but received no >>> feedback on this. >>> >>> This either means it works well, or nobody uses it. >>> >>> So I'm asking for it now, especially from GNOME and KDE users running >>> PulseAudio. >> >> I tested it a while on KDE and as expected it has downsides compared to >> using plain alsa. :-) I lost all controls in kmix except of only one >> volume control. > > The benefit is that Flash will not f**k and lock your sound card. These problems are solved since years. I even made a test. Playing two flash videos, playing music through mplayer with alsa and starting an old game which uses oss. All this works just fine with plain alsa. -- Pierre Schmitz, https://users.archlinux.de/~pierre
[arch-general] Pulseaudio
On a more serious mode now: As the devs themselves said, pulseaudio is optional, unless you are using GNOME, which requires Pulseaudio upstream. There is nothing clearer than that. Go blame GNOME developers. There is something i noticed. Morgan Gandwere is a Debian convert... That explains a lot of things actually. Debian is known to modify every possible package, since Debian maintainers are more wise and of course they know better than upstream developers about upstream software. Debian is known to fork a package when some upstream developer does not accept a debian maintainer's POS patch. Then the package is left to rott and die, since the debian maintainer is not able to develop it. Debian users are used to this mentality. That explains why someone with this background believes that a distribution should modify upstream to fit its maintainers whims. Sometimes there have been packages i wanted that didn't make part of Arch, even though in my opinion they should. For example, libxft-lcd was in community, while lib32-libxft-lcd was not. I asked in the forum to include that too, but instead, libxft-lcd went to AUR also. I didn't bitch about it, i just use AUR and that's it. One can't expect a whole distribution to accomondate his personal needs. So pulseaudio haters, since pulseaudio is optional, the only reason you complain is that you don't want it in extra, you don't want to install libpulse since you cant afford 1MB disk space, and you also don't want media packages compiled with pulse support because of a purely theoritical bloat. Well, you can't expect the distro to remain behind the times and not include proper (optional) pulse support for these reasons. If 1 mb of disk space and tiny bits of memory bloat in executables is such a waste for you, you could recompile those packages, or even better, try Gentoo. I hear Gentoo is really fast and without bloat. After 60 hours of compiling your apps start 5ns faster. Great!
[arch-general] Pulseaudio
Well Morgan Gangwere since all of us Arch users understand this greatly important need to play a 13 year game on an 11 year old machine, we should rollback all changes and send pulseaudio in AUR where it belongs. I mean, we can't leave behind every cheap computer user who can't be bothered to buy even a 5 years old used machine, can we? I mean, Linux is about supporting antics isn't it? We should accomondate those needs, because we might lose this kind of user. He might just go and install Windows 7 on his coppermine. I mean, Windows always supported 11 year old pcs, why Arch wont? Please developers, reconsider.
Re: [arch-general] PulseAudio in [testing]
On Sun, Nov 28, 2010 at 06:29:56PM -0600, Yaro Kasear wrote: > On Mon, 2010-11-29 at 01:15 +0100, f...@kokkinizita.net wrote: > > On Sun, Nov 28, 2010 at 06:44:10PM -0500, Simon Gomizelj wrote: > > > > > Pulseaudio has been buggy because in many cases they have been the very > > > first people to ever make use of some of the more esoteric parts of alsa. > > > Those parts also lacked proper documentation and many drivers didn't even > > > bother with a proper implementation. > > > > True. And what PA probably needs most and ALSA does not provide > > is a way to provide *lots* of buffering (more than a second, in > > cases where latency does not matter), while at the same time > > allowing an app to 'review' or 'rewind' this buffering in order > > to ensure responsiveness to user commands (such as stop/play for > > a player). > > > > Ciao, > > > > I'm sorry, but did no one notice that I haven't said anything more and > have, in fact, dropped this discussion? Who are you arguing with? I did not respond to you but to Simon Gomizelj's message, and I am not arguing at all. Ciao, -- FA There are three of them, and Alleline.
Re: [arch-general] PulseAudio in [testing]
On Nov 28, 2010, at 6:30 PM, Yaro Kasear wrote: > On Mon, 2010-11-29 at 01:15 +0100, f...@kokkinizita.net wrote: >> On Sun, Nov 28, 2010 at 06:44:10PM -0500, Simon Gomizelj wrote: >> >>> Pulseaudio has been buggy because in many cases they have been the >>> very >>> first people to ever make use of some of the more esoteric parts >>> of alsa. >>> Those parts also lacked proper documentation and many drivers >>> didn't even >>> bother with a proper implementation. >> >> True. And what PA probably needs most and ALSA does not provide >> is a way to provide *lots* of buffering (more than a second, in >> cases where latency does not matter), while at the same time >> allowing an app to 'review' or 'rewind' this buffering in order >> to ensure responsiveness to user commands (such as stop/play for >> a player). >> >> Ciao, >> > > I'm sorry, but did no one notice that I haven't said anything more and > have, in fact, dropped this discussion? Who are you arguing with? Unfortunately it usually takes 10-100x informed responses to negate each FUD riddled one. I would just continue to stand by and absorb the yummy brownies of information. C Anthony [mobile]
Re: [arch-general] PulseAudio in [testing]
On Mon, 2010-11-29 at 01:15 +0100, f...@kokkinizita.net wrote: > On Sun, Nov 28, 2010 at 06:44:10PM -0500, Simon Gomizelj wrote: > > > Pulseaudio has been buggy because in many cases they have been the very > > first people to ever make use of some of the more esoteric parts of alsa. > > Those parts also lacked proper documentation and many drivers didn't even > > bother with a proper implementation. > > True. And what PA probably needs most and ALSA does not provide > is a way to provide *lots* of buffering (more than a second, in > cases where latency does not matter), while at the same time > allowing an app to 'review' or 'rewind' this buffering in order > to ensure responsiveness to user commands (such as stop/play for > a player). > > Ciao, > I'm sorry, but did no one notice that I haven't said anything more and have, in fact, dropped this discussion? Who are you arguing with?
Re: [arch-general] PulseAudio in [testing]
On Sun, Nov 28, 2010 at 06:44:10PM -0500, Simon Gomizelj wrote: > Pulseaudio has been buggy because in many cases they have been the very > first people to ever make use of some of the more esoteric parts of alsa. > Those parts also lacked proper documentation and many drivers didn't even > bother with a proper implementation. True. And what PA probably needs most and ALSA does not provide is a way to provide *lots* of buffering (more than a second, in cases where latency does not matter), while at the same time allowing an app to 'review' or 'rewind' this buffering in order to ensure responsiveness to user commands (such as stop/play for a player). Ciao, -- FA There are three of them, and Alleline.
Re: [arch-general] PulseAudio in [testing]
Pulseaudio did expose a lot of bugs in alsa that needed to be fixed in alsa. IIRC they are attempting to move from scheduling sound with the soundcard's hardware interrupts to an entirely cpu based method. I can't remember exactly what the technique is, but it allows for better latency control, better mixing of applications which make different buffer size/latency demands, and consumed less power overall because of increased flexibility over have the processor sleep. Pulseaudio has been buggy because in many cases they have been the very first people to ever make use of some of the more esoteric parts of alsa. Those parts also lacked proper documentation and many drivers didn't even bother with a proper implementation.
Re: [arch-general] PulseAudio in [testing]
Excerpts from Ng Oon-Ee's message of 2010-11-28 17:19:11 +0100: > > I'll take both your words on it. Its worth noting that Pulseaudio > automatically corks when JACK wants a sound-device (jack2 that is, not > jack1). Running phonon atop pulseaudio wouldn't make sense if every app > uses phonon. Due to other considerations (for example that all the major > distros are pushing pulse), this may not be the case in the future. Just to make sure no-one gets wrong ideas: jack2, despite its name, isn't going to replace jack. It's another implementation, not a replacement. Both have their share of benefits and drawbacks, and Jack (1) is the most used implementation.
Re: [arch-general] PulseAudio in [testing]
On 28-11-2010 16:21, Yaro Kasear wrote: > ... if they were to actually test this, > would FLOOD this entire discussion with problems that would make the > Arch devs reconsider this decision. So you are making the assumption that using pulse still causes the same problems it used to cause before (on other distros at that). To top that you are assuming that it is pulse that is (or was) broken and not the alsa drivers that do the actual talking to the hardware. Just because something seems to work or claims to support something it doesn't mean it works well for all the cases, this was most probably the case with alsa drivers and it has improved a lot lately. When I bought the notebook I'm using now I've used ossv4 for some time because I couldn't stand the crappy sound that alsa (and only alsa, apps would output directly to alsa) would put out at the time, I have given alsa and pulse and alsa a try again and it's what I've been using for maybe a year now with _zero_ problems, even with apps that don't know what pulse is. >From your other posts it seems you have some kind of pet hate for pulse and present arguments that don't really apply currently, I'm sure there are some people here that also have a pet hate for the way that the kde folks seem to have to reinvent the wheel but don't spam the list with it. Please present _objective_ advantages and disadvantages of using pulse+alsa when compared with ossv4 or alsa + something else instead of just saying that pulse sucks. -- Mauro Santos
Re: [arch-general] PulseAudio in [testing]
On Sun, 2010-11-28 at 16:24 +, Nathan Wayde wrote: > > > > It's probably because the masses of people who already know Pulse Audio > > will break their sound aren't bothering to try it. I have a whole IRC > > channel filled with people who, if they were to actually test this, > > would FLOOD this entire discussion with problems that would make the > > Arch devs reconsider this decision. > > > > > > dude! no-one cares what you think so quit spamming the mailing list with > your nonsense already you clearly don't know what you're talking about > so please spreading FUD you're just exposing your ignorance. FUD would be if it wasn't true. Seriously, Google "pulseaudio problems" sometime. You'll see tons of reasons why this shouldn't be done. There's always dozens of threads at any given time on just about every Linux distribution's forums PURELY about fixing the SAME EXACT problems in Pulse that have been there from the beginning. Do you *really* want me to put up a detailed list of all of Pulse Audio's breakages that have never been fixed? Because I can do it, you know.
Re: [arch-general] PulseAudio in [testing]
On 11/28/2010 06:18 PM, Yaro Kasear wrote: On Mon, 2010-11-29 at 00:15 +0800, Ray Rashif wrote: On 29 November 2010 00:08, Yaro Kasear wrote: Once again, I say PA is far from the kind of quality I'd expect from a package in [extra], and I'm surprised the Arch devs are even considering it, especially in light of the fact that there's far more stable and useful packages in [community] getting passed up. Once again, nobody asked for opinions on PulseAudio, the software. If it does affect you directly, do report that here or the bugtracker. It was moved to [extra] for package-specific reasons, not just on a whim as you would like to think. What packages actually REQUIRE Pulse Audio? I don't know of a single Linux app to date that actually NEEDS it over what already exists in ALSA itself. dear Mr Yaro. I suggest to read again the first message from the list. It doesn't ask for opinions about pulse on how good or bad is. Keep your opinions for yourself. You are not forced to use pulse if you hate it, pulseaudio is optionally unless you are using gnome. Starting GNOME 3, we will include support by default. This it happened some time ago upstream but WE keep it out, until now. PLEASE, but PLEASE keep your junks out on my inbox -- Ionuț
Re: [arch-general] PulseAudio in [testing]
It's probably because the masses of people who already know Pulse Audio will break their sound aren't bothering to try it. I have a whole IRC channel filled with people who, if they were to actually test this, would FLOOD this entire discussion with problems that would make the Arch devs reconsider this decision. dude! no-one cares what you think so quit spamming the mailing list with your nonsense already you clearly don't know what you're talking about so please spreading FUD you're just exposing your ignorance.
Re: [arch-general] PulseAudio in [testing]
On Mon, 2010-11-29 at 00:19 +0800, Ng Oon-Ee wrote: > On Sun, 2010-11-28 at 17:49 +0800, Ray Rashif wrote: > > On 28 November 2010 11:24, Yaro Kasear wrote: > > > On Sun, 2010-11-28 at 11:17 +0800, Ng Oon-Ee wrote: > > >> On Sat, 2010-11-27 at 18:21 -0600, Yaro Kasear wrote: > > >> > I don't see KDE upstream doing that. They have Phonon. What's more, > > >> > most > > >> > KDE apps today count on Phonon being there. KDE upstream won't do that > > >> > without expecting to break KDE. > > >> > > >> Admittedly my view on this is skewed, since I follow PA's development > > >> pretty closely, but one of the devs on PA (Colin Guthrie) has mentioned > > >> getting various patches he's done for Mandriva's KDE implementation such > > >> that KDE's mixer and such supports pulseaudio natively. Phonon would > > >> output directly to pulse in that case, I believe. > > >> > > > > > > The point of which would be what exactly? All due respect, Phonon is > > > already a sound daemon. To output sound through a sound daemon into > > > ANOTHER sound daemon, particularly one as poor as Pulse Audio, is > > > begging for latency and who knows how many other problems. > > > > > > And, again, it's redundant and unnecessary since Phonon's already a good > > > sound daemon on its own merits. > > > > In fact, it handles all my audio pretty well, and even lets JACK take > > over when needed without my intervention. There's no PulseAudio or a > > kill command in that equation. > > I'll take both your words on it. Its worth noting that Pulseaudio > automatically corks when JACK wants a sound-device (jack2 that is, not > jack1). Running phonon atop pulseaudio wouldn't make sense if every app > uses phonon. Due to other considerations (for example that all the major > distros are pushing pulse), this may not be the case in the future. > > > > Anyway, Jan, everything works great, no troubles (with libpulse and > > without pulseaudio) on KDE. Good job. > > Yes, the lack of complaints (about actual problems) is really > surprising. > It's probably because the masses of people who already know Pulse Audio will break their sound aren't bothering to try it. I have a whole IRC channel filled with people who, if they were to actually test this, would FLOOD this entire discussion with problems that would make the Arch devs reconsider this decision.
Re: [arch-general] PulseAudio in [testing]
On Sun, 2010-11-28 at 17:49 +0800, Ray Rashif wrote: > On 28 November 2010 11:24, Yaro Kasear wrote: > > On Sun, 2010-11-28 at 11:17 +0800, Ng Oon-Ee wrote: > >> On Sat, 2010-11-27 at 18:21 -0600, Yaro Kasear wrote: > >> > I don't see KDE upstream doing that. They have Phonon. What's more, most > >> > KDE apps today count on Phonon being there. KDE upstream won't do that > >> > without expecting to break KDE. > >> > >> Admittedly my view on this is skewed, since I follow PA's development > >> pretty closely, but one of the devs on PA (Colin Guthrie) has mentioned > >> getting various patches he's done for Mandriva's KDE implementation such > >> that KDE's mixer and such supports pulseaudio natively. Phonon would > >> output directly to pulse in that case, I believe. > >> > > > > The point of which would be what exactly? All due respect, Phonon is > > already a sound daemon. To output sound through a sound daemon into > > ANOTHER sound daemon, particularly one as poor as Pulse Audio, is > > begging for latency and who knows how many other problems. > > > > And, again, it's redundant and unnecessary since Phonon's already a good > > sound daemon on its own merits. > > In fact, it handles all my audio pretty well, and even lets JACK take > over when needed without my intervention. There's no PulseAudio or a > kill command in that equation. I'll take both your words on it. Its worth noting that Pulseaudio automatically corks when JACK wants a sound-device (jack2 that is, not jack1). Running phonon atop pulseaudio wouldn't make sense if every app uses phonon. Due to other considerations (for example that all the major distros are pushing pulse), this may not be the case in the future. > > Anyway, Jan, everything works great, no troubles (with libpulse and > without pulseaudio) on KDE. Good job. Yes, the lack of complaints (about actual problems) is really surprising.
Re: [arch-general] PulseAudio in [testing]
On Mon, 2010-11-29 at 00:15 +0800, Ray Rashif wrote: > On 29 November 2010 00:08, Yaro Kasear wrote: > > Once again, I say PA is far from the kind of quality I'd expect from a > > package in [extra], and I'm surprised the Arch devs are even considering > > it, especially in light of the fact that there's far more stable and > > useful packages in [community] getting passed up. > > Once again, nobody asked for opinions on PulseAudio, the software. If > it does affect you directly, do report that here or the bugtracker. It > was moved to [extra] for package-specific reasons, not just on a whim > as you would like to think. What packages actually REQUIRE Pulse Audio? I don't know of a single Linux app to date that actually NEEDS it over what already exists in ALSA itself.
Re: [arch-general] PulseAudio in [testing]
On 29 November 2010 00:08, Yaro Kasear wrote: > Once again, I say PA is far from the kind of quality I'd expect from a > package in [extra], and I'm surprised the Arch devs are even considering > it, especially in light of the fact that there's far more stable and > useful packages in [community] getting passed up. Once again, nobody asked for opinions on PulseAudio, the software. If it does affect you directly, do report that here or the bugtracker. It was moved to [extra] for package-specific reasons, not just on a whim as you would like to think.
Re: [arch-general] PulseAudio in [testing]
On Sun, 2010-11-28 at 12:11 +0200, Χρήστος Κώτσαρης wrote: > I believe this was the right choice. Pulseaudio should be in extra and all > applications build with pulse support. Except for the fact that Pulse Audio is an incredible REGRESSION in Linux sound and causes far more problems than it solves. Do a google search on it sometime, you'd be surprised what a huge headache Pulse Audio actually is. > Regarding phonon, i believe KDE intends to drop it at some point, not sure > were i read that. I remember reading something about KDE 5 not including > phonon, but it may be FUD. Anyone more informed on the issue? KDE has no intention of dropping Phonon. Largely because they just implemented it as new in KDE 4. And they wouldn't drop it in favor of something as low quality and unstable as Pulse Audio. GNOME might, but their developers are idiots. > In any case, Linux/GNU needs pulseaudio. Pulseaudio should be the api to > target for all apps. The kind of functionality it provides it is needed if > modern distros are to compete with Windows 7. Windows 7 now provide the > functionality to switch sound cards on the fly without restaring the app > playing sound. This is possible only with Pulseaudio as far as i can tell in > the Linux world. And this is just one example. Linux has no need for Pulse. ALSA works perfectly fine. Pulse is a regression in Linux sound. If you think PA will catch Linux up to Windows 7 (It should be noted Linux is way ahead of Windows 7 in all the ways that actually count.), you're going to get a painful bite of reality when countless Windows 7 users correctly point ou ttheir sound Just Works where Linux USED TO before Pulse Audio came around and broke absolutely everything. Besides, both KDE and GNOME already provide user-friendly audio utilities that are easier to handle with Pulse Audio and, here's the killer feature, don't break sound AT ALL. > Imagine if you have a headset with included sound card, for example a 5.1 > headset. Without Pulseaudio, it is a chore to switch sound to it, with > Pulseaudio it is easy and userfriendly. Windows 7 now can do it too. Imagine > if a user tries to do it in Linux without pulse, he will be frustrated. Of > course, Arch users should be knowledgable enough to switch sound cards in > ALSA, but it still is a chore. And it is not the point. Actually, ALSA has a pretty simple and easy means to switch to USB audio devices. The Arch wiki even says so. Pulse might provide an easy way to switch to it, but it's completely outweighed by the fact that there's a 70% chance Pulse Audio will break most (If not all.) your sound. > The point is, Linux needs a sound daemon to provide modern user friendliness. > So it is a matter of time for GNOME and KDE to support it natively. KDE tried > it with phonon, but it seems phonon is more problematic than pulseaudio, with > less features. At least for me, when phonon sits on top of ALSA, i get all > sorts of messages informing me that some interface should be disabled, it is > annoying. Plus when i change a sound card, the app needs restarting. Phonon is far less problematic than PA. HAving actually used both extensively. Largely because Phonon doesn't hijack ALL sound on the system it runs on like Pulse Audio, so that even if Phonon breaks (Has yet to happen with me.) you can STILL use SOME sound, whereas in the inevitable eventuality Pulse Audio breaks, ALL your sound goes with it, even if you manage to kill it, because it took it on itself to take all your sound over, which no other sound daemon does, and for damn good reason. > So yes, in time pulseaudio should become the default linux api for Linux/GNU, > if not already. If there are bugs, they could be solved if all those geniuses > bitching about it and use ALSA could be bothered to help a little. > First off, Pulse Audio is not a sound API like ALSA or OSS, it's a Daemon, and a very crappy one at that. In fact, it's a crappy sound daemon that breaks sound that it and its developers somehow convinced themselves was a legit sound API akin to ALSA and OSS. Second off, no, it should NOT become a universal default for Linux because its a horrendous regression running on top of ALSA. Even the Linux kernel developers themselves have said so, even the ALSA developer suggested rewriting ALSA would be a far better alternative to Pulse Audio. Finally, the problems introduced in Pulse audio are NOT the fault of ALSA, drivers, OR distributions no matter how much PA's upstream loves to clamor for it to be true. The sad cold fact is Pulse Audio is buggy, unstable, unnecessary, slow, bloated, and causes WAY more problems than it solves. In fact, there's no problems actually PRESENT in ALSA Pulse is actually solving. Before Pulse came along, ALSA was doing very well. If you were to ask the opinion of myself and my colleagues, I'd recommend abandoning to idiotic sound daemon idea altogether and instead use or create an audio abstraction library a
Re: [arch-general] PulseAudio in [testing]
On Sunday 28 November 2010 12:48:38 Jan Steffens wrote: > Note that as far as I know, phonon is an abstraction API with similar > functionality like GStreamer, not PulseAudio. Yes indeed, that's my understanding too. Anyway, thanks Jan - I can report that I'm using KDE, VLC etc. without pulse and everything seems fine. This kind of separation and choice is one of the reasons why I really like Arch. Good work :-) As an aside... On Sunday 28 November 2010 10:11:12 Χρήστος Κώτσαρης wrote: > In any case, Linux/GNU needs pulseaudio. Pulseaudio should be the api to > target for all apps. The kind of functionality it provides it is needed if > modern distros are to compete with Windows 7. Windows 7 now provide the > functionality to switch sound cards on the fly without restaring the app > playing sound. Personally speaking, I can honestly say that I've never even considered this functionality. And I for one don't think that Arch's aims are (nor should be) to just try to keep up with Microsoft's bloat. Have it as an option for those that want this, by all means, but Arch way beats Windows 7 in pretty much every criteria I have. Pete.
Re: [arch-general] PulseAudio in [testing]
2010/11/28 Χρήστος Κώτσαρης : > Regarding phonon being dropped, after some googling it seems i was mistaken, > what i had read was that Qt framework is dropping phonon, not KDE. But still, > i believe it would be sane to drop phonon in KDE too and replace it with > Pulseaudio, it is the best choice. No need for 2 sound servers when one could > do the trick. > > Plus, in case someone says Phonon can switch sound cards without the app > restarting, everytime i try it Amarok and others crash, so yes, it needs > restarting... > Note that as far as I know, phonon is an abstraction API with similar functionality like GStreamer, not PulseAudio.
Re: [arch-general] PulseAudio in [testing]
Regarding phonon being dropped, after some googling it seems i was mistaken, what i had read was that Qt framework is dropping phonon, not KDE. But still, i believe it would be sane to drop phonon in KDE too and replace it with Pulseaudio, it is the best choice. No need for 2 sound servers when one could do the trick. Plus, in case someone says Phonon can switch sound cards without the app restarting, everytime i try it Amarok and others crash, so yes, it needs restarting...
Re: [arch-general] PulseAudio in [testing]
I believe this was the right choice. Pulseaudio should be in extra and all applications build with pulse support. Regarding phonon, i believe KDE intends to drop it at some point, not sure were i read that. I remember reading something about KDE 5 not including phonon, but it may be FUD. Anyone more informed on the issue? In any case, Linux/GNU needs pulseaudio. Pulseaudio should be the api to target for all apps. The kind of functionality it provides it is needed if modern distros are to compete with Windows 7. Windows 7 now provide the functionality to switch sound cards on the fly without restaring the app playing sound. This is possible only with Pulseaudio as far as i can tell in the Linux world. And this is just one example. Imagine if you have a headset with included sound card, for example a 5.1 headset. Without Pulseaudio, it is a chore to switch sound to it, with Pulseaudio it is easy and userfriendly. Windows 7 now can do it too. Imagine if a user tries to do it in Linux without pulse, he will be frustrated. Of course, Arch users should be knowledgable enough to switch sound cards in ALSA, but it still is a chore. And it is not the point. The point is, Linux needs a sound daemon to provide modern user friendliness. So it is a matter of time for GNOME and KDE to support it natively. KDE tried it with phonon, but it seems phonon is more problematic than pulseaudio, with less features. At least for me, when phonon sits on top of ALSA, i get all sorts of messages informing me that some interface should be disabled, it is annoying. Plus when i change a sound card, the app needs restarting. So yes, in time pulseaudio should become the default linux api for Linux/GNU, if not already. If there are bugs, they could be solved if all those geniuses bitching about it and use ALSA could be bothered to help a little.
Re: [arch-general] PulseAudio in [testing]
On 28 November 2010 11:24, Yaro Kasear wrote: > On Sun, 2010-11-28 at 11:17 +0800, Ng Oon-Ee wrote: >> On Sat, 2010-11-27 at 18:21 -0600, Yaro Kasear wrote: >> > On Sun, 2010-11-28 at 08:18 +0800, Ng Oon-Ee wrote: >> > > Just don't use Gnome. Upstream is going to make Pulseaudio default. KDE >> > > as well, maybe. >> > > >> > I don't see KDE upstream doing that. They have Phonon. What's more, most >> > KDE apps today count on Phonon being there. KDE upstream won't do that >> > without expecting to break KDE. >> >> Admittedly my view on this is skewed, since I follow PA's development >> pretty closely, but one of the devs on PA (Colin Guthrie) has mentioned >> getting various patches he's done for Mandriva's KDE implementation such >> that KDE's mixer and such supports pulseaudio natively. Phonon would >> output directly to pulse in that case, I believe. >> > > The point of which would be what exactly? All due respect, Phonon is > already a sound daemon. To output sound through a sound daemon into > ANOTHER sound daemon, particularly one as poor as Pulse Audio, is > begging for latency and who knows how many other problems. > > And, again, it's redundant and unnecessary since Phonon's already a good > sound daemon on its own merits. In fact, it handles all my audio pretty well, and even lets JACK take over when needed without my intervention. There's no PulseAudio or a kill command in that equation. Anyway, Jan, everything works great, no troubles (with libpulse and without pulseaudio) on KDE. Good job.
Re: [arch-general] PulseAudio in [testing]
On Sun, 2010-11-28 at 11:17 +0800, Ng Oon-Ee wrote: > On Sat, 2010-11-27 at 18:21 -0600, Yaro Kasear wrote: > > On Sun, 2010-11-28 at 08:18 +0800, Ng Oon-Ee wrote: > > > Just don't use Gnome. Upstream is going to make Pulseaudio default. KDE > > > as well, maybe. > > > > > I don't see KDE upstream doing that. They have Phonon. What's more, most > > KDE apps today count on Phonon being there. KDE upstream won't do that > > without expecting to break KDE. > > Admittedly my view on this is skewed, since I follow PA's development > pretty closely, but one of the devs on PA (Colin Guthrie) has mentioned > getting various patches he's done for Mandriva's KDE implementation such > that KDE's mixer and such supports pulseaudio natively. Phonon would > output directly to pulse in that case, I believe. > The point of which would be what exactly? All due respect, Phonon is already a sound daemon. To output sound through a sound daemon into ANOTHER sound daemon, particularly one as poor as Pulse Audio, is begging for latency and who knows how many other problems. And, again, it's redundant and unnecessary since Phonon's already a good sound daemon on its own merits.
Re: [arch-general] PulseAudio in [testing]
On Sat, 2010-11-27 at 18:21 -0600, Yaro Kasear wrote: > On Sun, 2010-11-28 at 08:18 +0800, Ng Oon-Ee wrote: > > Just don't use Gnome. Upstream is going to make Pulseaudio default. KDE > > as well, maybe. > > > I don't see KDE upstream doing that. They have Phonon. What's more, most > KDE apps today count on Phonon being there. KDE upstream won't do that > without expecting to break KDE. Admittedly my view on this is skewed, since I follow PA's development pretty closely, but one of the devs on PA (Colin Guthrie) has mentioned getting various patches he's done for Mandriva's KDE implementation such that KDE's mixer and such supports pulseaudio natively. Phonon would output directly to pulse in that case, I believe.
Re: [arch-general] PulseAudio in [testing]
2010/11/27 Ng Oon-Ee : > On Sat, 2010-11-27 at 13:01 -0600, C Anthony Risinger wrote: >> On Sat, Nov 27, 2010 at 1:47 AM, Philipp Überbacher >> > Gnome isn't Linux, Gnome is primarily a DAU-top. I don't see why gnome >> > should govern the direction of every distribution. Yes, ubuntu decided >> > that they want to follow and build on gnome, their release cycle etc., >> > but we're not ubuntu. >> >> yes i'd agree 100%; to clarify, i'm not asking about gnome/.../... in >> particular, my inquiry was based on the observation that only one >> "sound server" (or user-space library) can comfortably run per system, >> and i was curious as to how that would unfold in terms of pacman/etc. > > This has nothing to do with pacman. You can have many sound servers > installed, you just have to choose yourself which to run. And ALSA is > not a sound server. Pulseaudio and JACK are. I run both, at varying > times, on the same machine. well, that's why i said "library"; i know the user space alsa is not a server. the fact is, as you've stated, only one impl. can comfortably run at any given moment... but yeah, it doesn't matter too much i guess :-) i was referencing the fact that package managers (including pacman) are pretty one-track minded, and cannot cope with internal variations of the same package whatsoever (causing a need for dynamic dependency handling). portage sort of handles it, with the SLOTS system, but not really... in pacman (and others) a whole new package must be created. so maybe a totally pointless question in the end, but was curious if the *-pulse suffix would ever be dropped for some other scheme. >> > The piece you miss: PA depends on alsa, it builds on alsa, it can't >> > replace it. At hardware-near levels there's still alsa at work. If you >> > use alsa via PA, then you go alsa-PA-alsa. >> >> ok, i was thinking that PA was eventually going to have new kernel >> bits included as well. i know (IIRC) that ALSA is a kernel API, and >> also a userspace API... distinctly separate. programs are normally >> linked against the userspace API vs. using the kernel directly, >> correct? and PA has no intentions of ever reaching the kernel in any >> way shape or form? > > Refer to your own comments below. How does the kernel even come into a > discussion on Pulse anyway? yes there is much to learn :-) i thought pulse ultimately was trying to replace the ALSA kernel API as well, but sounds like i may have been wrong. >> > Btw., last time I checked it was not recommended to program using the PA >> > API, so unless this changed, developers are still supposed to write >> > their programs for alsa or whatever else. >> >> ok, i suppose i will need to do some more research on all of these >> components and how they interoperate, thanks Philipp. > > Yep. Simple version, ALSA manages the hardware itself (a tough job, and > causes most breakages currently, hardware support on Linux, same old > story), pulseaudio plugs in on top of that to manage ALL apps, so it > sits between apps and ALSA. In the same way JACK does. but there is still a difference between the alsa kernel API and the user space API... they just happen to share the same name, but they are very different [wikipedia]: "Unlike the kernel API which tries to reflect the capabilities of the hardware directly, ALSA's user space library presents an abstraction which is as similar as possible across disparate hardware." i thought pulse was using the kernel API directly, but again may be wrong. in this respect, PA is a peer to alsa-lib, not alsa... everything (jack/oss4 included?) uses alsa at kernel level. >> my only concern is that 99% of the negative feedback is based on >> ubuntu this or that, usually from years past... ubuntu pretty much >> jumped the gun; i really like the growing trend of services with DBUS >> unification, and i think this is a Good Thing for >> management/security/flexibility. > > Yeah, what does Ubuntu have to do with Arch anyway? heh, indeed :-) that's what i thought. >> PA appears to be quite stable at this point, and it's great that apps >> work with or without. somewhat unrelated, but these same questions >> will rise again, and more fiercely, once systemd is stable and >> mainstreamed (which is slated for fedora, and IIRC being considered by >> debian/ubuntu)... the landscape is changing for the better. > > I've been following systemd as well, looks good (though BSD-style init > is what we're all used to here). Will perhaps try it out soon. PA is > stable, and IMO has been for more than a year. yeah that's another can of worms, but it's one of about 3-5 technologies i'm really excited to reach fruition. nice that PA is w3rks for you too though, i'm definitely going to give it a shot very soon. thanks Ng, Jan, Philipp and everyone else for your time. C Anthony
Re: [arch-general] PulseAudio in [testing]
2010/11/28 Ng Oon-Ee : > On Sat, 2010-11-27 at 19:34 -0200, Bernardo Barros wrote: >> My experience is that pulseaudio sometimes works for simple desktop audio. >> Any serious work with audio it just cause (or potentially cause) problems... >> (again, just my experience) > > if (serious audio work); then > pulseaudio -k; jackd > fi > > This is OT though. Has the new pulseaudio/libpulse in [testing] affected > your system? > > pasuspender jackd This will suspend PulseAudio (corking all streams and releasing all devices) while jackd runs.
Re: [arch-general] PulseAudio in [testing]
On Sat, 2010-11-27 at 19:34 -0200, Bernardo Barros wrote: > My experience is that pulseaudio sometimes works for simple desktop audio. > Any serious work with audio it just cause (or potentially cause) problems... > (again, just my experience) if (serious audio work); then pulseaudio -k; jackd fi This is OT though. Has the new pulseaudio/libpulse in [testing] affected your system?
Re: [arch-general] PulseAudio in [testing]
On Sat, 2010-11-27 at 13:01 -0600, C Anthony Risinger wrote: > On Sat, Nov 27, 2010 at 1:47 AM, Philipp Überbacher > > Gnome isn't Linux, Gnome is primarily a DAU-top. I don't see why gnome > > should govern the direction of every distribution. Yes, ubuntu decided > > that they want to follow and build on gnome, their release cycle etc., > > but we're not ubuntu. > > yes i'd agree 100%; to clarify, i'm not asking about gnome/.../... in > particular, my inquiry was based on the observation that only one > "sound server" (or user-space library) can comfortably run per system, > and i was curious as to how that would unfold in terms of pacman/etc. This has nothing to do with pacman. You can have many sound servers installed, you just have to choose yourself which to run. And ALSA is not a sound server. Pulseaudio and JACK are. I run both, at varying times, on the same machine. > > > The piece you miss: PA depends on alsa, it builds on alsa, it can't > > replace it. At hardware-near levels there's still alsa at work. If you > > use alsa via PA, then you go alsa-PA-alsa. > > ok, i was thinking that PA was eventually going to have new kernel > bits included as well. i know (IIRC) that ALSA is a kernel API, and > also a userspace API... distinctly separate. programs are normally > linked against the userspace API vs. using the kernel directly, > correct? and PA has no intentions of ever reaching the kernel in any > way shape or form? Refer to your own comments below. How does the kernel even come into a discussion on Pulse anyway? > > Btw., last time I checked it was not recommended to program using the PA > > API, so unless this changed, developers are still supposed to write > > their programs for alsa or whatever else. > > ok, i suppose i will need to do some more research on all of these > components and how they interoperate, thanks Philipp. Yep. Simple version, ALSA manages the hardware itself (a tough job, and causes most breakages currently, hardware support on Linux, same old story), pulseaudio plugs in on top of that to manage ALL apps, so it sits between apps and ALSA. In the same way JACK does. > > my only concern is that 99% of the negative feedback is based on > ubuntu this or that, usually from years past... ubuntu pretty much > jumped the gun; i really like the growing trend of services with DBUS > unification, and i think this is a Good Thing for > management/security/flexibility. Yeah, what does Ubuntu have to do with Arch anyway? > > PA appears to be quite stable at this point, and it's great that apps > work with or without. somewhat unrelated, but these same questions > will rise again, and more fiercely, once systemd is stable and > mainstreamed (which is slated for fedora, and IIRC being considered by > debian/ubuntu)... the landscape is changing for the better. I've been following systemd as well, looks good (though BSD-style init is what we're all used to here). Will perhaps try it out soon. PA is stable, and IMO has been for more than a year.
Re: [arch-general] PulseAudio in [testing]
On Sun, 2010-11-28 at 08:18 +0800, Ng Oon-Ee wrote: > On Sat, 2010-11-27 at 12:09 -0600, Yaro Kasear wrote: > > > > > I stated it before, but I'll say it here, I don't think Pulse Audio is > > right for [extra]. Compiz is a lot more stable and still manages to stay > > in [community]. Pulse goes down a lot and takes sound with it and it's > > getting put in [extra]? I'm not sure how this makes sense. > > > > And I strongly oppose any "default" usage of Pulse Audio the way Ubuntu > > or Fedora forces it on their users. It just doesn't work that well. > > Also, forgive me if I am wrong, but isn't that against the Arch way of > > doing things of just putting in a minimalist installation? I'd hate to > > see Pulse Audio get installed by default for anything, but as a part of > > the default Arch install I think is just an all around bad idea. > > > I'd suggest reading before posting. 'default' means nothing on Arch > (already mentioned), and Pulseaudio is not going to be 'default on your > Arch installation' (also already mentioned). > > Just don't use Gnome. Upstream is going to make Pulseaudio default. KDE > as well, maybe. > I don't see KDE upstream doing that. They have Phonon. What's more, most KDE apps today count on Phonon being there. KDE upstream won't do that without expecting to break KDE.
Re: [arch-general] PulseAudio in [testing]
On Sat, 2010-11-27 at 12:09 -0600, Yaro Kasear wrote: > > I stated it before, but I'll say it here, I don't think Pulse Audio is > right for [extra]. Compiz is a lot more stable and still manages to stay > in [community]. Pulse goes down a lot and takes sound with it and it's > getting put in [extra]? I'm not sure how this makes sense. > > And I strongly oppose any "default" usage of Pulse Audio the way Ubuntu > or Fedora forces it on their users. It just doesn't work that well. > Also, forgive me if I am wrong, but isn't that against the Arch way of > doing things of just putting in a minimalist installation? I'd hate to > see Pulse Audio get installed by default for anything, but as a part of > the default Arch install I think is just an all around bad idea. > I'd suggest reading before posting. 'default' means nothing on Arch (already mentioned), and Pulseaudio is not going to be 'default on your Arch installation' (also already mentioned). Just don't use Gnome. Upstream is going to make Pulseaudio default. KDE as well, maybe.
Re: [arch-general] PulseAudio in [testing]
My experience is that pulseaudio sometimes works for simple desktop audio. Any serious work with audio it just cause (or potentially cause) problems... (again, just my experience)
